If you tidy or clean your house for 15 minutes to half an hour every day, this will prevent all the work from piling up and eventually having your hands full to put everything back in place. In that sense, Backlog Refinement is just like cleaning your house. It is better to do it more often and for a shorter  period of time than suddenly having to clean and tidy for days at the end of the month to get everything in order.
In this blog, Serge Smit, Senior System Architect at BPM Company, tells you how Backlog Refinement works, and what benefits it offers for the customer.

Maintenance is key
Backlog Refinement is a continuous process. The product backlog, a list of wishes that you are going to realize, is never completely perfect. And in the exceptional case that it was, the situation has usually changed after a few weeks so that it is no longer up to date. The backlog must therefore be continuously updated, in other words refined.
Holding refinement sessions every week has even more advantages; it prevents the backlog from drying up. “I recently had a project where the focus was very much on going live and on the possible aftercare. There was a lot less attention being paid to refining new user stories. This caused the backlog to dry up and therefore there was not enough work ready to be resumed in the next sprint”, says Serge. Because of this he advocates for weekly refinement sessions: “This also informs the team about what is to come. That way everyone stays up-to-date and everyone knows what to expect. ”

Discovering dependencies
One of the goals of creating a Product Backlog Refinement session is to identify dependencies. This way you can find out that requested functionalities that are on your product backlog have a great dependency on another team. These may be dependencies between different User Stories because, for example, there is a link with a web service. Another example is that the Development Team lacks the necessary people, which in turn makes them dependent on others who are not on the team. By allowing this process to take place early, these issues can be resolved before they become a problem.
Serge: “It is important that the User Stories are planned at the right time. But you also have to involve each other in the realization, for example during testing. You could argue that the moment there are dependencies with another team, the user story is not ready to be picked up. Think of it like vacuuming your house. If you are vacuuming your house but the energy supplier does not supply you with electricity at that moment, then there is a dependency. You cannot vacuum without electricity. ”

Detailing User Stories
Completing the User Stories by adding details is an important part of Backlog Refinement. The details that are provided make it easier for the Development Team, for example, to estimate how much time will be needed to complete a User Story. However, not everything has to be described as specifically.
“When I look at my experience within different projects, it varies a lot per team. Personally, I like it when there is some room for creativity. For me it does not have to be all very specifically described in the user story. Also for a developer I think it is nice to have some freedom in the development of a user story.
On the other hand, the more specific the user story is, the fewer mistakes can be made. The “gap” between what is expected and what is actually delivered is often smaller in that case. ”

Creating value
A big advantage of refinement is that an end result is delivered that meets the customer’s needs and also has functionality for the customer. Delivering “value” for the customer is something that always has the highest priority within an (agile) project.
“I think that with Backlog Refinement you can largely remove the ambiguities and that you can really meet the expectations of the customer through this process. After all, there is no longer any possibility to make assumptions. The delivery of something that is not asked for at all is therefore something that no longer happens”, says Serge.
However, this value cannot always be delivered in the first attempt due to the complexity. A good Product Backlog therefore contains a lot of smaller User Stories that have been given individual priority. The User stories that currently deliver the highest value are of course at the top and will therefore be picked up first by the team.

Time commitment
According to the Scrum Guide, a maximum of 10% of the entire time spent on a sprint may be allocated to Backlog Refinement. In other words, in a full-time sprint, the Backlog Refinement may not exceed 4 hours per week. Yet this can only be seen as a guideline. In reality, this often takes a little more time. “It differs greatly from project to project. In general, it is true that we spend about 10% of the time on the refinement part. But that’s just the sessions. In the background, before you enter such a session, there is of course also time to look up and prepare things. I think that you can eventually double that 10% and that you often spend almost 20% of the time on this part ”

Backlog Refinement has a lot of advantages. It prevents the backlog from drying up, identifies dependencies, helps with the time planning of the project and removes ambiguities. Also, this process clarifies project expectations at an early stage. In addition, User Stories can be divided into sub-tasks and picked up on the basis of priority, so that the Development Team can fully focus on the upcoming sprint. By applying refinement continuously, the chances are made many times greater that the end product will actually deliver “value” for the customer.
The latter is something that Serge himself enjoys the most: “What I personally like the most is to really understand what the end user is asking. It feels really nice when you build something that actually solves a problem. It is often the case that you are a bit further away from the end user, because you are not sitting next to that person. So through a user story with the right context you can gain good insight into why it is so important what you do. As a result, I feel very involved and I am really proud of the moment that I can go live with something for that user and in that way make his life a little easier ”.

Curious about the possibilities to work at BPM Company?
Then take a quick look at our vacancies or contact Hans Steenwijk.

Curious about working at BPM Company?

Take a look at our vacancies or ask Hans Steenwijk:

Meer informatie: