Deciding to Re-point a User Story

I was at a client recently where a scrum team member asked me about re-pointing a story that the team had estimated during a backlog refinement meeting.  A couple sprints had passed since that meeting, and when the story came to the top of the backlog to be played in the next Sprint, he thought the point value it had been given was no longer accurate so the team ought to have another opportunity to estimate the story.

For many good reasons the team had followed a practice of not re-pointing stories.  The rationale for that practice included:
  • The purpose of story point estimation is to reach a shared understanding of the story and provide an indication to the Product Owner of the level of effort required to deliver it, relative to other stories on the backlog
  • A practice of re-pointing stories can encourage the type of "analysis paralysis" that a team experiences when it tries to provide precise hour estimates for a story or use case.
  • It's expected that some story point values will be too high and some will be too low, that actual effort will vary from estimates.  Story points on completed work provided an average value of historical velocity that is useful for forecasting team capacity. 

Still, team members felt that, if they understood a story better when it was time to play it than they did when they originally estimated it, it was appropriate to revise their story point estimate.

Here are my thoughts on the subject:

Teams make appropriate commitments to work at different horizons: roadmap, release, iteration, and day.  When the team provides a story size estimate far in advance of playing the story, e.g., within a release horizon, the estimate reflects the team's level of understanding and commitment to complete the story based on their understanding and their reality at that point in time. As a story moves up the backlog and gets closer to being played and is more ready to play, the team's experience, work completed, and understanding of what's involved in delivering the story could mean a change in the level of effort to deliver it.  If, when the story is being considered in Sprint Planning, the team feels strongly that the level of effort required is going to be significantly different that the point value assigned, it would be appropriate to estimate it again

Whatever the team decides with respect to pointing in advance, re-pointing, etc., these should be included in the team's working agreements to avoid having to re-hash arguments and conclusions frequently.  That's not to say the team shouldn't reconsider its decisions during a Sprint Retrospective.  It's just a way for the team to memorialize its decisions and establish it ground rules on the subject.

Finally, never change the point value of a story after it's been completed in an effort to make a more accurate historical record of story sizes.  Leave story point values alone at the end of a Sprint and use the historical average velocity to get value from story points on completed work.

For additional reading, here are a really good series of responses to a question on this subject at stackexchange:


Popular posts from this blog

Severity, Priority, Impact and Likelihood - Managing Defects and Risks

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

Chatbot Code of Ethics