Estimating Story Size, or, Smidgen, Pinch, and Dash

In this post I am going to talk about something that has evolved on our team.  It may not be right for you but it has served us well and you may find it useful.

Over the past year we have tried many different ways to estimate stories.  We played planning poker (if that’s for you, this is a great tool for it http://www.planningpoker.com/ [and great for distributed teams too]), we used story points, we used days, hours, timeboxes (2 weeks or whatever), I’ve heard of teams using t-shirt sizes…there are all sorts of things you can do. 

Having the whole team together to estimate felt wasteful.  Sometimes there would be no discrepancies, sometimes there would be too many discrepancies, and a lot of times the people involved in estimating would not even end up working on the project.  In any case, the estimates were always a lie.  So we eliminated some waste.

We cut it down to just the people who would be working on each story, but sometimes those people would get pulled onto other projects so the estimates would be wrong for the new person that would be working on it.  So we eliminated some waste.

We broke things into MMFs that contained roughly the same amount of work.  Sometimes it would be 20 small things, sometimes it would be 8 medium things, sometimes it would be one ghastly, horrible thing.  It was difficult to measure at first and we were wayyy off on a lot of things, but over time it got a little better.  So we made some improvements.

Now, all of our stories are same-sized.  When we write them we make sure that they are small, but not too small.  Our stories are all “two days worth of work or less.”  After our weekly demo of the current project (10am) we go through the next batch of stories/designs for the coming week (11am).  We talk them out amongst the people who are working on the project at the time and make sure that everyone agrees that the stories are all two days worth of work or less.  If they aren’t, I’ll go back and refactor them.  If they are, they’re ready to be worked on and they go on the board.

For our situation, this process really had to evolve like this.  I don’t know that it would’ve worked if we just jumped into same-sized stories right away.  Getting a feel for how the team worked and how long each thing took (making sure to account for spikes and other things related to a feature but not necessarily in a story) got us into a really good groove.

Formal estimation did not do us well.  Things would always run longer or run shorter, and both of those are bad.  Too long and you’re behind, too short and people will slack off to stretch it out.  Having same-sized stories makes planning a sprint easy.  It makes meeting deadlines easy.  It reduces a lot of stress that you would get from working on a huge story…on our team we would get brand new HIGH PRIORITY WORK on a fairly constant basis, so smaller stories mitigated context switching.  Using same-sized stories has eliminated much of our waste and simplified our planning, and, in general creates a clean, constant flow of work.

Advertisements

No comments yet

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: