Can Scrum teams earn partial velocity credit for sprint backlog items that are close, but not quite done, by the sprint review meeting? Typically, a team wants partial credit when they've reached the end of the sprint and feel they've done "most" but not all of a given user story. They'll often claim they are something like 80 or 90 percent done and feel they should therefore get some of the credit for the story.
Sorry to break it to you, Scrum teams, but coming close counts in horseshoes, not in velocity measures.
My simple answer to whether teams should take partial credit on nearly finished stories when calculating velocity is no. 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.
Accurate agile planning depends on predictable team delivery. When teams take partial credit for "mostly done" sprint backlog items, their velocity is no longer as accurate or dependable.
In the following video, I describe the negative imacts of "fudging" a team's velocity by taking some credit for semi-finished work. The text of the blog includes the information in the video and a few extra nuggets of information as well.
Why can't agile teams take partial credit for unfinished stories?
You’re close, very close. You’ve almost finished a product backlog item…when…the sprint ends. Do you get to take any credit for that partially finished product backlog item?
The typical situation is this: A team has worked on what for them is a medium to large product backlog item. The end of the sprint arrives and the item is more than half done, sometimes even nearly done, and the team wants to take partial credit. If it is, let’s say, a user story estimated at 8 story points, they might want to claim 5 points as done.
Don’t let them.
Teams Overstate Progress on Unfinished Work
One of the big problems with partial credit is that teams will usually overstate their progress. Team members think they’re further along than they are.
Overstating progress feels good. An inflated velocity feels good at the moment—like my half-baked chicken—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 predict when the next project will be done. (See agile planning.)
Further, it is notoriously difficult to estimate what percentage is truly complete. Are we 50% done? 60%? That is extremely hard to know and most people overestimate how far along they are.
They don't do it on purpose. Developers think they see the full scope of what’s needed and they are truly 90% done with that. But as they work to finish the last 10%, they realize the solution is bigger than they thought—and even after more work they are still just 90% done with the bigger scope.
We might think we’re 50% done but what that usually means is we are 50% done with the work we see. There is almost always some amount of work we’ll need to do but that we don’t yet see. We haven’t thought of it yet. 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 of the difficulty in estimating percentage complete, I recommend not doing it at all. Product backlog items are either done or not done—no partial credit.
This is analogous to scoring a touchdown in American football. In American football, a team needs to move the ball 100 yards down the field, ending in their opponent’s end zone. Doing so earns a team six points (and the opportunity to earn one or two additional points).
Moving the ball 99 yards earns the team…zero points. No partial credit.
Two Benefits of a No-Partial-Credit Rule
A team doesn’t care if their Scrum Master refuses them partial credit on a one-point story. They do care when they can’t take partial credit on an eight-pointer. In response, many teams will take a we'll-show-you attitude toward the Scrum Master. They then proceed to show the Scrum Master how stupid the rule is by always finishing stories. That's benefit #1.
And to ensure they always finish, in product backlog refinement or the sprint planning meeting, team members split large stories into smaller discrete pieces of work. That's benefit #2.
Focusing on finishing and splitting large items into smaller ones are two things a good agile team does, anyway. So when a Scrum Master, coach, or the agile team itself enforces a no-partial-credit rule, teams work in a more agile manner.
What's not to like!
Is Partial Credit for Backlog Items Ever OK?
But do I ever let a team take partial credit for an unfinished backlog item?
Yes, I do. If a team discovers sufficiently early in a sprint that they will not finish and want to split a product backlog item, I will let them do so. They can split it, re-estimate the split stories, and then count the story that they finish. But they need to do this early enough that it isn’t cheating. A team attempting to split an item on the last day of an iteration is just trying to circumvent the no-partial-credit rule.
I want to avoid setting a hard-and-fast deadline for splitting items and taking credit. But, if pressed, I think a good guideline is around halfway through the iteration.
What to Do with Unfinished Work?
There’s an old saying that coming close only counts in horseshoes and hand grenades. A team coming close to finishing is nice but it’s not enough to earn the team any credit toward velocity. So what do we do with work that is almost finished? Do we re-estimate it?
For answers, read "Should You Re-Estimate Unfinished Stories?"
