In an ideal world, a Scrum team could perform the work of its sprints entirely uninterrupted. Product owners would never introduce change. Customers would never request urgent new functionality. And users would never discover any defects.
While teams can aspire to a world of no sprint interruptions, it is not the world in which most teams operate. Most Scrum teams do have to deal with interruptions of these types.
If 5-10% of a team’s iteration is used toward interruptions, this doesn’t create many problems for the team.
But some Scrum teams are interrupted much more frequently than that. And this is sometimes the unchangeable nature of their world. During their iteration planning meetings, those teams will usually incorporate some amount of buffer into their plans. (I’ve written about doing that in this blog post.)
Beyond planning a buffer into its sprint, teams who are prone to a lot of interruptions should track the use of the buffer over the course of the sprint.
A Personal Example of Using a Buffer
Think of the buffer as a budget for the interruptions you’ll allow in a sprint. As with a financial budget, you don’t want to exceed it. A good way of ensuring that doesn’t happen is to periodically compare how much of the budget has been used against how much of the budget should have been used by then.
My first job after graduate school didn’t pay particularly well. But it was enough to get by—if I was careful. For the first week after I got my paycheck for the month, I felt flush. And I felt I could afford to make myself a nice dinner. That usually meant a chicken breast and a salad. Sometimes I’d even grill a steak.
By the end of the month, though, I’d switched from chicken breasts and salad to 42-cent boxes of macaroni and powdered cheese.
What I should have done is assess my food spending weekly. If after the first week, I’d spent one-fourth of my four-week food budget, I’d know I was in good shape. But if I’d spent 35% in the first week, I could have cut back earlier in the month but less dramatically.
Buffer Penetration
An agile team can similarly track the use of a buffer allocated during sprint planning. Tracking buffer use, or buffer penetration, is helpful because it facilitates decision making about the use of the buffer.
For example, suppose a team is on the fifth day of a ten-day sprint. That is, the team is 50% through the calendar time of the sprint. And suppose this team has already used 80% of its buffer. The product owner in this case should be very disciplined about letting further change into the sprint.
Alternatively, if this team had only used 20% of the buffer by the fifth day of a ten-day sprint, the product owner could be a little more lenient in allowing a change into the sprint, assuming the team is on track to meet its sprint goal.
Visualizing Buffer Penetration
You can improve conversations about your buffer by graphing it. The easiest way to do this is with a simple chart like this:
The top bar is showing how many days the team is into the current iteration. In this case, they are five days (halfway) through the iteration as five of ten boxes are colored blue.
The lower bar indicates how much of the buffer has been consumed. In this case, 62% of the buffer has been consumed. Since the team is halfway through the iteration and has consumed more than half the buffer, it’s time for the product owner to start pushing back aggressively against anything being added to this iteration.
As another example, this time showing the opposite situation, consider the figure below, which now shows a team 7 days into their iteration and having used only 37% of the allocated buffer. The product owner could be a bit more willing to accept changes over the next few days (assuming the team is on track to achieve its sprint goal).
Given the short iterations of agile teams, this simple visualization is appropriate in most cases. However, if your team uses long sprints, you may want to visualize buffer penetration over time throughout the sprint.
Visualizing Buffer Penetration Over Time
To visualize changes to buffer penetration over time, create a graph like the one below. As in prior graphs, the days of the iteration are shown across the horizontal axis. But in this chart, a vertical axis is added and used to show the percentage of the buffer used.
A line is then drawn to show the buffer usage as of each day of the iteration. In this case, at the end of days 1 and 2, about 11% of the buffer has been used. By the end of day 6, 50% of the buffer had been used.
If you’d like, augment this chart as I’ve done by adding red, yellow and green zones. The red zone indicates excessive buffer penetration—the team has used too much of the buffer too early.
The green zone indicates the opposite. And the yellow zone indicates the team is roughly on track.
Note that I’ve drawn the yellow zone to be both 20% more and less of the buffer. This reflects the idea that buffering for uncertainties cannot be done with certainty. (Certainly not!)
Some successful iterations will use a bit more buffer than planned. Some will use less. The goal should be to be right on average, not to be concerned with the exact percentage every single iteration.
Experiment and perhaps use something different than the 20% I’ve used here, but that will be a good starting point.
How Large Should the Buffer Be?
The size of your buffer is entirely dependent on your team’s situation. Teams for whom interruptions are the norm will need larger buffers than teams that are rarely interrupted.
In determining the size of the buffer, you should also think about the implications for exceeding the buffer. If it is vital that your team deliver what it says it will, you may need to err on the side of a larger buffer.
The best way, though, to size your buffer is to simply make an educated guess, run a few iterations with that buffer size, and then adjust based on experience.
