Estimation of User Stories With Story Points as Abstract Size Measure

After discussing which issues we tried to solve by introducing agile practices to manage a remote development team, using User Stories to be able to compare requirements and building a Backlog for ruthless prioritizing I want to share our learnings about agile estimation of User Stories.

As you might have experienced, estimating the time required to build a certain piece of functionality is not easy. Either you have no clue and guess “3 days” or you have a feeling it will take around “4 hours”. Now what if that 4 hour story takes you 12 hrs or more? Maybe you know you’re too optimistic so you conservatively estimate 8 hrs. But it still ends up taking you 12 hrs. In fact, the longer you’ve been a developer the more you’ll come to realize that your time estimate is hardly ever right!

We Cannot Know in Advance How Fast Our Work Will Progress

The main problem I see with estimating duration is that we usually do not have “ideal” days. Our work gets disturbed by IM, email, colleagues walking by, etc. Sometimes we have good days where we crank out the most complex algorithm in minutes and sometimes we have days where even writing “Hello World” in our favorite programming language would take us an hour or more. As the impact of interruptions is very hard to measure and we cannot rely on how our day goes we’re hardly able to tell how long a certain task will take.

Estimation of Size is More Natural

So, how do you predict the real, productive development time of a developer? How do you estimate the time needed to implement a non-trivial change? We were bad at it – as bad as nearly everyone I know. As Mike Cohn explains very vividly in Agile Estimating & Planning, humans seem to be much better in estimating the size of something rather than estimating durations. Leveraging this idea leads to estimation of tasks in terms of “size” or “complexity” rather than “hours to complete”. You might start defining “size” as something like “ideal programmer days” (how long would it take an experienced developer to implement it, if he wouldn’t be disturbed or face any unexpected issues). Later on, the measure of size can be made completely abstract – based only upon comparing one task to those you’ve already estimated. Hmm, that sounds strange. So how did we do it?

Estimation of Size by Comparison

Instead of asking the lead developer to give an estimation on when he would be able to deliver a User Story, I only asked him: “How big do you think this story is compared to that one”. At first, it was quite strange to him to give an estimation that way and he always tried to tell me how long it would take him to deliver, but I didn’t want to hear that. I only wanted to compare the “size” of the stories.

Comparing the current tasks at hand with what we were able to achieve earlier led us to the last agile practice we introduced: Velocity.