Swarming: A Team-based approach to getting work done

Philip Rogers
· 3 min read

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

  • 70% percent of user stories 100% done
  • 100 percent of user stories 70% 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
  • Developer-Developer
  • Developer-Developer-Tester …

Any combination could of course be employed. 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 before anything else
  • Identify a particular day of the week as “swarming day” for a particular team

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, especially if a tester is included early in the process.

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

innovative agile techniques and practices

Some people try to draw a box and say "everything inside is Agile." This collection is for those who are willing to paint over and outside the lines.

Philip Rogers

Written by

I love to work with teams to help them improve. Most of my recent experiences are with teams using Lean/Agile approaches (variations on Scrum, Kanban, XP).

innovative agile techniques and practices

Some people try to draw a box and say "everything inside is Agile." This collection is for those who are willing to paint over and outside the lines.