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.

Pingback: Scrum Commitments, Little's Law, and Variability | Innovation and Agilty in Software | Scoop.it

Solid advice and guidance. With respect to the temptation to lengthen the sprint, I had this happen on a project many years ago and the outcome was disastrous and made doubly-so when the inexperienced PO (backed by management) proceeded to increase the sprint timebox each iteration.

This anti-pattern arises when POs and managers are unaware of the underlying principle behind Brooks’ Law, ie. “men and months are not interchangeable commodities”. You do not receive a commensurate increase in quality output from a system of intellectual/knowledge-based labour by adding either manpower or time – you get ever-diminishing returns.

See my post, Understanding Misalignments in Software Projects for a deeper dive on why this is.

http://www.derailleurconsulting.com/blog/understanding-misalignments-in-software-development-projects

Pingback: Management Improvement Blog Carnival #191 » Curious Cat Management Improvement Blog

Pingback: #NoEstimates Discussion at Agile Open Toronto | Learning Agile and Lean

Pingback: Estimations done right - lastzero's software engineering blog

@lastzero: Your pingback says: “Remember that the differences in size will cancel each other out according to the law of large numbers and a mostly stable velocity can establish (throughput).” This is not what this blog post states. This post is about moving from the convenient and erroneous thinking that “things will average out” and toward understanding what cycle time distributions really are and how that affects our decisions and our work on improving the system. Additionally, cycle time variations tend not to cancel each other out – the effect known as the “expansion of work.”

If your user story cycle time averages out to four days and if you run week-long sprints, you are mathematically bound to miss commitments on almost 50% of the stories. This point is lost on many Scrum Masters and thinking the law of big numbers doesn’t help them understand it.

Thanks for the feedback. That’s exactly why I added the link: You describe the underlying problem in the context of sprint planning really well. What I wrote is, that the effort of tasks with about the same, low complexity can indeed average out, so that accurate/precise estimations of single tasks are not required and you can observe a more or less stable throughput/velocity. You can of course NOT use an average throughput for guaranteed commitments. Hope the clarification in my blog post makes this obvious to the reader.

Michael, thank you for the comment. I see that you’ve compiled lots of material on the subject and I’m happy to hear that my post (which is really just touching one part of the elephant) has helped in some way.

Pingback: Top 10 Laws in Agile | Finding-Marbles