XP Practice: Slack

October 26, 2007 by Artem

Slack is one of the primary Extreme Programming practices, i.e. is one of those that can stand out and bring value on its own. Slack is a practice of of including in every plan a number of tasks or user stories that can be dropped if team runs out of time. The reason for including slack is to be honest and transparent about the workload estimation. Software production is always a new product development and every estimation is namely an estimation. Even if the team plans in detail for one iteration only, in most of the cases there is still some uncertainty and having slack is only about explicitly realizing it.

There are some variations of how slack can be used. Some teams prefer agreeing that some storied taken into iteration are considered droppable-if-needed. Other teams vise versa consider it useful to leave some "free time" in the iteration and agree which small stories could be included if everything went well and team really had some free time. There is also a possibility to fill the slack space with important, but not urgent technical tasks such, as major refactorings, unit testing script upgrades, etc.

Links

• Slack and Scheduling in XP - James Shore' proposal to stock for slack valuable, but non-urgent tasks, such as big architectural refactorings, adding tests to legacy code or work practices improvements.
• Practice: Slack - Kent Beck's post on what this practice is about
• Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco - classical book that suggests purposely slowing down could actually boost the productivity. Now quite about XP though. (non-affiliated link)

This page is a part of the Extreme Programming overview

Permalink