On a recent project, I was conferring with another experienced Scrum Master when we discovered a small but significant difference between our thinking around how to manage carry-over stories. I’d like to ask this audience – what is your preferred method – and why?
The Scrum guide tells us that teams must deliver “potentially shippable product increments” each sprint – but what happens when they don’t? What should a Scrum Master do - in terms of planning - when a story has been worked on, but not completed?
Usually the story is still at a high priority and so is ‘carried-over’ to the next sprint – simple right? …but one question – what is the estimate for that story?
When planning a sprint, the team should look to their capacity and select the priority stories that can fill that capacity. But what happens when a carry-over story is brought from a previous sprint? It turns out my friend and I had different methods. Let me illustrate these methods and their implications:
Method 1: The estimate is the same as before, no matter how much work was actually done in the previous sprint – e.g. if it began as 8 story points (sp), the estimate remains 8.
Pros: don’t need to re-estimate, the product backlog doesn’t change – easy!
Cons: This doesn’t reflect reality i.e the velocity figures skewed. The team might not reflect on estimates, and their estimates may become devalued.
As the carry-over story will be completed quickly (only 1sp left), The team then can either
a) plan more stories in the planning meeting (in spite of velocity)
b) Wait until these stories are done and plan more at the end of the sprint
c) Do nothing and let the carry over story cover a gap in their velocity this sprint.
While this seems the easier method, everyone has to remember that the 8sp was a carry over, and adjust velocities and release plans. If you are using Jira or another tool, then this can be a pain each time you show a report etc. There is also a danger that estimates themselves become devalued, as they don’t change when the story is replanned. These are less than optimum behaviours here, which is why I don’t prefer this method (although I have used it).
Method 2: Re-estimate the work remaining e.g. 1sp – and use that to plan the next sprint.
Pros: accurate velocity (both average & individual sprints), burndown charts etc. reflect reality.
Cons: The team has to re-estimate what is left. The Product Backlog and release plans are updated.
This is the method I use as it reflects reality and keeps everything visible and gives an easy start to a conversation about the story, its issues, and its plan. However, when I do use it, the team often feel they have ‘lost’ points: they worked on an 8sp story, but now only get 1sp. This is true – and it’s also fair and good discipline. They may have worked on the story, but it is not delivered, and that means no points!
The Role of Scrum Master
One of the Scrum Master’s responsibilities for the team is to ensure Scrum is enacted well, and that the team is improving. That relies on having transparency of both good and bad stuff that happens. When a team has not performed as expected, reflecting on carry-over work is the opportunity to review their estimates - to uncover any issues with a view to improving them and dealing with any issues.
The team may not like the fact that their work has ‘lost points’, but then that’s what non-delivery is – the team should be mature enough to account for their work and be held responsible. This must not be seen as blaming, but of being responsible. After all, the team is given responsibility for the estimates and for carrying out the work. If something goes wrong, it needs to be highlighted and addressed by the team.
These are the methods my friend and I discussed, but what does the wider Audience prefer, and why? Are there other options? I’d love to hear your comments – or click ‘like’ if you were interested in this issue.