If you have worked with Agile for a while, you probably heard of backlog refinement. For those of you new to this topic, in a nutshell, backlog refinement is a session dedicated to cleaning up the Product Backlog. Something to note is that the Product Backlog is different from the Sprint Backlog. The Product Backlog is the overarching backlog while the Sprint Backlog is for the Sprint increment. This is an everyday activity though it is not explicitly mentioned in the Scrum Guide.
A backlog refinement session is not the only time a backlog can be refined. Nor is it a one-shot meeting. It is an ongoing activity. Some teams dedicate time to working through the backlog with a refinement session while others may choose to take a more organic approach. So when you think of backlog refinement, do not jump right to a meeting.
Backlog Refinement Value
The act of backlog refinement does not mean only the Product Owner/Manager refines the backlog. Backlog refinement is an activity for even the team working on the product. Refinement is not about telling teams what to do but showing them the direction in which the product needs to be taken.
By keeping teams involved in the process of refinement they gain a better understanding. They are able to communicate directly with the Product Owner and ask questions they may have. This is also an opportunity for the Product Owner to ask their own questions to the team. Having a refined backlog helps clear things up before work is done. If the backlog were not refined, teams may work on something only to find out they were going in the wrong direction.
Keeping a backlog in clean working order keeps things running smoothly.
Backlog Refinement as a conveyor belt
One way to look at backlog refinement is to compare it to a conveyor belt. Some people think that the backlog needs to be 100% refined all the time. That approach causes teams to be less flexible and able to change should an issue arise.
By looking at refinement like a conveyor belt at any point in time the conveyor belt can be stopped and adjusted. If a feature is suddenly cut, it can easily be removed. If plans change the backlog can change.
As stories move down the conveyor belt they become more refined. A story at the very start might be very rudimentary and lack details. That is okay. As it works its way down the belt it becomes more and more refined through backlog refinement sessions and conversations around the story. The end of the conveyor belt is when the story is picked up. It has been refined to a point where a team feels comfortable picking it up and doing the work.
Pitfalls
Refining a backlog is not without its issues. Some common pitfalls are refining too much, leaving out essential voices, not removing items, and only refining at a designated time. This list could be longer.
Refining too much
If a team refines the backlog too much they could end up with wasted effort. Let us say that the team has a backlog with 100 completely refined stories at the beginning of the month. Some of these stories do not need to be done until near the end of the month. That sounds great. Midway through the month, a decision is made to change a feature. The feature’s stories had been refined significantly earlier. The team now has wasted effort from the beginning of the month. They refined a story that was farther away that ended up changing.
Exclusion
Too often a team can feel like they know enough information about a feature that they do not need to include the Product Owner. They have excuses like “the Product Owner does not need to attend another meeting” or “these are technical stories that they will have no input on”. By doing this the Product Owner misses on out insight into the inner workings of the product.
Backlog size out of control
It may be hard to believe but there are some pretty large product backlogs out there. That was a little sarcasm. Backlogs have been known to balloon out of control. Teams and/or Product Owners do not want to delete a story because they “might need it later”. They may leave stories in the product backlog because they simply forgot they were there. By letting the backlog grow too much they potentially can bury stories that need to be done. Finding stories becomes challenging. Prioritizing work becomes an issue because the backlog became so large.
Refining only at a designated time
Lastly, product refinement only at a given time can cause a team to forget exactly why some stories were needed. They can also forget important details that were discussed at the moment. By putting refinement off until the designated session they lose out on value.
In conclusion, product backlog refinement is a necessary action. Notice how it is an action and not an event. Calling it an event implies that it is a scheduled occurrence when in reality it is an ongoing action. The value it provides to the team is immense. But it is not without its pitfalls and traps.
