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.

3 thoughts on “Estimation of User Stories With Story Points as Abstract Size Measure

  1. My company is starting to research and learn how we can transition a number of projects (old and new) to an agile methodology. It is an interesting concept for a programmer to have to think in comparative terms as oposed to pulling time estimates out of thin air. Thanks for the post.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.