Managing team capacity and building in slack

It can be tempting to fill your sprints and your roadmap to the brim with work. Ironically this actually tends to cause delays and missed deliveries - a better way is to instead think about your capacity and (productive) slack time.

I recently read this article, by James Stanier. It explains how as a manager, you should not try to manage your time down to the minute, but instead focus on managing your capacity.

It’s a good principle, and something that can be more widely applied when looking at engineering teams and how their work is planned. It can be extended to sprints as well as longer-term plans as well; if you allocate 100% of your time then any interruption (a hotfix, waiting on 3rd party, an outage, etc) causes things to slip and means that overall delivery is delayed.

Building in some "slack capacity" also allows you to tell a better story - it's much nicer to say "we delivered X and Y this cycle, as well as W which was unplanned", versus "we delivered X and Y, but failed to deliver Z which we had on our roadmap, because of unplanned work required for W".

This is important for building trust in being able to do the things you put on your roadmap. And yes, we work agile, so roadmaps are more guidelines than promises, but that's not how our monkey brains work (we see shiny = we expect shiny) and so roadmaps tend to be more “real” than ideal

Something to keep in mind is that work expands to fill the time allocated to it, so if you just have empty slots then you'll find your deliverables always seem to take up that extra time. This is deliberately not the purpose; you want to keep the time for unexpected interruptions, not just regular work.

There are various strategies to compensate. The general idea is to not have unallocated "free-time", but instead have a backlog of low priority tasks that still bring value - small things like automations, paying off technical debt, or even time for learning.

The trick is to make sure the spare time is still active time - this is something you can see when one of your reports wants to learn something new, and so you allocate some time in the sprint for personal development (e.g. Friday afternoons).

If you just free up time, it takes a very disciplined person to actually use it for progressing - most of the time it ends up being used for product work, or vague "learning" that doesn't result in anything in the end. If you treat it as a task (eg: 1 chapter a week) then you can get further (further than just "read this book by X date").

If you make sure that slack time is still planned, you keep your velocity. It's important though that this work is low-priority (and small enough!) that it can be dropped easily, without impact, when you need the extra time back.

If each person in the team has a time reserve, and then a reserve for every sprint, and then also reserves in the cycle, doesn't that mean we will barely deliver anything? Well, yes but also no - looking at the backlog it may seem like fewer things will be delivered, however in reality you would not deliver a full backlog either. Having fewer items with higher confidence is more honest to reality, but gaps in the backlog don’t mean that stuff isn’t getting done either!

And this is why having a groomed backlog is important - if you actually finish on time (or even early!) it should be easy to pick up the next impactful item - anything delivered is now a bonus. If you actually need the buffer time, your overall commitments will not be impacted and it means you're able to deliver what you planned with minimal delays.