Bootstrapping story estimation for a release

After another great #PittAgile meetup session last week, where Andrew Cox illustrated the fruit eating estimation game, I caught up with Dan LeFebvre, who I had just met at the Agile2011 conference just a week before.

I asked him if he knew any good games to do story estimation. Why yes, I know a couple good ones! – said he.

This is how you could go about estimating a new release, given that you don’t have any velocity already established or any other historic data to extrapolate from.

[Caveat: I am going to try to reconstruct from memory the steps that he described, but since this was a week ago and much has happened since then, it is possible that I am misremembering or forgetting something, but in any case, I think something like what I describe below might actually work.]

First, you want to sort stories by relative size, similarly to the fruit eating game but allowing stories to be the same size if need be.

Then, you can play planning poker to size each bucket/column (so far this is pretty much like the fruit eating game we had just done).

Now, considering your iteration length (1 week, 2 weeks or whatever the case might be), agree with the team on how many stories you think you can do in an iteration, add their sizes and use that as your initial velocity. Let’s say it’s 10.

Next, take a different set of stories from the table (or wall)  that add up to 10 and see if you all agree that this new set of stories you could implement within an iteration. If yes, iterate over this step until no more stories are left. If not, reduce the set until it’s something the team feels confident they can implement within an iteration. Add up the sizes and set the sum as your new velocity. Let’s say it’s 8.

Now that you have a new velocity, take a new set of stories that add up to 8 and see if you all agree that your team could implement this new set. If so, gather a new set of stories adding to 8. If you don’t think you can, reduce the set of stories until the whole team feels confident they can implement the reduced set of stories in an iteration. Add up the sizes and set the sum as your new velocity. Let’s say it’s 7.

And so on and so forth, until no stories are left for grabs. Finally, you count the number of iterations you have required to virtually implement your set of stories and that gives you a rough idea of how long implementation might take for a this release.

Does this sound reasonable?

I mean, of course we always underestimate how long we think it will take us to implement things, so by that token, this exercise is doomed to result in a rather optimistic release estimate. Still, if you have nothing at all to drew from, doing this exercise might provide with some interesting insights.

24. August 2011 by ariadna
Categories: Agile | Tags: , , , | 1 comment

One Comment

  1. We just tried this today to try to estimate a new feature release (the VP of engineering walked up to my desk the morning after I wrote this post and asked when we were going to be done with the feature that we had just started working on, so I thought: here is the perfect excuse to try this out!!!).

    Something that seems obvious in retrospect, but wasn’t so obvious to me until we started this exercise is that you need two key things to come up with an estimate that is remotely useful:
    1. Well-defined acceptance criteria for each story, so that you know what the scope of the story is and what it means for a story to be done, and
    2. Current priority according to the Product Owner.

    The reason why having an established priority was key in our case is that we have different user stories that mostly rely on the exact same back-end functionality, which is the bulk of the work for that story, and so knowing which one we are planning to tackle first helped us decide on their relative size and size estimation.