Spill-over or carryover items are common in many teams. Unfortunately. Focusing on avoiding spill-over can have a positive impact on the team and team dynamics. This article provides insights into what spill-over is, why it’s important, how to prevent it, and what not to do to avoid it, along with strategies for measurement and improvement.
What does spill-over mean?
Spill-over refers to items that have been started but have not been finished at the end of the Sprint. Spill-over does NOT refer to items that were not started even though they were selected in the Sprint — these are sometimes referred to as items thrown out of the Sprint.
Consider the following scenarios:
A team picks up 4 items in Sprint Planning 1. They start all 4 of them, but then only complete (done) one of them in the Sprint. The other 3 they plan to continue the next Sprint. Spill-over is 3.
A team picks up 100 items. They start 1 of them and get it done. 99 of them they never started and are not completed at the end of the Sprint. Spill-over is 0.
A key point here is that spill-over does NOT relate to the amount of items a team selects during a Sprint. Hence, picking up less items to try to reduce spill-over is interesting but not likely to actually have an effect :)
Why is spill-over important?
Spill-over is an important measurement for 3 reasons:
Agility/flexibility. Ability to change directions every Sprint as there is a no work-in-progress point
Originally, in Scrum, Sprints were described as small projects that are treated independently. In between the Sprints (and preferably, all the time) the product ought to be in a shippable state and there should be no work in progress so that the Product Owner can re-prioritize based on the current situation. Spill-over practically doesn’t give the Product Owner any choice, the same items need to be continued.
Spill-over is caused by some team habits.
There are not many good reasons to have spill-over at the end of the Sprint. The most common causes for spill-over is that (1) the team members work individualistic and have many items in progress at the same time, (2) this goes hand-in-hand with using spill-over as a buffer to stay within your comfortable knowledge area, to avoid learning, or (3) the items selected in the Sprint are too large.
Spill-over suggests difficulty of working incrementally and a need to improve engineering practices.
Within a Sprint, team members work in small incremental steps that are integrated and tested continuously. When the team members do not work incrementally, then the chance of spill-over increases due to integration problems or other hidden surprises.
How to prevent spill-over?
So, what are ways that teams prevent or cope with spill-overs?
Have this discussion within your team. As a team, you have the goal for your Sprint, which is either a Sprint Goal or selected items. How do you work on these as a team in a way that avoids having spill-over. Examples below.
Limit the amount of work-in-progress. The best teams I’ve worked with tried to work one item at a time during the Sprint. This dramatically increased team collaboration and learning. Spill-over became an exception.
When you try to limit the amount of work-in-progress, then you will end up working out of your knowledge area. That is not always easy. Adopt practices such as pairing or mobbing that will make it easier to learn together.
Tasks in a Sprint Backlog become coordination boundaries. Sprint Planning Two, in essence, is a software design meeting where the team talks about how they are going to implement the selected items. One outcome of that in-depth software design discussion is fine grained tasks. These enable the team to work one item at the time. Use the time in Sprint Planning 2 to talk, in detail, about the design. You’ll find you’ll learn a lot from that also!
Have a status check during the Sprint. Commonly this is 2 or 3 days before the end of the Sprint, usually at the end of the daily, where someone asks “Ok, we have 2-3 days left, how does it look? What can we (not) complete?” This is where the team can decide what to focus on to finish or what other actions to take.
Split items during the Sprint. When you discover an item is larger than expected or the item left is too big to fit in the rest of your Sprint, split it! It is fine to split items inside the Sprint. You update the Product Backlog, inform the Product Owner, and pick one for in the Sprint and the other goes back on the backlog. Obviously, this split is a customer-centric end-to-end split and not a task split (unless you had a task in the first place).
When you do have spill-over, take it in the Retrospective. How did that happen? How can we work differently to avoid this?
Split items in the refinement. I would recommend to split so that a team can take roughly 4 items per Sprint. No need to split as small as possible.
What not to do to avoid spill-over?
Pick up less items in a Sprint. I mean, this doesn’t harm, but it isn’t useful either :) Spill-over is not related to the amount of items you selected, so it will have no impact.
Take shortcuts to finish an item. When this happens you are solving something bad (spill-over), but introduce something much worse. Having high quality ‘done’ work is more important than reducing spill-over. Reconsider how you work as a team but do not rush. Also, when you see this happen in your team, please speak up as you and the rest of the team will need to deal with the result of shortcuts on the long-run.
Conclusion
Spill-over measurements can be good agile health metrics. In my experience, focusing on reducing spill-over always eventually has a positive impact on the team and team dynamics. Initially the focus on spill-over often triggers questions. These are great learning opportunities for you, take them serious and engage people in the conversation. Hopefully this post helps you and the teams in that conversation.
Credits
This article was originally written in Wartsila context and they allowed me to publish it here. Thanks to Jowen Mei and Ronald van Miert for edits to the post.
RSS feed