Everyone for Themselves

Todd worked with a Scrum team where, at the end of sprint planning, development team members would choose and self-assign which product backlog items they were accountable for accomplishing during a sprint. The team members would then go back to their desks and each person would focus just on their PBIs, and had little interaction with other team members.

The team’s daily scrum conversations centered around individual developers updating other development team members on what progress they’d made on their PBIs, while other team members barely listened while awaiting their turns. Many sprints passed without the team completing their sprint goal. On the team’s Scrum board, almost everything sat in the in-progress category during each sprint.

Alas, we see this situation quite often: development team members leaving the sprint planning meeting and working on PBIs in isolation throughout the sprint. One of the biggest causes of this anti-pattern is that many organizations still operate under the illusion that they must maximize resource utilization, and that more is accomplished when individuals work on different items than when they collaborate. (We’ve heard many developers argue this—it’s not just management.) But just because there’s a lot of work in progress doesn’t mean there will be a lot of work finished at the end of a sprint. That’s because a development team can’t self-organize around a problem if team members don’t work together. And if every team member is working on something different, then ownership over the increment (a key component of Scrum) turns into ownership of individual product backlog items.

Reducing the number of product backlog items that are in progress may be the just recipe you need to create better focus and help your team get a high-quality, done increment at the end of the sprint. If your team is plagued by too much work in progress, during your next retrospective, try suggesting that you experiment with a WIP (work in progress) limit. Take these steps:

1. Define when a PBI becomes “active” in a sprint—in other words, when work has officially started taking place on it. This active state could progress through a workflow, such as analysis, design, coding, and testing. All of those states in this example are considered “active.”

2. Next, define when work is considered “done” in a sprint—when the PBI is releasable.

3. Limit the number of items that can be active at any given time. Have the team choose a reasonable number to limit themselves to. Start high, as you can always decrease this number.

4. In the next sprint retrospective, review the effect of instituting this limit.

Limiting work in progress is one technique you can suggest to foster collaboration. There are many other techniques that you may suggest such as pair programming, code reviews, or mob programming. The goal is to get a team truly working as a team and not as a bunch of individuals, each trying to complete their own work. The team will have a far greater chance of creating a high-quality product if they collaborate.