Unfinished stories do not count toward the team’s velocity
We focus on when the team completes the work, not on when the team is working on it.
Arguments
Predictability (for planning): By not counting unfinished tasks, you get a more accurate measure of what a team can complete in a sprint.
When you partially count unfinished tasks, you measure how much the team can be working on. If you want to know this, you can rely on a time tracking system.
Motivation for completion: It promotes the mentality of completing stories.
Simplified measurements: Collecting data is easier. Interpretation of the data is easier.
No need to split, discuss, and re-estimate stories during planning.
Focus on completion: Communicates that delivering value is more valued than work in progress.
Automatic correction mechanism
Now the impression may arise that the team has done work but it is not visible. This may seem unfair to the team.
Fortunately, this is automatically corrected in the next sprint when the story is completed. Those few effort points that were not added to the velocity in the previous sprint are now included in the velocity for the new sprint. Bonus points! The work was already partially done.
This is why we look at the average velocity of the last x sprints when planning how much we can take on in the next sprint.
References
- Velocity driven sprint planning - Mountain Goat Software
- Should You Re-Estimate Unfinished Stories? - Mountain Goat Software
- The Power of Small Wins - Harvard Business Review
- 3 things to do with an unfinished user story - YouTube Short
- The Planning Game - Clean Coders