Estimating stories quickly and efficiently with ‘The Rules’

Posted in Estimating/Planning, Process, Product Backlog, Requirements, Scrum by Mike Pearce on November 11, 2011

ticktickticktickBING - An Old Timer by hiro008 on Flickr

Estimating a backlog should be easy, especially if your Product Owner has looked after it, knows how to write good stories that mean something to the developers and the business and is able to prioritize based on business value (or, customer delight!). However, estimation meetings, poker planning, planning two or whatever you call it, can often be painful events that descend into chaos, anarchy and heated debate. While these things are all fun, estimation should be fast and simple, afterall applying arbitrary numbers, whose only measure is relatively sized, to amorphous items of work can’t be rocket science, so why would you want to spend much time on it?

Trouble is, developers and engineers are paid to solve problems, that’s what they love to do, so they begin the moment the problem is presented! This is to be applauded, but doesn’t really nail what should be fast conversations about stories!

We’ve recently been coarse estimating the next releases’ worth of stories for each if our products, the backlogs for these products contain between eight and 38 stories, depending on the goal. When we started estimating these, it was clear that it was going to be painful, so I created ‘The Rules’ (to be clear, they’re guidelines, remember the Shu Ha Ri!):

Reset the countdown timer to five minutes.
Product Owner reads story and acceptance criteria.
Team ask questions to clarify their understanding of the feature. No technical discussion.
When no more questions, the team estimates.
If estimates converge or there is consensus, GOTO 1 and start a new story.
If no consensus, start more discussion. Technical discussion is OK here.
When the conversation dries up, or the time ends, whichever is first, the team estimates again.
If estimates converge or there is consensus, GOTO 1 and start a new story.
If a consensus isn’t reached, reset the time for another five minutes.
When the conversation dries up, or the time ends, whichever is first, the team estimates again.
If a consensus still hasn’t been reached after 10 minutes, put a question mark next to the story and GOTO 1 and start a new story.
Optionally: create a spike story to discover more information in order to estimate the difficult story.

This means that the team will never take more than 10minutes to estimate a story. Usually, I’ve found, that the first estimate, right after the PO reads the story and the team clarify their understanding, is enough and rarely do we need the time for the second timebox of five minutes.

Remember, these are just estimates, they can be revised later if necessary and, really, the important part of this meeting is the conversation to clarify the requirements and, thus, ensure that business value is met.

Tagged with: arbitrary numbers, countdown timer, customer delight, estimating, old timer, poker planning, product backlog, scrum, story points, time ends

Mike Pearce – blog