“Operating a product development process near full utilization is an economic disaster.”

Don Reinertsen

Introduction: The Disaster of 100% Utilisation

Here is a question for Scrum Teams out there: when you plan your Sprints, what percentage of capacity do you load into your iteration backlog: is it ‘the full monty’? If the answer is yes, I strongly encourage you to think again.

Planning Sprints fully loaded at 100% utilisation prevents flexibility in two important ways.

First, it hinders the ability to collaborate inside a team. Simply put: team members are too busy to help each other out.

Secondly, the full load puts up barriers around our Sprint, preventing opportunities to collaborate with other teams. When other teams have to wait until the next Sprint every time, then we create tension and lose flexibility.

To understand why this is the case, think of gridlocked traffic on a busy Motorway/Freeway. The capacity of the motorway is 100% utilised! Is that full efficiency? Of course not.

There is no freedom of movement. Delays are very likely. The plans of everyone using that motorway will need to adjust due to delays.

Think of how that feels for a team: it is frustrating to know in advance that delays are inevitable with our work. We are very likely to not finish what we plan, carrying work over to the next iteration and getting deeper into ‘delivery debt’. Vicious cycle.

Now, think of how that feels for your customers and stakeholders: if they start to believe that your plans are unreliable, how can they be sure that you will honour your promises? 100% utilisation leads to business risks very quickly.

Velocity

To avoid these potential disasters, we need to work systematically.

First, understand the velocity of the team: how much work do you get done in each sprint on average? This is a good starting point. The average of last x number of Sprints is a good rule of thumb: I suggest 3 or 4 of your most recent Sprints. Work out the average number of items delivered or sum of story points delivered: whatever works best for your team.

Capacity and how we use it

Next, consider the team’s capacity allocation: how much of our work goes to different categories of work? The names of these types or categories of work can vary across teams and organisations but we generally have to ‘keep the lights on’ and ‘create value’.

How much of each type of work should we do? At a high level, we need agreement here, and the team’s stakeholders need to be aligned behind our choices. Product Owner: the Scrum Team needs your help here. Scrum Master: help here wherever you can.

Is our capacity allocation a 50/50 split, or is it something else? Considering support work as a ‘known unknowns’ will build some flexibility into a Sprint. If we know that we spend roughly 20% of our work on urgent support requests from outside the team, then we need to set aside capacity for that and use Kanban techniques to help us manage that work as it enters the system. We can’t plan the work items, but we can set capacity aside to allow flexibility. This will help build flexibility into iteration and allow for collaboration with other teams.

Flexibility

Once we understand how we allocate work into pieces of our capacity allocation, we can plan the iteration with more confidence.

Here is the key point: do not start the iteration with any more than 80% of your capacity loaded. This kind of planning allows for room to manoeuvre inside a team.

Even though we start the iteration with less planned, we now have a better chance of actually getting it done. This is down to the team’s new ability to move, collaborate, and help each other get work done.

With improved ability to get to done, we stand a better chance of completing what we planned. This means we should be able to pull more work into the iteration with confidence of closing it out.

Flow

Rather than gridlock, you’ll have a better flow of movement and flow of work through the team.

It’s always busy in an iteration where we are solving complex, adaptive problems, but at least in this picture we’re all moving! In the first, fully loaded iteration, we were all slammed.

Benefits

By building contingency into Sprint plans, we allow room to absorb unexpected dependencies from other teams, urgent support work and unexpected scope discovered in our existing sprint plan.

One risk of this approach: we need to promise less in the short term. Product Owner: we need your help and support on this one!

However, there is a payoff: we have a better chance of delivering to match our velocity when we start a Sprint at 80% capacity. We either absorb surprises, or we encourage ‘pull’ from the backlog. We should see fewer delays, better predictability and fewer items carrying over to the next Sprint as a result.

We will become more predictable and more reliable to our customers and stakeholders. We will also facilitate delivery of dependent work more often. The Scrum Team will not be ‘running hot’ all the time. It should feel better.

Close

Before wrapping up, I want to acknowledge the work of troy.magennis and Don Reinertsen, which have heavily influenced this post. Try here for an excellent presentation from Troy, or here for Don Reinerstsen’s hugely influential book.

I’ve also made a video to support this post on Vimeo (with thanks to Marty de Jonge, Scott Richards and Maria Chec for all the valuable feedback to help workshop the video and get me out of my comfort zone with it!).

Let me be clear in my closing advice: do not plan sprints at 100% capacity!

There is mathematical proof out there to demonstrate why this is a bad idea. If you need even more plain-speaking on this topic, Don Reinertsen calls it an ‘economic disaster’.

Adding contingency to your Sprint Plans will help work to flow more smoothly in your team. Introducing this flexibility to your sprint plan will help your team collaborate better inside the team and with others outside. Your team will have a better chance of completing what you plan, and less work will carry over to the next Sprint.

Your customers and stakeholders will start to see more predictability and you will meet your promises to them more often.

All this will help your team, the teams with which you collaborate, and your customers to be more successful with Scrum.