This morning whilst waiting for everyone else to arrive in the office I took the time to catch up on emails and read through the various mailing lists I subscribe to. One of which, Extreme Programming
had a large number of posts regarding a single thread—regarding the XP practice of “Slack”.
Some of the communication was debate over whether slack within the plans was in the best interest of customers, and this seemed to be around the confusion of what slack actually meant. Surely if we’re in the business of better delivering customer value faster, it’s in our interest to complete more important work quicker? On the face if it that is true, but, as the posts clarify, it’s important for iterations to have a commital, rather than to just stand for merely an allotment of work from the release plan.
As with the rest of the pillars of XP, slack isn’t a hard-and-fast rule. Where I work it’s not something we do all the time. Indeed, it’s something I’ve often found myself arguing internally over. So, when I read a few of the posts I felt it really solidified my position.
Jim Shore has an excellent article regarding slack and scheduling, but it’s the snippet below that sums it up for me:
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. —James Shore: Successful Software
However, I disagree to an extent with his view that slack and stories should be considered separate, that slack is some external entity. In a post to the email list he writes:
“I don’t see Slack as being about doing more stories. In every iteration, I plan stories according to velocity. I also plan technical tasks. Some are explicit, like “update build script to install Feature X;” some are implicit, like “type on the keyboard” and “do test-driven development.”
“Among those tasks are some that I consider to be Slack. Some Slack tasks are explicit; some implicit. While they are all important, it’s possible for me to set some aside, on occassion, to meet my commitments.”
“I think the idea of Slack as ‘extra stories’ confuses the issue. I don’t see Slack as being stories at all.”
Speaking from the experiences our team has had with development, I think that slack is something that unless we add as low-urgency stories, wouldn’t get done.
Introducing a dichotomy between customer-focused stories and ‘slack’ tasks introduced a difference in perceived value—and since we had piles of customer work to do, we ended up swapping out the slack tasks for getting more stories in. If you change the language of James Shore’s post, so it becomes value and urgency on the 2 dimensions, and we’re essentially back to the same (basic) constructs of a story anyway.
I guess if you’re in a situation where it’s possible to retain value by introducing a distinction then you have no problem. With us (whilst working with the excellent Charlie Poole) we added our ‘slack’ tasks as stories that would be scheduled alongside everything else. The argument being that we were are own customers also—it was in our best interest to ensure this work was done to better enable us to work in the future.
We marked cards with a red border to indicate items that we felt we needed to address, that would ultimately deliver high value, but were not necessarily of great urgency.
This lack of a difference in value was (pardon the pun) invaluable to us, and to my mind, seems simpler than trying to maintain two lists of things to do—everything is managed (with great visibility) through our old system!
Although this practice dropped unconsciously from our process a while ago, the idea of dropping less important features for a more defined commital is something we’re improving at now, and something I’m glad to see again! Has anyone else approached this in the same way, or has the separation proved more useful?