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.