Over on the xpe2e mailing list (yes, there is such a thing: it's for discussing Extreme Programming Explained, 2nd Edition, by Kent Beck) there's been a long-running discussion about slack.

In the new edition of Kent's book, he has a practice called "Slack." He summarizes it thusly: "In any plan, include some minor tasks that can be dropped if you get behind." He goes on to say that slack is important for two reasons: establishing trust in the team's ability to deliver, and reducing waste.

If you've read Tom DeMarco's book Slack or any of the Theory of Constraints stuff, this makes perfect sense. Because the world is full of surprises, buffers (slack) are necessary to protect critical deadlines and to allow the project to proceed smoothly. And it works better to create a separate buffer for the tasks than it does to over-estimate each task.

Kent doesn't provide a lot of guidance on how to implement slack in his book, though, and that's what the conversation on the xpe2e mailing list has been about. It's allowed me to see how many important XP techniques play the role of slack.

First, let's establish why slack is important. In the past few years, I've seen a number of XP teams that regarded the iteration plan as no more than a rough guide. They thought that, if they didn't finish all of the stories in the plan, that was okay... "we're agile!" Postponing stories to the next iteration was an acceptable (and frequently used) option.

This has always given me a sense of discomfort, and now I realize why it's bothered me so much. The whole point of an iteration timebox is to provide a hard deadline. Timeboxes are a proven technique for helping a team focus on the really important stuff. If you're always letting stories fall over to the next iteration, you don't have a timebox at all: you have regularly scheduled meetings. And then you're not delivering regularly, which leads to the issues of trust and waste as Kent describes. Slack enables you to deliver even in the face of unexpected delays.

Taking Stock of Slack

So what is slack? It doesn't mean scheduling a day (or three) of "do-nothing" time at the end of the iteration. Any task that can be instantly postponed, indefinitely, is slack. The best slack tasks are also valuable tasks. Maybe even as valuable as the stories you're implementing. In Stephen Covey language, they're important but not urgent. (Stories, on the other hand, are important and urgent.)

Many important XP tasks work as slack:

• "Big picture" (architectural) refactorings
• Adding tests to legacy code
• Paying off technical debt (for example, improving the build system)
• "Big picture" improvements to testing strategy (like mocking the database, a new sort of Fit fixture, etc.)
• 40-hour week (also known as "sustainable pace" and "energized work")

Joshua Kerievsky's Industrial XP has a practice called "Continuous Learning." These tasks also work well as slack. Examples include:

• Research time
• Book clubs
• And Kent suggests "geek week" in his book, which would work as slack for an overall release.

There are some other common tasks that I wouldn't use as slack:

• Everyday refactoring (such renaming, extracting, and moving methods)
• Test-driven development
• Pair programming

The good slack tasks in the first two lists build the team's capability to deliver. They all help the team work more effectively. If the team goes without doing them for an iteration, it won't cause any lasting damage. (Although going without them for several iterations in a row will be damaging.)

The tasks in the third list are poor slack tasks because they sustain the team's capability to deliver. Going without them, even for an iteration, will cause the team to accumulate design debt and hurt their ability to deliver.

There's another task that some have suggested using as slack...

• "Less important" stories

...but I don't think these meets the definition of a slack task. Slack tasks have to be dropped at a moment's notice. You can't just drop a story and do something else, because you end up with dead code, which turns into design debt.

Slack and Project Entropy

How much slack do you need? That depends on how much entropy you have in your iterations. How unpredictable is your environment? In my experience, there are two big sources of entropy on an XP team:

• customer unavailability
• technical debt (including design debt)

The more often you face these issues, the more unpredictable your environment is, and the more slack you need in order to meet your deadlines. In the case of technical debt, you can even use that slack to eliminate the problem!

Conclusion

Slack is an important tool for meeting commitments and deadlines. Use it to establish a reputation for delivering on time and establish trust with your project community. There are important tasks that every XP team should be doing, all the time, that make great slack. Go ahead and set them aside when you risk missing a deadline. Be careful, though, because these tasks are important as well, and if you set them aside too often, you're damaging your ability to keep delivering. If that starts to happen, scale back on your commitments.

Thanks to Bill Caputo for the phrase "increasing the team's capability to deliver" and to Joel Shellman for tying in Stephen Covey. The term "project community" comes from David and Amy Schmaltz. Although this article was inspired by the xpe2e mailing list discussion of slack, the opinions are my own.

James Shore. Reading 13 gazillion mailing lists so you don't have to!!