You need to stop using buffer to manage unplanned work in Scrum

Dev Team: “Hey Mike (Scrum Master), We have lots of unplanned work during the last sprints; how should we handle them?”

Mike: “You can create a buffer space in your sprint plan.”

Dev Team: “It looks great... Let’s do it.”

What is buffer space?

Based on this story, During sprint planning, reserve some buffer in a sprint backlog. There are two ways to do this. First, you can plan a virtual backlog item of a specific size that will count towards your velocity. This is going to be your buffer. Each time a new user story or bug enters the sprint, you subtract its size from the buffer item until it reaches zero. From this point, all the new work will be rejected by the team and put into the product backlog. Second, you can plan fewer items than the usual sprint velocity. During the sprint, you absorb new user stories. This difference between average velocity and forecast velocity will act as an implicit buffer.

But why buffer technique is not a good practice in most cases?

Let me tell you a real story. Some time ago, I started coaching an agile team. The team had adopted Scrum for a while. But the manager was not satisfied with the team’s delivery rate per sprint. The team attributed this low delivery rate to unplanned work on each sprint. To solve this problem, the team used the buffer practice to make better predictions in each sprint. But in practice, there was no significant difference.

When I started to work with this team, my initial goal was to maximize transparency to answer this question, “Why do we have this amount of unplanned work?”

Before taking any action, As a coach, we must have a clear understanding of the situation and, more importantly, make it clear to everyone.

What did you get from this visualization?

Let's look at the above image, I think you got the idea that why we should not use the buffer. This visualization uncovered that there is a high level of technical debt, and in fact, When you adopt buffer technique in this case, instead of solving the root of the problem, you hide it.

An old Japanese saying mentions hiding an offensively smelly object by covering it up.

This amount of bug rate certainly indicates the low level of quality of the Codebase. There is probably no automated tests. The design is very fragile, because, with each sprint as the new feature is developed, the next sprint has more bugs. You can find a pattern.

“Scrum is like your mother-in-law, it points out ALL your faults.” — Ken Schwaber

The basis of the Toyota production system and Lean is the absolute elimination of waste. Don’t Hide the Wastes, Visualize them, and solve the root problem.

When the problem is clearly understood, improvement is possible.

Sometimes (though not always), the buffer hides the root of the problem. The result will not be satisfactory, and we covered the problems.

The next time you encounter unplanned work, check the 7 wastes of lean software development. Try to make them clear and visualized, and the solution will emerge.

While problems observed at the surface level can often be addressed with a simple readjustment, the lean mindset pushes us not to assume that every issue can be solved by simply treating the symptom or adjusting at the surface level.

In my case, After visualizing, we started to create a plan to manage our technical debt, we added a technical mentor to the team, we adopted XP practices…

This story has already published on FactfulAgility

Best Regards

Asad