Estimation: Time or Size?
(No Ratings Yet)
Loading ...
It surprises me, but I have recently come across a few people in the Agile field who prefer estimating in “real time” over estimating in size (e.g. story points); I have even heard statements such as: the most advanced implementations of Agile use real time estimates, because it offers the most powerful benefits. My gut feeling has always told me otherwise, but I found that I didn’t have a well-thought out argument beyond, erm… read Mike Cohn’s book, which in the event of a real-time discussion is not very helpful, and even so does not address all of the arguments I have been hearing against size-based estimation. This blog post is my attempt to clarify my own thoughts on this matter. I focus on four specific arguments in favour of time measurement, and attempt to counter those arguments.
Argument 1: Estimating in hours allows a developer to measure his estimate against his actual, and use that data to improve his estimates in future.
This is true, and it works very well if a project has only a single developer working on it, or has more than one developer but they are all essentially working alone, on different parts of a system — a common model in a “build-by-layers” approach to system development.
Problems arise however when we introduce the concept of cross functional teams working on “slices” of a system. What is a team-hour? Is it the whole team working for one hour together, or is it the average time it would take one team member to do the work? Already we are beginning to talk in abstract time, not real time. One team member may be twice as fast as most others, through familiarity with the system and/or greater experience; does one hour to him mean the same as it means to others? Clearly not. “One hour” becomes a confusing unit of measurement in such cases. It is also the case that different team members have different responsibilities. How do we find a unit of time appropriate across documentation, UI design, coding and testing. How does each team member measure the time other team members will take for their part of the work on the story? You’ll see that this quickly becomes completely unmanageable.
Some Scrum/Agile teams use hour estimates at the task level, with the assumption that a single developer will work on each task; this seems reasonable as the tasks are divided across skill boundaries, such as server-side, database, testing, etc. In this case Argument 1 seems to hold good: developers should estimate in hours at a task level and then improve their estimates by measuring estimates against actuals. Unfortunately this argument breaks down again as soon as we recognize that the best code creation, and the best testing is done in pairs. Again, what does one hour mean? A pair hour or an hour for one of the pair? What if we don’t know in advance (as we probably should not) who will pair with whom and on what? Who gives the hour estimates? Everybody? Just one person? Which person?
In general, I find the practice of estimating task time to be massive, wasteful overhead. Tasks should be small; they should move across the task board in a single working day. End of story. The focus of estimation should be at the story level.
Argument 2: Our customers/product owners don’t understand story points; they need to know how many hours developers are working so they know how much the work will cost.
I hope anyone reading this can see the immediate flaw in this argument: micro-management. Product Owners have no business knowing how many hours each developer is working. It breaks encapsulation and it breaks self-organization. Actually, it breaks pretty much everything. Customers are not buying developer hours, they are buying software. Their focus needs to be on how much software they can expect in an iteration; their measurement needs to be on comparing actual software delivered against expected (promised?) delivery.
Story points help set expectations here. Very soon after beginning iterative development using a size measure to estimate, customers will be able to see the capacity of the team: this team can deliver 40 units of software per iteration, therefor let me prioritize 40 units’ worth of features for the next iteration, with a few extra units in reserve. It is beautifully simple. A customer is welcome to map story points to cost (it will be approximate). He should not care about how many hours it took to make the software.
Argument 3: Story Points will map to time anyway, very soon we’ll see that (e.g.) one story point is worth 2.5 hours, so it is better to skip the intermediate step and just measure in hours.
This is a flawed argument, and assumes a team never gets better. Truly self-organized teams always get better. When a new team starts, it may be safe to say that (e.g.) one story point is worth 2.5 hours, but as the team improve their development and teamwork skills, as the code base is salvaged from the big mud hole it has been in for the past months or years and rises majestically to a state of elegance, and as the team use regular reflection to improve their process, the value of a single story point will change. It may come to be valued at only 2 hours, because time is being used more efficiently. Now instead of 40 story points in an iteration the team can take on 50 story points.
More story points per sprint means that the customer will be getting more software. The cost of this software will not go down; the team building it will be making greater profits for the company. That’s business. The customer is happy — happier, in fact — he is getting the software he needs at the price he expects to pay, but getting it faster. Everyone is happy.
Imagine if the customer was measuring time. He would expect his software to get cheaper as the team got better; what used to take twenty hours to build now only takes ten hours, because the developers have put time into creating a good infrastructure and developing good practices. This does not seem right. The benefits, at the very least should be equally shared between provider and customer. A time-based estimation model will not allow for that without (apparent) steep price increases.
A measure of size allows a team to show they are creating more value for money. We can draw big visible charts to show this. A measure of time will never show this, because there are always a fixed number of working hours in an iteration.
Argument 4: Story Points don’t allow you to improve your estimation techniques.
Actually, they do. Sometimes when clients ask me how this works, or why it works, I tell them it is magic. This is not so far from the truth. I have never really figured out quite why or how it works. But it does. Teams do get better at estimating. A simple velocity chart that maps two points for each iteration, i.e. estimated points and actual points, will begin to show the points converging over time, and not that much time either. Of course the shorter the iterations, the quicker this improvement will be apparent. I always recommend iteration lengths of one week or two weeks. Never longer.
And to be clear, the two points don’t just get closer together because teams are committing to less and less each time. The average value of points delivered goes up over time. This latter, it may be argued, is because teams begin making bigger and bigger estimates. I can see that would be a temptation, but because the team starts collecting historical data (sometimes even just at a gut-level) they self-correct for this, using their data as a baseline for future measurement. Remember, good software developers want to build good software, and they want to do it fast and efficiently. Suspicion doesn’t have much of a home in an Agile environment.
I am sure there are other (and perhaps better) arguments to favour measures of size over measures of time, and I’d love to hear them here. I’d also be interested to hear opposition to my arguments; healthy debate on this topic is welcomed.
Comments
Got something to say?
[More Help]