Allow slack, don't allocate 100%

A classic approach to resource allocation is to aim for 100% allocation. Anything else would be cost-inefficient, right? Having people sitting around doing nothing can’t be a good thing, right? …Well, wrong…!

Aiming at 100% allocation would be desired only if it was possible to know and plan every detail that every person has to do, in advance. And you can’t. Allocating less than 100% doesn’t mean that the unallocated time is expected to be spent on youtube (no offence, youtube is great! ;-)). No, it means that the unallocated time is expected to be available for all unplanned things that has to be done in order for everyone to do their planned work and keep the pace up.

It’s important so let’s repeat it: You should allocate less than 100%. The remainder, let’s call it Slack, is expected to be available to do useful things that can’t be planned for. What are those “useful things”? Well, helping your teammates for example. If you don’t allow for slack the team members won’t have time to help each other. So the team’s productivity will actually decrease because the cooperation effect is lost.

Usually the purpose of trying to allocate to a 100% is to make sure that productivity is maximized. But, in fact increasing allocation towards 100% will risk giving the opposite effect.

Obviously, the trick is to have just enough slack.

So, slack is good. You want slack, and you need to stay weary of any attempts or implied desires to the decrease slack time.

There are several methods you can use to ensure you introduce the slack time as a mechanism in your planning:

• Continuously measure and use “Focus Factor”. A typical focus factor might be somewhere between 0.6 and 0.8 I would say, but there are no rules and differs for every team. So don’t focus too much on this number: it’s a crude measurement and it has much more to do with how large/many impediments and how much disturbance the team has, how good your user stories are and how good your backlog is, than e.g. the team’s efficiency.
• Expect no more than e.g. 6 hours of "available work-time" every day. We’ve been experimenting with values as low as 5.5 and up to 6.5 or 7. If you use a project tracking tool it should be possible to set “Working hours” somewhere as a global setting for your project. Either as a percentage of a working day, or as a start- and end-time of each day (which was the option in our case).
• Measure actual velocity and compare to actual, continuously and let the team help out to give feedback on their sense of “load”

We’ve tried all three, and I think a combination of them is the way to go, depending on situation. Key is to understand why you need slack. If everyone understands that, then you’re able to use either method whenever it feels right.

For another, shorter and more pedagogical way of saying what I say above, I recommend Henrik Kniberg’s slide that you can find here (see page/slide number 26): http://old.crisp.se/henrik.kniberg/presentations/2008-10-13-HiQ/Introduction-To-Lean.pdf