Slack

A common approach with Timeboxed Iterations is to
allocate as many UserStories as possible to
each iteration in order to maximize the utilization of the staff involved.
Slack is the policy of deliberately leaving time that isn’t
allocated for stories, using that time for unplanned work. Although this seems
inefficient, it usually yields a significant improvement for the
productivity of a team.

A good way to introduce slack into planning is to use it to cope with the
inherent uncertainty of planning. A team that averages 20 stories per iteration
won’t complete exactly that number every iteration. Instead we’ll see a range:
say from 15 to 22. In this situation the team can plan at their lowest
consistent number (15) and treat the additional time as slack.

One benefit of this approach is that it reduces the variability of story
completion. Rather than wondering if this iteration will complete those last
five of a 20 story allocation, we can expect 15 with high confidence. For
planning and coordination, higher confidence is often worth more than trying
to maximize throughput.

People often fear that slack will lead to idleness, but there are many
productive ways to use that slack time. The most obvious is to tackle
additional stories as an uncommitted bonus. This doesn’t affect the
predictability of the lower commitment rate, but gets more done on an
as-possible basis.

But doing more stories is often not the most productive thing to do. Most
teams are slowed by factors in their working environment. There may be
inefficiencies in the build process, cruft in the code base, or
unfamiliarity with productivity tools (most people have all sorts of undiscovered
gems in their IDEs). Spending the slack time on these can make a big
difference by increasing productivity in future interactions. Indeed the most
common productivity problem teams face is due to a congested schedule that
allows these impediments to fester.

Another good use of Slack is activities that increase collaboration with
customers. Often the biggest impediment to true productivity is a development
team that doesn’t really understand how best to improve the work of their
customers and users. Learning more about them, even if it’s as simple as
spending an afternoon shadowing a user, can do much to amplify the value of
their features.

Slack improves a team’s ability to respond to urgent requests. Often teams
need to collaborate, such as extending an API for another team’s feature. Without
slack, such work needs to be scheduled into the plan, increasing delay, and
the cycle time of other teams. Small tasks can be handled in slack, done
quickly with little ceremony. Remember that high utilization increases
latency.

While I’ve described slack here in terms of Timeboxed Iterations it is also important to Continuous Flow. The smell here is if a continuous flow team is always
busy – that indicates not enough slack, which will make them slower to respond
to requests and unable to look after their working environment.

While slack is both important and often undervalued, it’s a seasoning not
the main dish. A schedule that’s all slack gives up visibility and longer-term
planning. But to run without it is like skimping on your oil changes.