Estimating 100+ user stories within 2 hours

Planning poker is a well known and proven technique to estimate user stories. It is a good technique that I use often with the teams I coach. However, when I have to estimate a lot of stories (30-200), I don’t use it, because it takes too much time.

Estimating so many stories is often needed. For example when starting a new project. The product owner has prepared his backlog, and needs to have a ballpark figure for cost estimates, contract negotiation, etc. Even agile teams have to manage stakeholder expectations.

A good technique to estimate many stories (based on a blog I once read, but can’t find anymore) is the following.

I will print all stories on small cards (A5 or A6 size) and put them in a pile on the table. The developers will then sort all these stories into 3 baskets: small, medium and large. The product owner should be present to explain the content of stories. In my experience, you will need about 1 hour to do this for 70-100 stories. Make sure to facilitate it well, encourage the developers to do it quickly, use their gut feel.IMG_1325

When this first round is done, I will ask them to do it again, one level deeper. So, the small stories get split again in 3 groups: small-small, medium-small and large-small. And so on for the medium and large piles. At the end of this second round at most 9 piles will exist from small-small to large-large. Sometimes, some piles will overlap. Large-small and small-medium may be the same size.

This second round of estimation will be performed much faster than the first round. All stories have been discussed already, so the discussion time is saved. Typically, 30 minutes is enough for this step.

From this point onwards, it is easy to assign story points. If this is the first time you’re estimating and there is no story point baseline yet, you can define the small-small pile as your 1 story point baseline. All stories in that pile are 1 point large.

Now move on to the medium-small pile. How much bigger are they compared to the 1 point stories? Twice, three times? Assign 2 or 3 story points. And so on for all 9 piles.

I find it typical that the large-large stories get real big story point counts. 100 points is no exception. And that is fine. This simply means that these are not really stories, but epics and that they need to be split into smaller stories later on (if their value really outweighs their cost).

About André Heijstek

Rijnlands / Agile verbeteren van software ontwikkeling
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a comment