Should you re-estimate unfinished work?
Avoid having unfinished or work not “Done” at the end of a Sprint.
When a team finishes part of a Product Backlog item, people often ask to receive partial credit toward the velocity for their effort.
Example: a team that claims to be 1/2 done with an eight Story Point Product Backlog item may expect to count half of that—four points—toward their Velocity.
A team should only add points to Velocity for work that meets the Definition of Done.
In the above example, the item doesn’t meet the Definition of Done. Perhaps only 1/2 the tasks are completed.
As Mike Cohn suggests:
"Taking credit for partially Done work would be like me inviting you over for dinner and serving you half-cooked chicken. It might taste OK now, but you’re going to regret it later"
Mike Cohn
When a team takes credit for partially complete work, they often overestimate how much is Done.
This is because, Mike Cohn argues, that Developers think they see the full scope of what’s needed before they do the work and they are truly 90% done with that ‘known scope’.
The amount of effort to complete complex work can only be truly known once the work is actually completed. So, a team that says they’re 50% Done is perhaps only 40% or 48% or 35% Done. Knowing the percentage Done is very hard and most of us overestimate how done we are.
Because teams tend to think they are further along than they truly are, velocity is slightly inflated. An inflated velocity feels good at the moment—like Mike Cohn’s half-baked chicken analogy—a team can tell its stakeholders a nice, big, juicy Velocity value. But that inflated Velocity will stop feeling good if anyone ever uses that artificially high Velocity to forecast when the next set of Backlog items will be Done.
Scrum.org Professional Scrum Trainers (PSTs) advise teams to take a stance of no partial credit.
No matter how close team members are to finishing a backlog item, they earn no points for it until the entire item is done. This is analogous to scoring a try in Rugby or a touchdown in American football. A team needs to move the ball over the line. Doing so earns a team points. Moving the ball 10m from the line earns the team zero points. No “partial credit”.
Mike Cohn highlights two big benefits to taking a stance of no partial credit.
Ensure the Product Owner is provided the opportunity to decide whether or not the remaining work is still of value to deliver and in what Sprint.
When a Product Backlog item is unfinished at the end of a Sprint, the team often wants to know if the item should be re-estimated.
The size of the Product bBklog item may have increased such that the estimate of what remains actually goes up and is higher than the initial estimate. For example, a team feels like they’ve made two points of progress on a five-point story but also have discovered that there are eight points remaining. In re-estimating partially finished work, it is entirely possible for the new estimate to exceed the original.
But should a team re-estimate at all?
There are two arguments in favor of re-estimating:
The argument for resizing the backlog item assumes the team is using velocity-driven sprint planning techniques.
In that approach a Sprint is planned by selecting product backlog items whose estimates sum to the team’s average velocity. So if a team has a Velocity of 30, they bring in 30 points of work. If they’ve already brought in 25 and the next item is a partially finished item estimated at eight points, that item won’t fit.
Velocity-driven planning is different from capacity-driven sprint planning, which involves the team simply selecting items one at a time and seeing if the item can be Done in the Sprint. If they can, they include it and consider another until Developers feel the Sprint is “full”.
In general, a Product Owner's forecasts are more accurate if they and their teams pay a bit less attention to each Sprint’s Velocity and more to the average Velocity of recent sprints.
There is always a natural variability to complex work. Understanding the natural variability and trends over time helps teams improve their forecasts and set better examples with stakeholders about when they are likely to see Done work.
When work doesn’t meet Done by the end of the Sprint: