Swarming in Scrum
Swarming is the act of all development team members working on only one requirement at a time during the sprint. Although not a principle specific to scrum, it is such an effective way for teams to execute their sprint backlog that it warrants some more discussion.
Again, one of the main benefits of scrum is that development teams start and finish requirements to satisfy their definition of done to produce a potentially shippable product increment within a relatively short timebox, and to repeat that cycle with lessons learned again and again. The goal is to finish, not just start, as many requirements as possible.
Swarming enables teams to enjoy the following benefits:
Maximized chances for success with the skills and abilities of the entire team focused on a single requirement.
Complete the entire cycle of plan, design, develop, and test to completion for each requirement.
Resolve issues and impediments today, in the now.
Dramatically decrease the introduction of defects into a product up front through pairing and single‐tasking (versus multitasking).
Eliminate single points of failure in knowledge, process, and skillsets.
The most important requirements get done, done completely, and get done first.
When team members see all their fellow developers working on a task, and none are left for them to work on the same requirement (the user story), it’s perfectly natural for them to consider it more productive to go start on a new requirement rather than help the others out on the current requirement in progress. However, this tendency can get out of hand to the point where teams find themselves with multiple requirements started, but none of them finished. By shadowing, pairing, researching, or helping in whatever way gets the task to done, development teams will avoid this risk.
Stay focused. Stop starting and start finishing.
This process ensures that in every sprint, something will get completely developed and be available to show stakeholders. Every sprint will produce “shippable” results. The development team’s efforts are focused, their teamwork is enhanced in that they’re encouraged to help each other, and the iterative process of scrum is put into play.
Recently, Microsoft conducted a study on the effects of multitasking. The results were that multitasking just doesn’t work. On average, it takes 15 minutes to get your brain back to the level it was at before you answered that phone call or email. Studies have also shown that an interruption as short as 4.4 seconds will triple the number or errors made on subsequent tasks requiring sequencing. Reducing multitasking in your development team will get you a sound head start on achieving the 30–40 percent increased product-to-market time.
Thrashing is when developers jump back and forth between projects, requirements, and tasks — context switching. Thrashing increases the time required to complete tasks by 30 percent. If you don’t have enough people to take on the workload as dedicated, swarming developers, you definitely don’t have time to thrash them.
If a requirement placed in the Accept column is rejected by the product owner, the developers have several options:
Finish their current tasks, and when those are finished, they swarm the rejected requirement.
This might be the best option if plenty of time is left in the sprint to complete the current tasks and the rejected requirement.
Abandon their current tasks to swarm the rejected requirement.
This might be the best option if not much time remains in the sprint to finish both.
The product owner decides the priority when faced with this decision. Other variables than time left in the sprint may influence the product owner’s decision. As the team inspects their learning and adapts throughout a sprint, the rejected story may become less valuable to achieving the sprint goal than the next requirement in progress, and so even though time is left in the sprint to do both, the risk of not finishing the in-progress requirement might be higher than not finishing the rejected requirement.
In any case, attention to priority and close daily coordination with the product owner throughout the sprint keep the entire scrum team (including the product owner) on focus and on task, literally.
Scrum teams should always be pushing themselves. If development teams accomplish 100 percent of their sprint backlog every time, they may not be pushing themselves to their limit. A high percentage of sprint backlog completion should be the goal, but it should not be expected that scrum teams will hit 100 percent every time. As development teams push themselves, scrum masters, like aeronautical engineers, help the scrum team find ways to reduce drag to become more effective and accomplish more in each sprint. As long as teams are finishing what they start each sprint and increasing velocity, they are realizing the continuous-improvement benefit of scrum.