Three ways to look at continuous backlog grooming
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.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about Theory of Constraints to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.