… or relative size over absolute numbers
Imagine yourself at the startup of a project. Your requirements are written down, hopefully as user stories, and you are ready to start estimating. One very common approach on doing this revolves around a project manager who asks team members, who are responsible for carrying out the tasks, for estimates on how many days, hours or minutes they will take to complete.
This process could probably be improved a lot but the focus here is on the estimation part. Let us assume that there are user stories, a cross functional team and a planning session in which every one who is participating in the development team can attend. This includes stakeholders, developers, usability experts, database administrators or anyone that has an active role in your project.
In this meeting it is very important that everybody can make his voice heard. Since you want all the risks, possibilities and challenges with your user stories to be discussed. You will also want to be able to play the ‘planning game’ again. The product of this session should thus be a plan that takes you in the right direction, focuses on the correct tasks and stories by completing the user stories that bring the most business value to the customer first. The definition of business value in this context is another discussion and will be left out for the time being.
When everyone is at the same place and ready to start estimating you need some common ground to stand on. This is where estimating in points, or rather estimation in relative size over absolute numbers comes in.
Estimating in relative terms is more like sorting. “Is this bigger than that” or “If this is 3 how much is that”? It is faster, more accurate but most important of all it focuses on the real impediments of a user story than estimating in absolute figures does.
Imagine this scenario, an actual experience I have had myself.
Two programmers discussing some new functionality that has to be implemented are looking at the same story card after having been asked the question “How long will this story take to complete?”.
Team member 1: It will take 4 days to complete.
Team member 2: No, it is only 2 days.
Team member 1: How can you say that. This is a very difficult one. The programming alone will be 3 days and then you have documentation, updating acceptance tests and maybe DB-updates.
Team member 2: Yeah, but the acceptance tests take like 3 hours, programming is close to 6-7 and documentation is a mere 4 hour job. I’d say 2 days. At the most!
Team member 1: What! Three hours for acceptance tests. You are out of your mind …
… and this continues for 5 minutes before they settle for a 2, 3 or maybe a 4. Do I need to point out that a 4 is twice the size of a 2, or going for a middle road will probably not lead to very good estimates.
The problem with the approach described is that the discussions are revolving around minutes, hours, days or maybe even weeks. This is not very productive. First, the estimates are very subjective. Second, they will not last for very long as you may gain knowledge about the domain in which you are working. Frameworks might evolve and a lot more can happen which affects the estimates made early in a project. If they are in absolute numbers.
The focus of the discussions should be about functionality. What this particular story means to the customer and how to get there as cost effective as possible. When you do that, magic happens. People start working together and come up with great ideas and the correct questions are answered.
Lets look back at the two programmers discussion again and rephrase the question a bit.
“How big is this user story compared to this one”
Team member 1: Well, this does not include a new editor
Team member 2: No, but I’m pretty sure you will have to be able to make some changes? (turns to customer) Am I Right?
Customer: Yes, I want to be able to change that. Although that particular data can be edited with the default editor:
Team member 1: Great, then it is as big as the other one.
Team member 2: Yes, it is a 2 as well.
The discussion about tests, new DB-tables does not even come up. In fact you do not even have to decide if you want to add another DB-table at this point. That is a later decision, an implementation detail.
My favorite trick to start estimating in relative size is to spread out a whole bunch of user stories on the table, give them a quick look and find a story that looks like it is medium sized. As long as it is not huge nor very very small it will do. I will then assign a number to that. This value should also be in the middle range of your values. If you are using Fibonacci (1, 2, 3, 5, 8, 13, 21 …), it would probably choose 5. This story is now your ‘reference point’. Please note: Setting the value of a reference story is a one time activity. You can not change the value of your reference story along the way. That would have disastrous effects on your estimates.
From here you just start comparing your other stories to your reference one. After a while you can either choose to lose the reference story, as it has become obsolete due to the many other stories that are estimated. Or you could keep it and bring it to your future planning sessions. Just be sure to bring at least one story to your sessions.
Good luck in your future planning adventures!