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. By the way – do you know SPIDR acronym? If not, read User Story defined in 3 acronyms.
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.
One of the possible solutions is to forecast based on the average from several last Sprints (e.g. 10 sprints) – this way short-term jumps in velocity will be smoothened. Assuming that a slipped item will be continued in the next Sprint, you can assess work left (don’t change the original estimate in Story Points though!), and then you’ll know how many new items you can pull in. That way we still sustain possibility to have reliable forecast for the future.
3. Slip to the next Sprint and do re-estimate
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 a strong disadvantage of this approach. Each Item in Product Backlog should be able to be used as a reference for further estimations, while the re-estimated Item cannot. It can also be extremely confusing for a 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.
A possible solution is to include additional information in the re-estimated Backlog Item:
- original estimation which covers the whole scope of an Item;
- info on scope which is covered by re-estimation;
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 and the same time doing with my teams the second 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?
I generally agree but I have a big problem with “why re-estimate?”. As it is written “3. Move to Sprint Backlog but re-estimate, as some work has already been done.” – I do not see this as a valid reason to re-estimate. Relative measures in my opinion do not include “work effort still to be done”, it is only “work effort” (and it is only a part). I see re-estimation valid due to the fact, that we know more about a particular PBI (of any kind). So after a few days of work it turned out that a User Story is way bigger than expected, but some work has aleady been done – if we only take work done into consideration when re-estimating, the estimation should be lower. But we know there is even more to be done than we expected (we were quite sure it will be quite easy and not too complex) and complexity increased (e.g. due to unforseen dependencies). In such case lower estimation does not sound like a reasonable choice.
To sum up – I guess work done is not the reason, the learnings from this work is.
I believe you touched exactly the difference between 2nd and 3rd approach. Especially “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.” The most important is to know the consequences of the approach you will choose. The reasone I believe in reestimation is that it is much easier to plan. Without proper reestimation I saw team doing reestimation only for the purpose of planning – so they had two estimates – one for planning and one for size of Item. Unnecessary complication I believe, cause estimation is all about plannig and forecasting future. And past work is not important. You said that reestimation is valid if “we know more about a particular PBI”. Let’s assume that you realized that some part of the work was done by other team. Will you reestimate or not? Is there any difference who did the work?
“estimation is all about plannig and forecasting future” – and how do you forecast? Usually basing on the past so it is important as well 😉 And no, there is no difference who did the work so reestimation which is based on “now we know more” will be exactly the same no matter who did the work or found out how much more (or less) is to be done.
As with so many things in an agile world my belief is that the context of the team and their reaction to the consequences are the biggest factors in determining which approach will work best FOR THEM. The important thing is that the team experiment, learn and make the choice that fits best for the outcomes sought……and they may want to change their approach as other things change.
For instance if the teams story size is generally large they may take a different approach to if their stories are small or mixed. If they have issues in estimation they may take a different approach to a period where their planning starts to struggle and if there is a need for forecasting that may also play a factor.
Then throw in multiple stakeholders versus internal or external stakeholders and time/material contracts versus fixed price.
Ultimately I agree with the authors decision to experiment with all 3 methods but at the same time would be encouraging the team to find ways of avoiding starting things they can’t possibly finish in the timeframe and use capacity at the end of the sprint to spend time on work they typically don’t estimate.
Agree with everything here. Most important is to understand the context of each particular team and build safe environment in which team will be willing to experiment and learn.