Should a Team Swarm on to One Backlog Item at a Time?

This week I want to address the question of whether a team should work on one product backlog item at a time or whether it's OK to work on multiple items. In general, a team should feel comfortable working on multiple product backlog items at the same time during an iteration.

A typical seven person team will plan between five and ten items into an iteration. They'll usually be closer to the low end of that range with a one- or two-week iteration and closer to the high end with a four-week iteration. Perhaps surprisingly, though, iteration length has less influence on the number of product backlog items selected than you might think. It seems that teams with longer sprints simply have larger product backlog items. A seven-person team will rarely be at its most efficient when all team members swarm onto a single product backlog item. There's too much opportunity for them to get in each other's way for this to be a good long-term strategy. However, an entire team swarming onto a single product backlog item can be a very effective learning technique and one that I often encourage.

If you are part of a team that hasn't yet learned how all disciplines can work well together, limiting the entire team to one product backlog item in progress at a time is something you might want to try. This forces people to quickly learn ways to work in small batches so that work can, for example, be transferred from programming to testing in multiple tiny increments. Similarly, if you are on a team where each developer grabs a product backlog item and works independently on it throughout an iteration, a rule of "only one item in progress at a time" is a good way to experience the benefits of working in smaller batches.

So, while I think swarming in this way is an excellent technique to use sometimes, I don't think it should be the default way of working for very many teams. Some may benefit from it over the long term, but most will find that it introduces too many opportunities to be in someone else's way as they try to make progress. I consider it equivalent to a drill that a team may do to improve a skill--good to use for practice but not the way to do something forever.


A Free PDF to Help You Choose the Approach

A Free PDF to Help You Choose the Approach

I’ve created a PDF you can download that will help you decide which approach is best for any story you’re adding detail to. It also includes examples of the two approaches.

Download my PDF
Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.