Projects have limited resources. It's one of the legs of the iron triangle. In the case of software development, that means people. Companies that follow a product-style approach don't have such a triple constraint but are still limited by their bandwidth. And that limited bandwidth also means people.
When assembling a team, we design the available resources or bandwidth. That's why we love stable teams: it makes calculating progress and projections easier. If our team of five devs can consistently churn out 25 Story Points per sprint, it's reasonable to assume they can keep doing this in the future. Whether that's considered "real Agile" or not: Scrum teams use velocity to project future results.
Even those who refrain from creating long-term projections will use this bandwidth for the short term. One of the defining characteristics of Scrum is getting together on Monday to decide how much work the team thinks it can get done in the coming fortnight.
Unfortunately for these projections, our resources are not inexhaustible machines. They are human people who need holidays, sick days, and last-minute PTO. In larger teams, it's almost a guarantee that not everyone will be there for the entire sprint.
And that brings us to the noble sport of capacity planning. How do we account for these fluctuations in our bandwidth? How do we make a sprint commitment when we're not sure the entire team will be there? And how do we make long-term plans if we don't know the team’s availability?
Over the years, I've seen wildly different and creative ways of calculating a team's capacity. I've seen companies where holidays needed to be requested before the sprint planning meeting. I even worked with a business that asked their developers to plan their summer holidays in January so they could create a roadmap for the year. But more often than not, I've seen teams ignore capacity planning completely. They'll commit to those 25 Story Points even though 40% of their team is on holiday.
So, what's a healthy way of planning the team capacity?
Here's how I look at it. Fluctuations in capacity are either high-impact or low-impact.
Low impact means a part of our team is out for a short period of time. Even when a single team member is out for a longer period of time, this can be considered a low-impact fluctuation. High-impact fluctuations are moments when a large chunk of our team is unavailable for multiple days.
When your team commits to delivering scope by the end of the sprint, even low-impact fluctuations can mess with your plan. Your backend guy needs a day to take care of his sick child, and suddenly, your sprint commitment is broken.
But when you're using Iterative Buffer Planning, this doesn't pose a problem. Since the scope of the Focus Block is flexible, the impact on the result is negligible. The team can always deliver something that moves the needle towards solving the problem. The beauty of iterative buffer planning is that you don't need to account for low-impact fluctuations. Either the team ships less, or the backend dev catches up in the following Recovery Block. Your long-term plan won't be affected.
Typical examples of low-impact fluctuations are sick days, half a day to run a last-minute errand or even a national holiday where the entire team is out for a day.
But high-impact fluctuations do need to be planned. When three of your five developers are out for two weeks, that's going to impact your capacity to ship. Fortunately, most high-impact fluctuations are rather predictable. The typical example here is the summer and Christmas holidays. Even if the team hasn't requested their holidays yet, we know the team capacity will be lower. In that case, I advise teams to book Recovery Blocks in the holiday season. While it will impact the work that can be done in those weeks, there will be zero impact on promises we've made to stakeholders.
Trying to plan scope based on estimates leads to brittle plans. We’ve all seen how sick days can impact a team’s delivery. Iterative buffer planning makes capacity planning easier. Focus Blocks have built-in capacity plans, and Recovery Blocks can be used to anticipate low-capacity moments.
A reader reached out and asked an interesting question: Isn't there an error in the matrix? Isn't the combination of "short period" and "many developers missing" high-impact?
The example I use is that of a national holiday. On such a day, most or all of your team will be unavailable. That's not a problem when applying iterative buffer planning, as the team can either build less or catch up during the following recovery block.
But the reader makes an excellent point. When using traditional estimate-driven timeboxes, such a holiday will wreak havoc. It takes away 10% of the development capacity for a typical two-week sprint. That's painful when the scope is fixed, and there are no buffers. It will create a domino effect that will impact the long-term plan. In that case, it's definitely high-impact!