Swarming is a whole new way of getting work done on a team. Instead of taking a “step-by-step” approach to something (which frequently leads to hand offs and inherent loss of continuity and information), teams that “swarm” on backlog items approach items from a “multi-vectored” standpoint — whatever needs to be done is done by whomever needs to do it and at pretty much the same time.

Why Does Swarming Work?

Swarming works because it exposes all of the complexity of the backlog item at the same time. Problems that, in more traditional approaches would surface near the end of the work, now tend to appear in the first few hours of work. Also, teams that swarm form “collaborative information networks,” or CINs. CINs tend to cause the rapid learning and sharing of information across the team, and leads to quick improvements in team performance.

What is Necessary For Swarming to Work?

For swarming to work, the team needs to do the following:

• Backlog Refinement — backlog items committed into the Sprint cannot be larger than what the team can complete in three days of work. Larger than this introduces unnecessary and disruptive complexity.
• Be Willing to Work Outside Your Comfort Zone — sometimes the task that you need to work on isn’t your speciality (e.g., writing or testing or editing).
• Be Willing to Work Together — swarming works best when developers work together on one or more tasks.
• Don’t Pre-Assign Tasks — predicting ahead of time who should work on what task is like predicting the weather. You might be right, but the further out you predict the more wrong you’re going to be. Let developers self-assign tasks when they’re ready.
• Limit Your Work in Process (WIP) — working on more than one or two items at the same time eliminates any benefit swarming can provide. Don’t spread the wealth — reduce overall risk, waste, and complexity by only allowing one or two backlog items to be in progress at the same time.