Don’t Change Estimates During Sprint Planning

Team estimating user storiesI encounter scrum teams changing, or worse, creating, story estimates during their sprint planning meeting. This slows down the meeting and it undermines the whole purpose of estimation: predictability.

Predictability is knowing what the business will get and when. Stakeholders might ask the team: “Can we get these features by the end of the year?” Or: “When will the new feature set be ready?”

In a sprint planning meeting, the only predictability needed is a simple yes or no. Is the story (product backlog item) in the sprint? If it’s in, then the stakeholders can expect to get it by the end of the sprint.

The purpose of estimates is to support longer-term predictability, meaning when are we going to get stories from the product backlog? This leads to the reason why we should not change estimates in sprint planning.

When we bring a story into sprint planning and break it down into tasks, we very often will discover things about that product backlog item we didn’t – and couldn’t – know before. Frequently, a team will think oh, our estimate was wrong. We should adjust it. In fact, adjusting the estimate at this time will lead to diminished predictability.

Here’s why. Breaking the story into tasks is something that has us working with the story at a level of detail greater than we have before. If we change the estimate based on what we learn by doing this work, then the estimate becomes a “corrected estimate.” All of the stories in our product backlog will have uncorrected estimates because we have not worked on those yet. If our velocity is based on “corrected estimates,” that velocity will not give a good predictability for a product backlog filled with uncorrected estimates.

Scrum teams typically work in the complex domain, which means there are always unknown unknowns. We can’t expect perfect predictability for each story, but we can achieve good predictability over time. Simply record the points for each story when the story is complete. The team’s burn up chart will fluctuate up and down, but the average rate of delivery (velocity) will give good predictability for when our stakeholders will get their stuff.

Cheers,

Chris

This entry was posted in agile, scrum. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>