In part 1 of this Overcommitting in Agile series, I outlined the challenges that can result from overcommitting. I contended that we should prioritize product throughput over resource utilization to ensure we’re delivering features our customers love faster. In this blog, we’ll explore that further and I’ll also propose 11 practical solutions to combat overcommitting.

A typical metaphor used to illustrate this concept of product throughput vs. resource utilization is a freeway. We all know what happens when a freeway is fully utilized–gridlock.  The same thing happens to engineering teams. Some other similarities between freeways and teams include:

1. The actual rate at which a freeway slows down increases dramatically as utilization increases. Traffic slows down much faster at 80-90% utilization.
2. When traffic incidents occur (e.g. accidents, lane closures), the impact is much higher at times of high utilization.
3. When a freeway is at or near maximum capacity, its ability to handle the unexpected decreases significantly.

These same principles apply to software teams, especially the third item. There are a host of unknowns and random events will occur, so plans need to have enough slack in them to account for these.  If we focus on maximum utilization, teams will start to thrash when things don’t go exactly to plan.

Instead of focusing on utilization, it’s important to focus on delivery to get stuff done with quality before we start new stuff.

To avoid overcommitting in the future, here are some ideas to try with your teams.  Don’t feel like you have to do all of these. Just try a couple and see if they help; if they don’t, try something else.

11 Practical Solutions to Avoid Overcommitting:

1. Use “Yesterday’s Weather” (i.e. your team’s average velocity) to sprint plan what you can take on in the coming sprint.
2. Actively manage your team’s WIP during the sprint. For Kanban teams, this is done through WIP limits, but even with Scrum, you can put WIP limits on the number of open stories your team is working on at any given moment.
3. Focus on getting stories to done as quickly as possible before starting new stories.
4. Dogpile (or at least pair) on stories to get them done faster.
5. Allow for slack time in your sprint plans (YES, you can do it!)… This will better enable your team to handle the unexpected and maximize the flow of delivery.
6. If you’re concerned that your team may not have enough work coming out of sprint planning, then have 1-2 stories in the ready queue to be worked on if the team gets all the committed work to done before the sprint ends.  You can always pull work into a sprint before it finishes.
7. Keep your stories small! Queuing theory provides evidence that small items flow through delivery systems much faster than large work items.
8. If your team is struggling to get stories to done every sprint and is not tasking out stories, try tasking at your next sprint planning session.
9. Make sure your stories are ready to be worked on before sprint planning.  This will lead to a better understanding of the work, better estimates, and better planning overall.  At Salesforce we have an Enterprise Definition of Ready that defines what a ready story looks like.
10. Make sure you know everyone’s true capacity to do sprint work during sprint planning.  Make sure you call out everything that takes time away from capacity.
11. Make sure that all your team’s work is identified in planning and is visible during the sprint.

So in your next few sprints, try focusing more on finishing and less on starting work.  It really will make your work life easier, produce higher quality products, and actually get more product out the door faster that your customers will love. Isn’t this why we are all here in the first place?