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

Share it!

4 thoughts on “Don’t Change Estimates During Sprint Planning

  1. shiva

    Your article made to me view sprint planning in different perception. Thanks you so much!!!
    My query..
    As you said not to change estimate during sprint planning then are you estimating stories in Backlog Refinement or Backlog? and finalizing everything before the Sprint Planning?
    and Sprint planning means Breaking Stories in Tasks & Hours allocation per capacity is isn’t?

    Reply
  2. shiva

    Thanks Chris,

    If my team capacity is 300 Hours for 2 weeks sprint. (5 members, 6 Hrs productivity & 10 working days)
    In Backlog Refinement meeting, Team has sized
    3 stories as 3 Story points each (9 SP)
    4 stories as 5 Story points each (20 SP)
    6 stories as 8 SP (48 SP)

    Total 13 stories & 77 Story Points.

    In Estimation planning will decide how many stories & How many story Points can accommodate. and these data no where related to Hours or efforts.

    But my Team capacity is 300 Hours.

    How to decide how many stories & How many story Points can accommodate? using which parameters?

    one more question..
    Can team creates all sub tasks for their entire User stories in Sprint Planning?

    Reply
    1. Chris Sims Post author

      Shiva,

      I believe you are putting too much focus on, and faith in, the estimates. While they are useful for decision making and managing stakeholders’ expectations, they are not so valuable in sprint planning. The goal of sprint planning is to create a plan that whole team believes will create the maximum value this sprint. This involves carefully looking at the stories, the work required for each story: not just the amount of work, but the specific details of the work.

      Many of us, myself included, have fallen into the trap of thinking that there is way to calculate a sprint plan. Sprint goals, stories, developers, and creative technical problem solving work can’t be adequately represented in a formula. Annoying. The best approach I know is to gather the team and collaboratively make a plan that we all believe will succeed. I recommend having a look at the following articles:

      Cheers,

      Chris

      Reply

Leave a Reply to Chris Sims Cancel reply

Your email address will not be published. Required fields are marked *