I have recently had a discussion with a Scrum Master whose team was struggling quite a bit, completing exactly zero stories for two straight iterations. This problem is often framed as overcommitment – how can we make them team commit to what they can deliver and deliver what they have committed to? The Scrum Master was also a recent graduate of an Agile training program as I could tell by very revealing language: “teaching the team a lesson”, “honouring commitments”, and looking at the Scrum Guide first and at the situation second, trying to link the problem with “violations” of Scrum rules.

Let’s re-frame the problem first. This is not about coaching the team to “perform.” Even the concept of a “team” is not really helpful here. What we deal with here is an ecosystem: part of it the team, other parts of it are its customers, partners within the organization, and various stakeholders. Some of these interests may be represented by the Product Owner – although how the Product Owner can be a leaky abstraction and other criticisms of this role is a wholly different topic. The problem is not how to make the team execute on some tasks, but to understand how its ecosystem – a system – co-evolves to create value by delivering its software. Our job is understand the system capability and improve it continually and forever.

Before we embark on that improvement journey, it would be reasonable to ask, what “laws of physics” our system may be governed by?

One of such laws is Little’s Law from the queuing theory. If we have to have conservation of flow – stories enter the system at the sprint planning and exit at the demo – then the amount of work in progress divided by the completion rate must equal the cycle time.

If you do one-week sprints, your minimally acceptable throughput rate is 0.2, representing the velocity of one user story per sprint (five working days). Since the amount of work in progress is greater or equal to 1, Little’s Law allows us to establish quickly that the best we can do as far as the cycle time in this case is 5 days. Fortunately, this cycle time fits into the one-week sprint, although it gives no room for error. But we can say at the very least that the cycle time must be consistently no more than 5 days, and ideally 4, to account for the transaction costs (such as sprint planning and demo)

If the team multitasks (WIP several times more than necessary), its cycle time increases linearly, making it likely it will not fit into the four-day timebox. For example, when the cycle time was three days, they met their commitments. Double the WIP, the cycle time is now six days and they’re now missing commitments. When human beings are involved, the task-switching will actually decrease throughput while increasing WIP at the same, making the cycle-time increase worse than linear.

Another force affecting the team is variability. Cycle time is not really a number, but a probability distribution. People tend to underestimate its variance and the effects of the variance. I hear quite a few Scrum Masters and coaches talk about velocity as a “hard number” or a “meaningful metric” – they miss these metrics’ probabilistic nature.

In order to meet weekly sprint commitments, you need the upper control limit of the cycle time to be no more than four days. For example, if the cycle time has Gaussian distribution with the mean of 2 and the standard deviation of 0.5, the control limits are 0.5 and 3.5. In this case, you have nearly 100% probability that the story will be delivered within the sprint. If the mean is 4 and the distribution is symmetrical, you have a 50% probability of missing your sprint commitment.

Even if my example of the average cycle time of 2 days with a sigma of 0.5 helped anyone start thinking probabilistically, it is actually too good to be a real-world example. It was only an illustration – real-world distributions are a lot worse!

They are almost never normal (Gaussian); lognormal, exponential and “unique” distributions much more common; the standard deviation a greater fraction of the mean as well. The expansion-of-work phenomenon and the asymmetry of distributions will ensure that you almost never benefit from “less-than” outcomes, but always pay the price of “longer-than.”

Options for Improvement

There are two basic options for improving due-date performance. One is reducing variation. Here the main culprits that contribute to increasing it:

• multitasking
• story size
• various blockers (due to multitasking, new technologies, and other sources)

Another option is to reduce the average story size, which has a doubly beneficial side effect because it tends to reduce the harmful component of variation as well. As you can see in the made-up example (average 2, sigma 0.5), committing to stories even as small as half the sprint length assumes unrealistically low variability.

As a rule of thumb, divide the sprint length by a factor of 4 to 6 and that’s how long the average duration (not the development effort) of your stories should be. Err on the side of making your stories smaller, using XP techniques like Product Sashimi and Elephant Carpaccio to make them smaller.

Lastly, the Scrum Master received some advice to increase the sprint length, but was reluctant to do so. I’m in agreement with him on that. I have seen teams take this step as a matter of convenience and they ended up covering up problems and avoided the deeper learning that they needed to go through. Instead, keep the week-long sprints, reduce work in progress, and use the actual cycle-time and velocity data to guide improvement.