A question I encounter when people are pushing back about extra columns on the board!

Buffers are designed for a number of reasons. They can:

  1. Enable us to understand the flow through the system
  2. Help you to control a bottleneck situation
  3. Act as an input queue for work coming into the system.

Let’s break each one of these down.

Enable us to understand the flow through the system

The above diagram shows yellow buffers applied to each of the work flow states. We use these to help us be a flow/pull system. We typically buffer each of the ‘Doing’ states Eg Dev, Test and Review to help us understand where the build up of work is happening. For example, if we see large amounts of work frequently in the ‘Ready to Test’ column, then this signals that the balance across the Dev and Test functions is not working as desired. Ultimately the queue of work grows in ‘Ready for Test’ and the testers are over burdened and the developers potentially run out of work in progress limit space, to be able to pull in more work. This leads to an unhappy team. If a one off problem, you might take smaller mitigating actions such as Dev’s helping to test. But if a reoccurring problem, then we need to look at our numbers of people, work in progress limits and anything else we can do to solve.

The work in buffer columns is actually bad for you. Seeing them is good! but work in there is effectively waiting. Waiting increases your lead time and ultimately reduces your ability to deliver. We call this our delivery rate.

So where we have work waiting in these buffers, we want to be working out how we can stop so much work being in there. My top tip in this instance is to really look at your work in progress limits against the number of people you have in the team. So whilst these might cause more noise on the board, they are designed to be a mirror and tell us where issues are occurring.

I typically buffer out all of my states when I design a board, but then get rid of them if they are not used. Remember, your board changes as your system and knowledge evolves.

Another rule of thumb I have when designing boards is whether a process is slick or fraught with issues. A team might complete a pull request, and the process is slick and the work picked up and completed quickly. Then you probably don’t need it as a buffer and a explicit policy will do. But generally no one likes doing this work, they sit around for days and lots of issues. So in this instance, a buffer is really going to highlight there is a problem here. Which we can then discuss as part of the retrospective/Flow review.

Help you to control a bottleneck situation

Imagine the situation where in your team the review process is completed outside of your organisation. You do other types of work as well, but some of them need an external partner. For that work you have little control of the review process. So a symptom you might see is a bottleneck of work building up to be reviewed. In this instance I would potentially add in a buffer, which is actually a queue. If I left the board without the green section, my ‘Ready to Review’ in the test column will become very full, eat up my work in progress and everything grinds to a halt. By adding the additional green section then we have a place for work to queue up in an unlimited way.

But wait, is what I have just taught you a good thing?

No it’s not, but its a way to control your system and keep things moving. Remember you are only as fast as the slowest part of your system and so I would quite quickly be wanting to talk to the reviewers and understand how many they can do at any given time, effectively creating a work in progress limit. I would then know that any additional work of that type sent through the system will get delayed. So maybe a better a balance of types of work we do would be beneficial and we do some other piece of work instead. This stops the bottle neck getting worse. We are now controlling our work item type flow.

Once you have your system balanced, then I would get rid of the green section and use my usual buffers.

Sometimes I get asked, ‘Why don’t you just increase the work in progress limits?’. Well by doing this we are hiding the problem and I really want that work in progress limit across both the working and the waiting state to create that holistic flow.

Act as an input queue for work coming into the system.

The ‘Ready’ or ‘Up next’ (whatever you call it) is a form of a buffer/queue. The purpose of this is to ensure you have enough ready work to keep the team fulfilled. Running out of work here would be bad news and costly in terms of team financial burn. We have a work in progress limit on this column, but it is worked out in a different way. You want the front end of your system to match the back end. For example we have to understand the delivery rate of the system, let’s say 2 per day. We also have to understand how much is being abandoned, blocked or waiting. We also have to understand do we have generalists in terms of skills or do we have people that will only do certain types of work. The more of this you have, the more of a uplift you have to have of this number. This is why staff liquidity is important. Translated, that just means we want teams who can do all of the stuff needed and we need to know in the team who wants to learn and who can teach.

In Conclusion

Buffers are critical for understanding the flow and controlling the work. We might not always need them, but initially we might choose them to truly be able to see what is happening with our work. This then guides us in continuous improvement. Sometimes people get caught up with names, is it a buffer or a queue. It doesn’t really matter, the point is the thing you are trying to achieve.

Take a look at your board. What changes do you need to make?