Old binders with files, standing in a row, partly stacked.

Not all teams do ensemble programming, where everyone work on the same task, all the time. If you do not always have access to everyone, you need to have some function where knowledge is shared for each item in the backlog. I use “backlog grooming” as a name for this meeting. This is where you check that the information on the items in the backlog is enough for everyone in the team to understand them, and that people agree somewhat on what is intended with the item. It is important that everyone in the team is present, most so for new teams. I argue that we should have these meetings more often and make them shorter, almost regardless of how we do it today. Here I present the three ways to look at continuous backlog grooming that made me come to that conclusion.

Building Inventory

In the analogy with a factory our groomed backlog items can be seen as work in process. Throughput in a system is limited by high work in process. Backlog items do not take up floor space. But they can get old and irrelevant, or stress the team by being a metaphorical mountain of waiting work. The buffer before a machine is calculated by using the throughput and the time to replenish. Therefore I suggest that the meetings for grooming the backlog should be scheduled in proportion to the team velocity and the current size of groomed items. A rule of thumb is

time to next meeting = work in groomed backlog / (velocity * 2)

This is not precise, so you do not have to measure velocity, just get it about right.

Knowledge work

Going through backlog items is hard cognitive work, and we are not very good at doing this for long periods of time. So having shorter, more frequent meetings, will help us stay fresh and focused. Pick a time in the morning, when the brains are fresh, or after lunch and some rest where the brains have gotten new energy. Then keep it short, preferable under one hour, and focus. That way you will make better decisions and stay engaged.

Continuous improvement

We get better at things that we do often. Things that are painful, but important are good things to get better at. Hence, do painful things more frequent. For Toyota this was setup for the machines. For me it is time reporting. For some software teams it is grooming the backlog. Do a short retrospective after each meeting and focus on the improvement of the processes. Then we will get really good at preparing our work, and well prepared work is more fun to complete.

Related texts

Whirlwind computer, sections of core memory and controls, in Museum of Science, Boston, Massachusetts, USA.

Unnecessary limitations with a history

A kitten that peaks out from under a blanket

Solutions hidden under subjectivity