One of the most common questions asked in Scrum classes and coaching is how to handle backlog items that don’t get finished in a sprint – where do we credit the ‘work done’ for unfinished backlog items?
While it’s understandable to want to allocate credit for the effort spent to the sprint to which it ‘belongs’, it’s important to remember why there’s no partial credit in Scrum: Because working software is the primary measure of progress (#7 of the principles behind the Agile Manifesto). The metric of record is therefore how much a team can complete to potentially-shippable quality each sprint, not how much they can complete to 90% finished status. This is a common occurrence with new Scrum teams. By the end of Sprint, they have a whole bunch of backlog items “90% complete” (whatever that means), which means they’ve got nothing done to potentially-shippable standard, which means they’ve delivered zero business value. In other words, they’re 0% done.
Attempting to ‘give credit where it’s due’ by tracking how much work was performed in which sprint skews the emphasis toward measuring how hard people tried to reach a goal, which isn’t what we want. We want to measure the goals reached: backlog item story points competed per sprint, or business value delivered if you’re using that metric.
The most common recommendation is that an unfinished backlog item gets returned to the product backlog, with its original estimate intact. When it gets committed to a new sprint and completed, the backlog item’s full effort estimate gets credited to the Velocity of the new sprint. While this may appear to skew the numbers, the numbers average out over time – and it’s this average velocity that a PO uses for forecasting and planning. Moreover, this practice adds an incentive for the team to do their best to discuss, negotiate, estimate, and commit to finishing backlog items to full completion in a sprint.
If management and finance want to track costs for purposes outside of managing a team (one that doesn’t need managing because it’s self-organizing) – say, for hourly client billing – then a task-level metric might be used. A carried-over backlog item’s constituent tasks done in the first sprint will remain counted as tasks completed (or task hours completed and remaining if you’re using those metrics) as part of graphing the sprint burndown in any good agile project management software such as ScrumWorks Pro.
This is a not-uncommon business need, although the practice is easily abused to “manage” agile teams’ “productivity”. The danger here is that it leads to a mentality (to use a relay-race analogy) of tracking the runner rather than tracking the baton. In Scrum it’s the baton that’s important – that is, story points of backlog items done to potentially-shippable completion each sprint (Velocity). Since ultimately that’s what we care about, then that’s what we should spend our expensive, limited time encouraging and focusing on.