Velocity is a complementary practice many Scrum Teams use to plan future work. Here’s how it works: A team selects a point system and decides that certain types of work are worth one point and other types of work may be worth different point values. Every Sprint, the team adds up points for each Product Backlog item (PBI) that meets the Definition of Done by the end of the Sprint. The team's Velocity is the total sum of all of the points associated with PBIs that meet the Definition of Done by the end of the Sprint.
Velocity can be a helpful metric. Teams can use Velocity to predict how much work they may be able to accomplish by two or three Sprints from now. Velocity can even be used to predict future value delivery more than two or three Sprints out. In addition, Velocity can guide the team in determining how much work to pull into the Sprint Backlog for an upcoming Sprint.
But Velocity is also problematic because it is often misused. Many leaders—and even Scrum Teams—mistake velocity as a measure of success. For example, leaders think that if a team’s velocity increases, they deliver more value, which is not necessarily the case.
Another way that velocity can be misused is when teams decide to “cash in” on Product Backlog items that don’t meet the Definition of Done.
What is “cashing in”?
“Cashing in” means that a team decides that even if a particular PBI doesn't meet the Definition of Done by the end of the Sprint, the team should “take credit” for part of the points associated with that PBI in the current Sprint because they spent time working on it.
Here’s why “cashing in” is not a good idea. Velocity is intended to provide teams with a clear understanding of how much work they can realistically accomplish within a Sprint. By tracking the amount of backlog converted into a potentially shippable product increment, teams can make informed decisions about the scope of future sprints. However, when Velocity is polluted with undone work, it becomes a less reliable indicator of the team's capacity and performance.
So why do teams do it?
Teams often “cash in” on Product Backlog items when they lack an understanding of the purpose of Velocity. Velocity is not supposed to be a measure of success. It is a planning tool, and nothing more. Rather than “cashing in,” teams must prioritize adherence to the Definition of Done and resist the temptation to inflate Velocity artificially. This requires a commitment to quality and transparency at every stage of the development process. By ensuring that PBIs are truly complete before being counted towards Velocity, teams can maintain the integrity of their metrics and make more informed decisions about future iterations.
Conclusion
"Cashing in" on undone PBIs undermines the effectiveness of Velocity as a planning tool. Agile teams must recognize the importance of adhering to the Definition of Done and strive to maintain the integrity of their metrics.
Did you know that velocity is not the only way to use past performance to predict future delivery? Many Agile teams are increasingly turning to flow metrics - or the number of Product Backlog items completed per Sprint - to predict future value delivery. Signup for Rebel Scrum’s Professional Scrum with Kanban course to learn more.