Is It Ever OK to Re-Point User Stories?

You ask ’em, I (try to) answer ‘em.

Q: Is it ever OK to re-point user stories?

Inevitably, teams encounter a user story that takes significantly shorter or longer than anticipated to complete and they want to change its’ story point value to reflect reality after the work has already been done. Typically, their motivation for doing so is to obtain a more accurate representation of the amount of work done in the sprint, often because velocity (the number of story points delivered in a sprint) is used by leadership as the measuring stick by which teams are evaluated — either by comparing velocity across teams or micromanaging changes in a team’s velocity sprint-over-sprint (fear the dreaded dip!). This behavior, however, is an agile anti-pattern that will hinder your team’s ability to effectively plan sprints, estimate reasonable completion dates, and shifts focus away from using story points and velocity as tools for continuous improvement.

I believe teams should never re-point user stories.

Let’s look at why.

Story Points are Estimates

When teams assign a story point value to a user story they are making their best estimate of the effort required to complete the work based on what they know before development begins. Changing this value after the work is already done, when everything is known about effort it took to complete the user story, causes the team’s velocity to become a reflection of the actual work done rather than an estimate of the work to do.

Why is this an important distinction?

Velocity is a tool used by scrum teams to perform both sprint and release planning on work from the team’s product backlog, which contains only estimated user stories to be completed at some point in the future. It should represent the rate at which the team can complete estimated story points because the backlog contains estimated story points!

If velocity is calculated using revised user story estimates, any sprint or release plans will be based on the rate in which the team can deliver actual story points rather than estimates. Given that people have a natural tendency to underestimate the effort required to complete work, changing story point values after the fact is likely to result in a team’s velocity being estimated artificially high resulting in mistakenly early release date predictions. Doing so puts the team at a distinct disadvantage by setting unrealistic expectations with key stakeholders regarding release dates that are not likely to be hit.

Further, changing an estimate to reflect reality hides velocity volatility. Volatility represents risk — the more volatile a team is, the less predictable their output is from sprint-to-sprint and the harder it is to estimate release dates. When teams re-estimate user stories after the fact, it’s a sign that they’re focused on the wrong thing — instead of embracing their volatility and having a discussion around how to estimate better, they play games to try to hide it by bumping up estimates to achieve or exceed their estimated velocity and demonstrate artificial stability or improvement.

Story Points are a Continuous Improvement Tool

Re-pointing user stories acts as a bandaid for teams who struggle with inaccurate estimation and signals to the team that accurate estimates aren’t important — just fix ’em after the fact, right? Instead, use these occurrences as moments to reflect on why the estimate was inaccurate in the first place and try to fix it going forward. This can happen for a variety of reasons, including:

• Unforeseen Dependencies: When teams don’t spend enough time refining user stories, the work required to get to done isn’t obvious. The steps involved and people required aren’t clear, resulting in unanticipated blockers arising mid-sprint. Note any external dependencies in the user story and never pull it into a sprint until they have been resolved (remember — the I in INVEST stands for Independent!).
• Unclear Implementation Path: Sometimes how a user story will be implemented isn’t clear at the start of a sprint and teams spend more time than expected in the design phase. If the how is unclear, create a discovery spike to first investigate, design, and plan the work, then circle back on the development work when the development path is more clear.
• Ambiguous Scope from the Outset: Teams occasionally bend the rules and pull in work that is not clearly defined. The user story has minimal acceptance criteria, making it very unclear what done looks like. If a user story does not satisfy the INVEST principle, do not pull it into a sprint — period.
• Scope Creep Throughout Development: It is not uncommon for Product Owners to add acceptance criteria mid-sprint with little-to-no push-back from the development team. Mature Agile Coaches and development teams must push back. Instead, create a new user story and prioritize it in the product backlog. If it must be pulled into the sprint, something else must be pushed out — no exceptions!
• Unavoidable Delays: Some sprints, sh*t just happens. Team members take unanticipated sick leave, mandates are pushed down from leadership that cause priorities to shift and work to stop, etc.

When any of these situations occurs estimates should be left as-is. The frequency and likelihood of these delays will actually be built into the team’s velocity volatility and will lead to more accurate estimates!

In general, re-estimating user stories after the work has been done is never a good idea. Doing so puts the team at a disadvantage with regard to reasonably accurate sprint and release planning and robs them of an opportunity to improve the predictability of their velocity through better user story estimation.

Have a different viewpoint, follow-up questions, etc? Head over to the responses where I highly encourage a healthy discussion/debate to help fine-tune these recommendations in the name of spreading the agile love!