A Backlog is different to a Buffer.
In short, a Backlog should be a safe waiting place, where it is: a) cheap and b) fast for ideas of all sizes and complexities to flow to. The purpose of a Backlog is to have just enough information to do a very rough triage of a potentially infinite range of problems and opportunities. That allows one or more teams to then siphon the cream off the top.
A Buffer on the other hand is NOT a safe waiting place. It is neither cheap, nor that fast to get to, and the number of options in the buffer should be very limited (not infinite!) The options in the buffer should also be roughly similar in size and complexity. Options in the buffer will have been sliced and refined down enough that the team could pull one from the top of the buffer, swarm around it and do enough in a short space of time (less than 2 weeks) to learn something of value.
Here’s where each roughly fit in the flow of things:
So, the Buffer is “downstream” from the Backlog. The work required to get to a Buffer is to break ideas down, understand CD3 and “Refine” the options.
Some suggested rules for the Backlog:
- It is a “Safe Waiting Place”. It is cheap to hold them there (we aren’t working on things that are waiting in a Backlog),
- We are making no promises or commitments or expectations about things on a Backlog. We aren’t committed to starting them at all.
- Demand will be infinite, and always exceeding supply, arriving randomly. The Backlog is where that demand flows to. (At Maersk, we called these the “Dynamic Priority List”, since Backlog was considered a bad thing in Danish, like a backed up toilet.)
Some suggested rules for the Buffer:
- Buffers are specific to a Team or Squad. The work that exists in a teams’ buffer is specific to them – the things they are going to focus on in an attempt to move the needle on the OKRs and Problems that were articulated in the Backlog, which is often multi-team and is often Product, JTBD, or Stakeholder specific.
- To get from the Backlog to a Team’s Buffer requires input from the team. You don’t inject work into the Team’s buffer, unless it is something like Production Support or a bug that that team inadvertently shipped.
- The items on the buffer are the result of the team doing the work to consider options for how they might solve a problem or contribute toward an OKR or initiative.
- It costs us something to get to the Team’s buffer. Not just the time to understand the problem, different options for attacking it and the complexity of that, but also the time spent doing that is time spent not working on other problems or opportunities.
- The purpose of the buffer is to protect the team from wasting too much time doing to much of the refining sort of work required to get to the buffer. This is partially why we limit the number of items. The other reasons are that refining work decays quickly and that our priorities may well change.
- The other cost is in task-switching. Getting your head into a different problem space pulls you out of the problem space you were in and it takes some time to get back into the original one.
- How much work to hold in the buffer? Ideally, none! The work to slice and refine options down to size should be done just-in-time — no more than a couple of weeks before they then have a crack at it. In other contexts you might have a few or more week’s worth of things in the buffer. In the most extreme example, where you have complex dependencies that you haven’t yet broken, you may need to look at something like a quarter’s worth of “what’s coming up” so that other teams can do things in the correct sequence or synchronise. You do want to avoid this as much as possible though! It’s not free. Are the decisions you’re making with the additional information worth that?
- The things in a Teams’ buffer are already sliced and diced into small enough parts that the team can deliver from the buffer to Prod in (ideally) less than 2 weeks. Some teams will have better developed slicing heuristics, and their buffer items will be much smaller, less than a week. It’s really team dependent, and it may well change over time. Keep the team together if you want them to get better at this.
- Buffers will likely contain a mix of things that address Tech Debt, flow improvements, Risk and Security improvements as well as other OKR or initiative focused things. Teams may want to reserve some capacity to handle incidents, investigations and research, and bug squashing. Late arriving dependencies from other teams may be another thing to create slack for.
- The “right” mix at the team level will be different for different teams depending on the state of the apps they are stewards of — and the state of the surrounding landscape and org needs.