Swarming: A Team-based Approach to Getting Work Done

Which of these sounds like a more desirable outcome at the end of an iteration?

• 70 percent of user stories 100 percent done
• 100 percent of user stories 70 percent done

It’s hard to imagine too many customers or other stakeholders who would be happy with the second option. The purpose of this blog post is to provide some simple advice about ways for team members to work together to get user stories to done.

Swarming Defined

In the most general sense of the term, it can be said that a team is starting to swarm any time that more than one team member is working on the same user story at the same time.

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 patterns (sample combinations)

On teams where team members have specific roles, here are examples of swarming patterns that could be applied:

• Developer-Tester
• Developer-Designer-Tester
• Analyst-Tester
• Developer-Developer
• Developer-Designer-Data Scientist …

Ideally, team members will discover their own swarming patterns that make sense in their context. There is no one “right” way to swarm.

Swarming scenario

Let’s say that a particular user story has five tasks associated with it.

A common approach for a Scrum team during Sprint Planning is to assign the tasks by saying a particular person takes on tasks 1–2–3 (often a developer), and another person takes on tasks 4–5 (often a tester).

A different way to approach the same scenario (a user story with five tasks) would be to list the tasks, identify ALL the team members capable of handling the various tasks, and agree on an approach on how to attack the work. The larger the number of people who are identified, the larger the number of potential swarming variations a team could choose to employ.

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 right away
• Identify a particular day of the week as “swarming day” for a particular team
• Identify “swarming themes,” for instance, to pay down technical debt or address other areas that might not get consistent attention, like web security
• Periodically execute exploratory tests in pairs or other small groups

What are some advantages of swarming?

• Broader team understanding: Having more than one person work on a user story at the same time avoids situations where team understanding is mostly limited to a subset of what’s being built (which in practice means only having an in-depth understanding of the particular user stories any given team member might touch).
• Real-time code review: By having more than one developer working on a user story, you are essentially getting a real-time code review.
• Potential time savings: It might seem counter-intuitive, but with multiple people involved early there is a lower likelihood that there will be a need for rework later.

What bad things can happen if teams do not swarm?

• Having a large number of user stories in development at the same time (high work in progress number [WIP] almost always results in completion of fewer user stories during an iteration
• The team is less likely to be able to achieve continuous flow

Note: For an additional perspective on the pernicious effects of trying to work on more than one thing at the same time, along with examples of techniques that can help prevent a “flow buffer overflow,” see a fact sheet that I wrote about the Zeigarnik Effect, which is published on the Excella Insights blog.