One of the most common debates among Agile and Scrum teams is whether to include partially finished work in their sprint velocity. Many teams reach the end of a sprint with some user stories almost done, maybe 80% or 90% complete and feel they deserve partial credit. However, as tough as it sounds, the answer is no. In Agile, “almost done” is still not done. Velocity should only count items that are fully complete and meet the Definition of Done (DoD).
Why Partial Credit Damages Accuracy?
Imagine this: I invite you for dinner and serve you half-cooked chicken. It might look fine, but you’ll regret it later. The same goes for partial credit in Scrum. It may feel satisfying at the moment to show higher velocity, but it will create confusion and inaccuracy in long-term planning. Velocity represents the amount of work a team can reliably deliver in a sprint. If teams take partial credit for unfinished stories, they distort that reliability. The next time management or stakeholders use that inflated number for forecasting, the project timeline could go completely off track.
Why Teams Shouldn’t Take Partial Credit?
Scrum is built on transparency and honesty. Taking partial credit breaks both. Let’s explore why:
Teams Often Overestimate Progress
Developers are optimistic by nature. When they say a story is 90% done, it often means they’ve completed 90% of what they can see right now. But once they start testing or integrating, they realize there’s more hidden work, bug fixes, data handling, validations, or design tweaks. So that “90% done” might actually be just 70% or even 50%. That’s why partial progress is misleading.
It Creates False Confidence
An inflated velocity might look impressive for a sprint or two. But later, when future sprints are planned based on those false numbers, deadlines will slip and trust will erode. Stakeholders might start believing the team is inconsistent or underperforming when the real issue is incorrect measurement.
It Weakens the Definition of Done
One of the core principles in Scrum is maintaining a clear Definition of Done (DoD). If teams start taking partial credit, that clarity fades. Soon, “done” might mean “coded but not tested” or “tested but not deployed.” This confusion can lead to quality problems and rework.
All or Nothing – The Scrum Way
In Scrum, a backlog item is either done or not done.
There’s no “almost done” in the velocity chart. Think of it like football (soccer) or American football — moving the ball 99 yards doesn’t earn any points. You only score when you cross the goal line.
This strict “no-partial-credit” rule might feel frustrating, especially when a large story is just one step away from completion. But it offers two major benefits:
Teams Focus on Finishing Work
When partial credit isn’t allowed, teams make sure they complete every item they start. They work smarter, plan better, and collaborate more to finish tasks on time.
Teams Learn to Split Stories
Large stories are harder to finish within a sprint. When teams face this challenge, they start splitting large stories into smaller, manageable pieces during sprint planning or backlog refinement. This makes progress visible and realistic a hallmark of good Agile practice.
Is Partial Credit Ever Acceptable?
Yes, but only in specific cases, and only early in the sprint. If a team realizes early on (say, halfway through the sprint) that a story is too big to complete, they can split it into smaller stories. The smaller story that gets completed can be estimated and counted toward velocity.
However, doing this at the end of the sprint just to claim velocity points is not acceptable. That would be like “cheating the system.” The key idea is transparency, the decision to split and re-estimate must be made genuinely and early enough to maintain the sprint’s integrity.
What Happens to Unfinished Work?
If a story isn’t done by the sprint review, move it to the next sprint’s backlog. The Product Owner and team can decide whether to re-estimate it (if the scope has changed), or Keep the original estimate and just finish it. The unfinished story doesn’t count toward the completed sprint velocity. But that’s perfectly fine, velocity averages out over time, and keeping it honest ensures long-term predictability.
Why This Matters for Agile Teams
Avoiding partial credit helps Agile teams:
- Build trust with stakeholders
- Deliver more predictable results
- Maintain quality and transparency
- Strengthen sprint discipline
A true Agile mindset values progress that is complete, tested, and valuable to users. Half-done work doesn’t deliver value and Agile is all about delivering value every sprint.
Agile success depends on honesty and discipline. Counting unfinished stories in velocity might feel like a small compromise, but it can lead to big issues in planning and delivery. At HelloSM, the best Scrum training institute in Hyderabad, we teach Scrum Masters and Agile teams how to apply these principles effectively in real projects. As the top training institute in India, HelloSM focuses on practical learning that helps you make smarter, data-driven decisions without cutting corners. Remember, in Scrum, done means done. That’s what keeps your team reliable, predictable, and truly agile.
Frequently Asked Questions
Why shouldn’t teams take partial credit for unfinished stories?
Taking partial credit gives a false impression of progress and makes velocity unreliable. It reduces the accuracy of sprint planning and long-term forecasting.
What should be done with unfinished work at the end of a sprint?
Unfinished work should be moved to the next sprint’s backlog. The team can re-estimate it if needed but should not count it toward the current sprint’s velocity.
How can HelloSM help Agile teams improve their Scrum practices?
HelloSM, the best Scrum training institute in Hyderabad, offers expert-led courses that focus on real-world Scrum application, helping teams improve velocity tracking, sprint planning, and delivery predictability.