It is about the flow!

While it is the Product Owner’s responsibility to order the Product Backlog to maximize value delivery, it is up to the team to order the implementation of the Sprint Backlog to maximize flow of production.

When teams attempt to improve output with each person working on a single Product Backlog Item (PBI) at a time they are more likely create bottlenecks elsewhere. This is a classic example of local optimization.

If multiple work items are delayed during a Sprint, there is an increased risk of not bringing the PBIs to Done by the end of the Sprint.

A team working on multiple items at once results in excessive work in progress, low process efficiency, context switching and associated delays.

It is also about good housekeeping!

Not fixing a bug found during a Sprint can turn one hour of work into multiple weeks later. In other words, if you find a bug during the Sprint, just fix it! That is called good housekeeping and studies have shown that doing so doubles velocity!

Deferring things instead of swarming can easily delay delivery of some backlog items for up to two years.

How do we make the situation worse?

It is easy! Multitask! Well, at least what most people call multi-tasking. Our brains cannot multitask regardless of what some people claim. At best we can perform time slicing and move back and forth between tasks.

That creates context switching which is one of the worst things that can happen! If you don’t believe me, keep reading!

Jerry Weinberg in his book Quality Software Management (1992) mentions how multitasking delays getting things done. Even worse, recent brain research shows that multitasking makes you stupid as well as slow, while increasing stress and accelerating aging (Darren Rowley and Manfred Lange. “Forming to Performing: The Evolution of an Agile Team.” In Proceedings of Agile 2007, Washington, D.C., 2007)

Working on many things at once gives the illusion that things are going faster and plays on the desire for efficiency of the individual worker. Yet, this increases the number of defects that the team must fix and test later, escalates product development costs, and slips release dates.

How do we prevent learning?

Working on too many things at once can radically reduce individual effectiveness and can cripple velocity. If everyone is working on their own thing individually, they are unlikely to help each other and, in the long term, learn from each other.

Team members often want to work independently to avoid stepping on each other’s tasks, a symptom of a dysfunctional team with poor process and engineering practices. Google solved this problem by discussing how to swarm to get things Done during the daily standup.

Yes, we can also do that at a team of teams level and you must!

How do we swarm?

Swarming means that the team is focusing on one PBI at a time, it also implies a rapid interleaving of many development activities on the item in progress. Carrying out one development phase at a time is another way to avoid teamwork, and Swarming works best when all team members bring all their talents to bear all the time.

Working the highest priority PBI on the Scrum Board will tend to cause individuals and teams to self-organize to maximize flow in a Sprint.

Jeff Sutherland, the creator of Scrum recommends:

· Part of the team swarms on the topmost priority Sprint Backlog Item

· Part of the team swarms on the second top priority Sprint Backlog Item

· No more than two items at a time

· Experiment and gather data on how well it works for your team

· It is a way of working but NOT the only way of working

· Start with pairings

What if I don’t believe you?

Besides the examples from a book that is close to 30 yeas old and a paper that was published 13 years ago, meaning this is not exactly new information, Systematic A/S in Denmark showed how implementing this pattern doubled the productivity of every team in the company.

Citrix Online applied this pattern at the enterprise level and reduced release cycles from 42 months to less than 10 months resulting in substantial gains in market share for its products.

Citizenship and Immigration Services went from releasing every 478 days to releasing on demand.

Working on one Product Backlog Item at a time makes it unnecessary to coordinate between work items in progress. Instead, the team can work on the least dependent items first.

Recent Posts

See All

Prior to the Scrum Guide 2020, the backlog refinement used to be regarded as a “quasi event” and a lot more was mentioned about it. So, what happened? As we know the Scrum Guide 2020 was “leaned” and

The Scrum Guide states that the Scrum Master is accountable for the Scrum Team’s effectiveness. Improvement is key to effectiveness. Previously, we discussed Scrumming the Scrum. That was all about co