During sprint execution, it’s the development team’s responsibility to manage the flow of work to meet the sprint goal. One important flow-related decision a self-organizing team must make is how many product backlog items the team should work on in parallel to maximize the value delivered by the end of the sprint. As a general rule, team members should swarm to the fewest viable number of product backlog items at one time. To demonstrate why that’s true, let’s look first at other options: working on too much at once and working on too little.
Bad Strategy #1 – Work on Everything at Once
Let’s assume that the development team has agreed to complete eight items this sprint. Let’s also assume there are eight members of the development team (some developers, testers, UX, database, and other skills). The question, then, is how many of the eight items should the team members simultaneously work on when sprint execution begins?
What if they start working on all eight? By that I mean, they “assign” each product backlog item to individual team members and ask everyone to start working on his or her assigned item immediately. Would that allow the team members to maximize the amount of work they complete? The short answer is probably not. For many different reasons, this would likely be a bad strategy.
First, it is rarely true that one person could complete a story unless we permit people to do final testing of their own code. Second there often are dependencies that exist among the product backlog items that make working on them in parallel impractical. Also, there could be a critical skill (say UX) that is needed on several of the stories so it is likely that the team could not realistically work on all of the stories at the same time given insufficient capacity of a critical skill.
Working on all of items at the same time might be a great way of keeping people busy, but it is a poor way of getting things done. And our primary goal should not be to keep everyone 100% busy (see Chapter 3 of Essential Scrum). In fact, if the team is working on too many items at once, team members will spend significant time multitasking, which in turn increases the time required to complete individual items and likely reduces their quality. So, working on everything at the same time is likely a poor strategy.
Working on all items at the same time might be a great way of keeping people busy, but it is a poor way of getting things done.
Bad Strategy #2 – Work on Too Few Items at Once
Just as working on too many items at the same time is wasteful, working on too few items at a time is also wasteful. It leads to underutilization of team member skills and capacity and to potential work interference, all of which result in less work being completed and less value being delivered.
Imagine, for example, the same eight team members commit to deliver the same eight items, but this time, they decide to work together on only one item at a time. The UX and database people, the developers, the testers—all committed to complete the first item before anyone moves on to the next. Wouldn’t that be the epitome of team collaboration? Perhaps, but this is likely another bad strategy.
There are several potential problems that can result from having all team members work on the same item. First, certain items may not require a particular skill. Let’s say an item has no database work associated with it; unless the database developer has some T-shaped skills what would she do on that story? Though the goal isn’t to keep everyone 100% busy, neither is the goal to underutilize people to the point of being wasteful.
Plus, even if everyone were somehow able to work simultaneously on one item, they’d likely be in each other’s way much of the time. What if the team has three Java developers and the item really only needs a single Java developer? By analogy, think of eight people trying to dig the same 6X6 ditch at the same time. It’s more likely that people would be accidentally whacking each other in the head with shovels than making any real progress on the ditch! While there might be rare occasions when swarming on one item makes sense, in general, working on too few items at the same time is just as bad as working on too much at once.
Though the goal isn’t to keep everyone 100% busy, neither is the goal to underutilize people to the point of being wasteful.
Swarm for Balance
So, is there a way to gauge how many items to work on simultaneously? Yes. I recommend that teams swarm to the fewest number of items that leverages, but does not overburden, the T-shaped skills and available capacity of the team members, while taking into account the dependencies that might exist among product backlog items. That was quite a mouthful; so let me break that down a little.
By swarm, I mean that team members with available capacity and the skills necessary to accomplish at least some work remaining on an item, help to complete unfinished items as opposed to moving on to new items that might better match their primary skillset. Teams with a Musketeer attitude (all for one and one for all) and some degree of T-shaped skills swarm in order to reduce the time required to complete individual items while maximizing the total value delivered during the sprint (typically the number of items completed during the sprint).
I recommend that teams swarm to the fewest number of items that leverages, but does not overburden, the T-shaped skills and available capacity of the team members.
The alternative is for team members to finish “their items” and then move on to the next, without regard for items that are still in progress. This happens frequently on teams that still think in terms of individual roles. A classic individual-role-focused thought is “The testers might still have their work to finish up, but I’m finished coding this feature, so I’m off to start coding the next one.” Instead, it is typically better to stay focused and help get the testing done instead of running ahead to start working on new features.
Teams that fail to swarm at all tend to wind up near the end of the sprint with some members far ahead and others who are mired in unfinished work. Teams that do swarm, on the other hand, remain goal focused instead of task focused, which means the team gets more things done, faster.
With all that being said, as demonstrated in Bad Strategy #2, while swarming favors working on fewer items concurrently, it usually doesn’t mean working on only one product backlog item at a time. That typically is not practical. Instead, self-organizing team members should swarm to and work on the fewest number of product backlog items that it makes sense to do at once. As I mentioned earlier, the fewest viable number takes into account the actual work that needs to be done, the skills of the team members, and other conditions, including dependencies, that exist.