Unfinished Stories
Beginner
difficulty
Stage 2
Agile IQ® Level
Done
Estimation & Planning
Overview
Should you re-estimate unfinished work?
Avoid having unfinished or work not “Done” at the end of a Sprint.
Should a team earn partial credit?
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"
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.
No partical credit
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”.
The benefit of a "no-partial credit" stance
Mike Cohn highlights two big benefits to taking a stance of no partial credit.
- Teams tend to choose smaller work that will guarantee it gets to Done.
- Many teams resolve to try harder to get the items they bring into a sprint to Done.
Don't automatically "roll" work over to the next Sprint
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.
Re-Estimating Unfinished Work
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?
Reasons to Re-Estimate
There are two arguments in favor of re-estimating:
- It’s more accurate since some part of the work has been performed
- It assists the Product Owner understand what can be delivered over the next Sprints, so they can update their roadmap.
The argument for resizing the backlog item assumes the team is using velocity-driven sprint planning techniques.
Velocity-driven Sprint Planning
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.
Capacity-driven Sprint Planning
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”.
Focus on average rather than actual velocity
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.
Try This
When work doesn’t meet Done by the end of the Sprint:
- Estimate the remainder of the work needed for the item to get to Done
- Return the item to the Product Backlog and get the Product Owner to re-prioritise the remaining work.
- Don’t discuss the item at Sprint Review.
- Discuss how to avoid having unfinished work in the Retrospective, this might include a discussion on how to slice work more effectively.
