Deciding to Re-point a User Story

By -


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:
http://pm.stackexchange.com/questions/12536/what-can-we-do-with-a-mispointed-story-in-scrum
http://programmers.stackexchange.com/questions/173292/should-you-ever-re-estimate-user-stories

Comments

Post a Comment

Popular posts from this blog

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

By -
Defects and Risks are often dealt with in a subjective, emotional way.  That's unfortunate, because among all the things a software development team deals with, those are two that can be handled in a more constructive and empirical way. First, a couple definitions. Defect Severity: the degree of impact a defect has on system operation. A defect is something observed, so impact can be empirically quantified. Risk Severity: the degree to which a hypothetical event, should it occur, would impact system operation. A risk event is something that has not occurred, so impact must be estimated or extrapolated. The common element in both Risk Severity Assessment and Defect Severity is Impact on Revenue.  The FMEA framework that AKF recommends uses 1 = Low, 3 = Med, and 9 = High, to represent the exponential effect of a high impact risk or defect Impact on Revenue No payments being collected and/or payment data security compromised (Critical) Payment collection being de
Read more

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

By -
Image
Brian Rabon introduced me to the Entrepreneurial Operating System (EOS) as the framework he uses to manage his company, The Braintrust Consulting Group (TBCG). EOS is the missing element in organizations that are having some success with Agile at the team level, but not succeeding with change at higher levels or outside software development. As Charlie Rudd points out in his post The Third Wave of Agile , there is broad consensus on the value of Agile practices at the team level, but all types and sizes of businesses are struggling to scale Agile and to increase agility across their organization.  I think EOS addresses those challenges. EOS is comprised of the EOS Model : Having a model like this in place allows teams to function optimally as self-organized units that share the vision and goals of the organization.  Teams are able to align themselves with the organization's objectives, and can see how their outcomes affect the organization's performance. The EO
Read more

Demand Management Using Agile + Lean

By -
Image
The problem of demand for IT services and project resources exceeding available supply is something every organization faces.  I was asked again recently about how Agile helps with demand management. Agile addresses the problem in several ways. First, an Agile team's highest priority is to satisfy the customer through early and continuous delivery of valuable software.  Unbridled demand almost always will exceed resource capacity, but increasing flow of finished work from the development organization definitely results in higher levels of satisfaction from those who produce the demand. Further, delivering working software frequently, from a couple weeks to a couple months, with a preference to the shorter timescale, means a team satisfies demand on a more regular basis and on a timeframe that corresponds to the customer's ability to absorb and implement new features and enhancements. Finally, Agile processes promote sustainable development.  Sponsors, developers, and us
Read more