We all know that scrum teams are made up of individuals with cross functional skills that commit to completing the sprint backlog as a team. Instead of a traditional Project Manager assigning tasks, the team decides how they are going to get the work done and individuals choose or sign up for the work they want to do.
The challenge faced by most of the teams is Spillovers. And it’s not so uncommon – almost 50% of the teams I worked with had this challenge. There could be a number of reasons causing the spillovers but am not going to focus on them in this post. Instead, let’s focus on how we can get rid of these spillovers.
It’s OK to have spillover when there is a situation that cannot be anticipated even after proper planning. But frequent occurrence of spillovers is a pattern for concern. The Scrum Master, along with stakeholders, plays a leading role to make the necessary adjustments. Spillover might not be completely eliminated from your projects. But with proper management and planning, you can reduce the number of times it may occur and be able to reduce its impact.
If on sprint planning day, the team determines the owner for every task, then it’s very easy for our introverted development teams to go heads down at their desk and only focus on their personal ‘to do’ list. Even though they are having a daily stand up, if they are not truly paying attention to how the team as a whole is tracking according to their plan, then teams can end their sprint with several backlog items partially completed. The team has to own up to the stakeholders during the sprint demo that they didn’t meet their commitment and that walk of shame is no fun.
I would challenge a team who finds themselves in this situation to no longer determine the owner of tasks on sprint planning day. Instead, allow team members to sign up for a task daily throughout the sprint following the swarming approach.
Like when worker bees swarm together to build a new hive, teams should swarm together to work down the prioritized sprint backlog.
On the first day of the sprint, the team should put only the top backlog item in progress until it meets the definition of done. Once the top backlog item is done, then the next backlog item in the list can be put into progress. Based on the size and skill sets of the team, they may find that their WIP limit is to make sure everyone has a task on the first day of the sprint. To help enforce this, the team can set a WIP limit of one or two on the ‘In Progress’ column of their story board. This focus will:
- Keep the team working together closely and will result in less context switching
- Keep the intensity level high on getting impediments resolved ASAP
- Forces the team to test early in the sprint instead of it becoming a bottleneck at the end
- Product Owner can provide feedback, verify and accept a backlog item early in the sprint instead of on the last day
The Product Owner who has three backlog items done and accepted feels a lot better than the Product Owner who only has seven items that are 90% complete.
Discuss the best order to work stories within the sprint and reinforce or adjust those priorities during stand ups. Work the Sprint Board “from right to left,” collectively focusing on finishing open stories before starting another.
I have suggested swarming approach to many teams so far and some of the stuff that went well is:
Teams stopped worrying much about the WIP as long as the sprint goal isn’t in danger. Teams don’t really mind people swarming over all the user stories as long as the goal of getting the sprint is clearly within reach. When possible all team members work together on one user story at the same time.
Some practices I’ve found useful for teams over the yeas are listed below. I know they’re not all strict Scrum, but then again, scrum only works if you apply it within your own domain. For the teams I worked with, these were great practices, with your team it might be a bit different.
- Focusing on the team value more than the value of the individual.
- The team’s goal is the most important thing which means that working together should become easier by time.
- Each user story we have a set of disciplines to attach to, if someone who totally lacks experience in a certain discipline skip the user story.
- I’ve found testers to be quite hard to pitch in. I did involve them earlier by giving them versions almost after one hour already so they can start testing and sit next to you while you solve some of the issues they’ve found.
On one end of the spectrum, only two team members could be working on the same user story, while at the other end of the spectrum, ALL team members could be working on the same user story. Taking the latter example even further, all of the team members could use “mob programming” to focus on solving a particular problem (or completing a user story) together, using a single computer.
Swarming variations:
- Employ swarming on an ad hoc basis, for instance, throw multiple people at a user story when it is critical that it be finished before anything else
- Identify a particular day of the week as “swarming day” for a particular team
What do you think?
Have you experienced spillover on your project recently? How often? and what have you done to prevent it from happening again? I would like to hear from you so please share your thoughts in the comments below.