That is the question.
In practice it is quite rare to deliver hundred percent of the Sprint Backlog. In most cases when the Sprint ends there are still some Items left undone – those that do not fully meet your Definition of Done. What should we do with such leftovers? I would like to analyze with You all possible solutions.
I see (and experienced) three possibilities:
- Let’s divide the remaining backlog Item into two – one which is finished and will be part of the current Sprint Increment, and second which is unfinished and will go back to the Product Backlog. In this approach Story Points are split between the two new Product Backlog Items.
Instead of following that approach, some would stick to the Definition of Done, saying not Done means not Done, and move the entire Item to the Product Backlog. Here come another two possibilities:
2. Move to Sprint Backlog and keep the original estimation.
3. Move to Sprint Backlog but re-estimate, as some work has already been done.
1. Let’s divide
It’s in fact the worst possible solution, but at the same time a very tempting one. Development Team may try to argue with Scrum Master to convince him or her it’s the right thing to do.
Hey, we finished development for this, only testing is missing. Let’s create an Item for testing for the next Sprint.
We spent 8 days on that and we only need to prepare the user manual – like 3-4 hours of work. Come on, we will finish it by the end of the first day of next Sprint! We even don’t need a new Backlog Item for it.
It’s 13SP and only couple of unit tests are missing. Work left is only for 1SP. Let’s have 12SP Item in this Sprint, which we can close, and let’s put a 1 SP technical debt Item in the next Sprint. We will clean it up then!Development Team Member
Have you been involved in such conversation as a Scrum Master? Or maybe you were the one providing such arguments? How many times have you agreed to bend the Definition of Done?
It can be seen as a small and innocent step at the beginning, but in fact it’s a very dangerous one. It’s like starting with a small hole in a solid wall – you can live with one or two and can also easily fix them, but having tens will weaken the construction and may cause its collapse.
Bending the Definition of Done to account few Story Points is also addictive, especially when your Team’s velocity is being observed by stakeholders closely.
Remember it’s the Development Team who should guard the Product quality! (see to quality vs quantity).
We would also have 12SP more Velocity if we agree to have technical debt task of 1SP in the next Sprint. And it is closer to reality, because truly we already delivered these 12SP.Development Team Member
Is that true – did the team deliver those 12 SP? Definitely not, the item is not Done. Then how do you know that the 1 SP that is left will be enough to finish the task? I observed many times teams saying that they would finish leftovers within 1-2 first days of the next Sprint, and then working on them for 1 or 2 full weeks.
Putting a bit different light on this approach, there is one situation in which I would agree to divide a leftover Item into two smaller pieces. Sometimes Development Teams are not creating their Backlog Items properly, putting sub-task which are independent from the business value perspective under one Item instead of creating separate Backlog Items. Be careful with the approach though and mind if the below conditions are met:
- Item is possible to be divided into two (or more) separate, independent Backlog Items
- And each separate Item brings business value to system users
- And one (or more) such Items are finished according to Definition of Done (no reduced tariff!)
You can use this method few times to encourage the Team to split Backlog Items in a different way already during Backlog Refinements, and not at the end of the Sprint.
Nevertheless, this is just an exception – as a rule you should reject this possibility, because it is very harmful.
2. Slip to the Product Backlog and do not re-estimate
We don’t want to re-estimate it, because that way some of work done by us will not be visible in Velocity.Product Owner
That’s the most common argument for this approach. First an unexperienced Development Team will try to fight with Scrum Master for ‘Let’s divide’ way. Slip to next Sprint but do not re-estimate will be probably their second choice. Reason they have is pretty good. But the question is – what do you use Velocity for? Is it for tracking the past? For reporting how the team is doing? Or rather… for trying to predict the future?
For me Velocity is a tool which should be used during Sprint Planning to properly estimate how many Product Backlog Items we can take to the next Sprint.
If that’s the case, this approach may create some mess and blur the reality – there is a risk that your Velocity will wave significantly from Sprint to Sprint. By moving Item from one Sprint to another without re-estimation you are virtually transferring between those Sprint the work already done by the team. 12SP done in Sprint 1 will be virtually transferred to Sprint 2, and Velocity in Sprint 2 will skyrocket. Graph presenting Velocity Sprint by Sprint in team using this approach is presented below.
It is very hard to plan next Sprint when you have such Velocity.
I don’t want to re-estimate Items, because it will create mess in my estimation process. We won’t be able to refer to re-estimated Items.Scrum Master
Fair point. This is strong advantage of this approach – each Item in Product Backlog can be used as reference for further estimations. The re-estimated Item cannot. It can also be extremely confusing for new team members or people from outside the Scrum Team – they just don’t know what happened and can deliberate why this Backlog Item is estimated much lower than the others.
3. Slip to the next Sprint and do re-estimate
We should re-estimate, because we need to know how many Items we can take in the next Sprint. So we need to know what is still left in each Item. Done part is not important.Scrum Master
Focus on the future. As I mentioned – Velocity is a tool for Sprint Planning and future predictions. Information how much work is left is most valuable here.
Even when you read Scrum Guide carefully you won’t find a direct answer to how you should proceed with leftovers. Still there is one part which seems to give us a clue – one on Canceling a Sprint says:
When a Sprint is cancelled, any completed and “Done” Product Backlog Items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.
Sprint in which the Team didn’t finished everything from Sprint Backlog or even didn’t achiev the Sprint Goal is very similar to the cancelled Sprint, isn’t it?
In both cases some work is Done, some is not Done, and so some of the Items are pushed back to the Product Backlog. In both cases you are not sure whether unfinished Items will become part of the next Sprint. When the Sprint was cancelled it is rather unlikely, but when the Sprint ended properly it is very likely. Just that it is not a rule. Maybe the Product Owner will decide to switch to another topic and unfinished Items won’t be part of the next Sprint? Maybe there was only a short timeframe to deliver functionalities and now they are useless? Who knows.
As a general rule you should not assume that leftovers from one Sprint will automatically go into the next one.
They go back to the Product Backlog and are prioritized by Product Owner along with all other Backlog Items. Same as it would be for a cancelled Sprint.
This approach assures that all Items in Product Backlog are properly estimated and only real work needed to deliver them is considered. The same team, whose Velocity I presented above, decided to switch from not re-estimation approach to the re-estimation approach after Sprint 8. Velocity became much more predictable – compare chart below – and planning was way easier.
What I really like here is also that it pushes the Development Team into good direction. They will notice that some of their work is not visible in Velocity, so also possibly not visible for stakeholders and other parts of organization. They will feel uncomfortable with that and they will be much more determined to properly divide Items – the smaller the better. With small Items you’re also eliminating temptation for the first approach: ‘Let’s divide’.
Just remember that with this the 3rd approach, some work done by the team won’t be visible in Velocity. If a really big Item slips and you re-estimate it, then the Velocity will be impacted strongly and possibly will be lower than in reality. Remember about that during Sprint Planning.
I was doing all three approaches (yes, even the worst one) and currently I’m for the third one. But of course… everything depends on the context and situation you’re currently in. Which of the three do you use, or maybe you know yet another approach that could serve the leftover challenge?