Why Story Point Estimates Shouldn't be Changed
When practicing Agile, it isn't unusual for a team to discover that their original story-point estimate for a story wasn't quite right. It may turn out to be easier than expected or (more often) more complex.
This is very common, especially when teams are immature or taking on unfamiliar work and not something to be ashamed of or worry about. What's more important is how they deal with it and what they learn from it.
In this post, I explain why changing the original estimate on a story is never the answer, even if it is known to be inaccurate and how changing story estimates can affect the integrity of velocity tracking and capacity planning.
Common Bad Practices
Over my career, I have seen some "interesting" approaches to the situation.
Changing estimates retrospectively at the end of the sprint
One Scrum Master, with whom I worked many years ago, asked the team to estimate the points remaining on a story that hadn't been completed at the end of the sprint and then reduced the estimate on the story accordingly before moving it into the next sprint.
While it makes sense to understand the remaining effort, so it can be factored into pragmatic (vs. absolute) capacity planning for the next sprint, the original estimate should never actually be changed.
Why story point estimates shouldn't be changed retrospectively
If the estimate is reduced before taking the story into the next sprint, the effort spent in the previous sprint is effectively "lost" in the ether. The points cannot and should not be counted in the previous sprint's velocity, because the story was not completed, but the deducted points are also not recorded in the next sprint if they are removed before the story is carried over. This leads to inaccurate velocity tracking and therefore poor capacity planning in future sprints.
The Scrum Master's response, when challenged, was that the previous estimate was "in the history". Some Agile tools do have fields for "original" and "actual" estimates (although this was well over a decade ago, when such things didn't exist!), but these should be used for informational purposes, in the background, to assess the team's estimate accuracy over time; never to replace the original estimate used for velocity reporting.
By the same token, if a story is found to be more complex than originally thought and the effort required in the next sprint is greater than the original estimate, increasing the estimate before carrying the story over doesn't solve the problem either. If the story couldn't be completed in the previous sprint and there is the same or even more work to do in the next sprint, there's a strong chance the story still won't get done in the next sprint. In this case, the story should be broken down at the end of the sprint and the constituent parts put back on the backlog and re-estimated, to be taken into subsequent future sprints.
Note that this still doesn't change the estimate on the original story in the previous sprint; but the team are able to learn from the experience and divide the remaining work up into new stories, which can be estimated more accurately in future sprints. This is different to reducing or increasing the estimate on the original story and carrying it over, as it does not change the estimate on the original story. A good way to think of the difference is that one re-writes history and the other re-writes the future.
"It's ok to break an underestimated story down into smaller stories at the end of a sprint and re-estimate the constituent parts, to be taken into future sprints, because that doesn't change the estimate on the original story. This is different to increasing or decreasing the estimate on the original story because it turned out to be inaccurate. One is re-writing history; the other is re-writing the future."
Surreptitiously updating estimates mid-sprint
A Developer once confided that he used to surreptitiously update the estimate from what he'd originally "guessed" in sprint planning to a more accurate number, after he'd started the work, but had stopped doing so because he'd been found out and "marked down" for poor forecasting. This was obviously quite a lot to unpack!
Why story point estimates shouldn't be surreptitiously updated mid-sprint
Firstly, changing estimates mid-sprint defeats the purpose of estimating in the first place. Estimates represent the team's understanding of the story at the point of sprint planning. Any variance from that estimate will and should be reflected in the team's velocity.
If a team significantly overestimates, their velocity will increase because they'll burn through their sprint commitment more quickly and be able to take on more stories than first thought.
If they underestimate, their velocity will decrease because they won't be able to claim points for the incomplete stoy/ries at the end of the sprint and will have to carry the work over.
This is all valid and valuable learning that is lost if the original estimate is changed.
Overestimation
If a team overestimates, no real harm is done. Their capacity will increase in line with their velocity and they'll learn to take on more stories in future sprints.
It can result in "story-point inflation" that may need to be re-baselined against new example stories at some point, to avoid the trap of nothing being smaller than a 5 but, once a team becomes familiar with the work and adept at breaking stories down to the absolute minimum, it can often be the case that every story really is 5 points! This may not necessarily be cause for concern.
Underestimation
Persistent underestimation is a more serious problem and may indicate that the work is not well-understood, or that stories are too big and need to be broken down further.
Again, this should be obvious at the end of the sprint, when the team struggles to meet their sprint commitment and isn't solved by changing the estimate to make it look like they did more work!
Inaccurate estimation shouldn't be penalised
Secondly, no team member should ever be "marked down" for inaccurate estimation. The reason the Fibonacci sequence (1, 3, 5, 8, 13...) is used is that it is deliberately vague and representative of relative, not absolute effort. It is a tool for capacity planning, not for measuring productivity or performance.
In the ordinary course of events, some stories will typically be slightly underestimated and some may be slightly overestimated and the two usually balance each other out. This is called "common variance" and doesn't need to be addressed or over-analysed.
When teams first start working together, if there is a change in the team make-up, or if the team takes on new or unfamiliar work, their estimation may well be a bit hit and miss for a few sprints. Unless the team vastly under or over commits, there is nothing to worry about and their velocity will almost certainly stabilise over time.
Even on a large programme, with multiple contributing teams performing totally incomparable work, I was surprised to discover that, although the teams' story point velocities obviously couldn't be compared (a topic for another blog post!), the number of stories completed by the programme as a whole each sprint stabilised within a couple of months at around 42 and stayed that way for about a year, until the resource profile on the programme changed. In this case, it turned out that 42 really was the answer to everything!
Deliberately adding or re-estimating story points mid-sprint
Finally, I have also heard of teams not being able to accurately estimate all the stories being taken into a sprint in sprint planning, so instead deliberately amend or add points in mid-sprint, once they are able to estimate the stories more accurately.
This is usually an indication that the team is not performing effective backlog refinement between sprints, so are not in a position to accurately estimate stories when it comes to sprint planning; or that they are taking architectural "spikes" and development stories into the same sprint and cannot accurately estimate the development until the architecture has been decided. This in itself is bad practice and the spike should be done in an earlier sprint, so the team are able to estimate the development effort when they plan to take it into sprint. If the architecture has not been decided, development should be delayed to a later sprint.
Why story point estimates shouldn't be added in or re-estimated mid-sprint
Most importantly, it completely undermines the principle of sprint commitment. If the team cannot quantify the work to which they are committing in sprint planning, how can they possibly be confident in completing it within the sprint? It will almost certainly lead to overcommitment and disappointment for all involved come sprint-end.
Secondly, it renders the burndown chart useless. The purpose of the burndown chart is to act as a visual "information radiator", showing how the team is burning through their sprint commitment over the course of the sprint and whether or not they are on track to meet it. If the scope changes mid-sprint or, worse, keeps changing throughout the sprint, the goalposts will literally move and the burndown line will deviate further from the target, but it may not be evident until it's too late to do anything about it and certainly past the "last responsible moment" to communicate to stakeholders that they won't be getting everything they are expecting at the end of the sprint.
In this example, the architecture (5 points) was decided on day 4, at which juncture the development work was estimated at an additional 8 points; taking the scope to 48. The whole sprint backlog was then re-estimated at a mid-sprint review on day 5, resulting in a further 8 points being added to the scope. On day 7, with just 3 days to go, the team still appeared close to on track but, in reality, only ended up completing the 40 points to which they had originally committed, leaving the 16 added points to be carried over.
The same is true if stories are added late into the sprint - please see my related post on the perils of introducing work late into sprints.
Exceptional Circumstances
As is often the case in Agile, there are exceptions to these rules.
The only time it might be appropriate to question a team member's estimation is if they are suspected of deliberately overestimating work, so they can appear to be doing more than they are and "sitting back" at the end of the sprint, once they've completed the story points expected of them, instead of looking to pick up more work from the backlog.
This kind of behaviour should be exposed by planning poker in sprint planning. If other people consistently suggest lower estimates, the team member in question should be asked to explain why he or she believes it to be more complex and the ensuing discussion should result in the "rogue" member's estimate ultimately being downgraded before the estimate is finalised. In extreme cases, a whole team may conspire to artificially inflate estimates, but this should be able to be identified by the Product Owner or Tech Lead and tackled in a Retrospective to understand the root cause.
Another extreme case might be if it emerges mid-sprint that a story is vastly more effort, or completely different to what was originally believed, or if there needs to be a dramatic change in the technical approach. In such circumstances, it is obviously nonsensical to doggedly retain the story in the sprint until its bitter end and the best course of action is to swap it out of the sprint (for something of equal or lesser value) and use refinement sessions to break it down into new stories to be put on the backlog and estimated for the next or later sprint(s). Again, it's worth noting that, even in this extreme case, the estimate on the original story is still not changed. It is in fact removed from the sprint and split into smaller, hopefully better understood, constituent parts, to be taken into subsequent sprints.
Summary
When I asked Co-pilot to eloquently articulate why story point estimates shouldn't be changed, the response I got was:
"Story points capture what we believed about the work at the time we committed to it. If we change the estimates once we know the actual complexity, we lose the ability to measure forecasting accuracy, learn from estimation errors and maintain meaningful velocity trends. The variance between estimated and actual complexity is valuable data. Changing that estimate removes that insight."
Couldn't have put it better myself! Thank you for reading.
Comments