The importance of slack π
A team needs some spare capacity to deliver at full potential.
It may sound counterintuitive, but a team working at 100% capacity is brittle and inefficient. Some spare capacity, or slack, is necessary to hit peak throughput. Slack lets the team adapt when reality inevitably throws a wrench in the works.
To better understand for why some slack is necessary, let’s turn to traffic flow theory.
Fundamentals of traffic flow #
Below are three traffic simulations of a three-lane highway. All simulations have the same traffic inflow on each lane. The only difference is how much additional traffic is coming from the onramp.
No incoming traffic: With no traffic coming from the onramp, the flow is smooth even with heavy traffic.
Light incoming traffic: The highway can handle a bit of additional traffic being merged in from the outside. Cars can adjust their speed to avoid disrupting the flow.
Heavy incoming traffic: If incoming traffic is too heavy, the system breaks down. It is simply not possible for the cars already on the highway to adapt.
Ouch, a lot of people in that last simulation are going to be late for work. π
How it relates to software development #
Just as a highway has a limit to how many cars it can handle, a team can only manage so many tasks before slowing down.
In the above simulations, the highway acts as an analogy for your Scrum board. Each car represents a ticket on the board. Each lane is a team member moving those tickets from the backlog on the left, to “done” on the right. The onramp represents the unplanned work the team is forced to handle.
Just like the highway, a well-oiled team can achieve good throughput, and handle some unplanned work without losing its stride. But if the rate of unplanned work becomes too high, the team is not able to compensate. The incoming work pushes out planned work. When that planned work is postponed, the work in the backlog will have to wait longer. And if more unplanned work appears, that work is delayed even further. With enough unplanned work, most new tickets added to the backlog will never be completed.
Finally, slack provides a cushion for other road-blocks. Tickets are much more complex and inter-dependent than cars on a highway, so there are many more sources for delay. Therefore, slack is also needed for reprioritization, not just capacity. It makes it easier for someone else to pick up a ticket if a colleague gets sick. It allows team room to handle tickets that take longer than expected, without breaking delivery commitments. It also gives the team room to breathe.
Making good use of slack #
Am I suggesting team members should sit idle, sipping coffee? That we waste those precious man-hours?
No, I think we can be more creative than that. Spare capacity is a perfect opportunity to do work that is important but not urgent. Activities that can be done in small steps and paused when urgent work comes up.
Here are some examples of how that spare capacity can be put to good use.
- Refactoring & technical debt: Clean up the code and improve test coverage.
- Documentation: Update READMEs, architecture docs, onboarding guides.
- Learning & experimenting: Read up on new technology or try out tooling.
- Automation & efficiency: Write scripts for setup, debugging, or performance checks.
- Pair programming & mentorship: Work together with colleagues, share knowledge.
- Tidy backlog: Review tickets, clarify acceptance criteria, close outdated items.
Want your team more resilient, consistent, and productive? Drop the mindset that every minute must be accounted forβand add some slack!1 As a bonus, you will get some of that important-but-not-urgent work done as well!
-
Yes, I used an em dash. No, it wasn’t written by an LLM. I just like em dashes. π ↩︎