Software developers don’t just build new features. We know we need to spend time on operational work and maintenance. Yet most plans don’t reflect this. Operational work is always lacking when I go over a customer’s initial roadmap.

Those of you who have been reading this newsletter for a while know how much I like Iterative Buffer Planning. After every “Focus block”, we plan one or two weeks of Recovery. This creates an ebb and flow system where teams alternate between product and operational work. Product managers plan the Focus blocks; developers pick what to work on during the Recovery blocks.

Recovery blocks serve three purposes:

Most importantly, they ensure developers have time to catch up on operational work. The pressure to deliver new features and functionality rapidly can often leave teams with little time to focus on customer support, technical improvements, and bug fixing. This leads to a mountain of work that builds up over time, increasing the risk of errors slipping through the cracks. Instead of waiting for a time when devs magically have 45 minutes to fix that bug, Recovery buffers make us treat operational tasks as first-class citizens.

Secondly, they allow us to go over our timebox’s budget without creating the dreaded “domino effect“. When one feature takes longer than expected, it can create a ripple effect that impacts subsequent tasks and throws off the entire timeline. This chain reaction is often hard to stop.

When a team needs another day to complete the last story of a sprint, that day will come at the expense of the next sprint’s capacity. While that’s not a problem for short-term sprint planning, it makes it impossible for the team to make promises. The domino effect is why we are reluctant to claim a feature will be ready by sprint 17.

Recovery timeboxes act as buffers. When we need an extra day to finish the feature, we have one day less to work on operational stuff. That’s often an acceptable trade-off. Since slippage gets caught by the buffer, we are still in a position where we can keep promises.

Lastly, timeboxes offer another significant benefit – they give developers more agency and autonomy over their work. During the Recovery timebox, developers have the freedom to focus on the tasks and activities they feel are most valuable for the stability and maintainability of the product. This can be a major morale booster for developers, who often feel like they are at the mercy of stakeholders, product managers, and business leads when deciding what work to prioritize.

Recovery blocks should occur after each Focus block and take at least one week. If the previous Focus block is particularly long or contains a high level of uncertainty, extending the Recovery block to two weeks is a great idea.

The one drawback of Recovery blocks is that they make the roadmap look less “ambitious”. Prepare to spend time convincing stakeholders of this approach.

Consistently scheduling Recovery blocks after each Focus block is the way to balance operational work with predictable feature delivery.

Give it a shot!