Why Backlog Refinement Will Make Your Product Rock

Every scrum master faces the challenge of making the team understand what the story point estimation is for. The most common explanation is that you estimate the time you need to complete the story. Is it? And what does backlog refinement have to do with it?

As science hasn’t progressed so far yet, time is still an undefined parameter for humans, which is why we are not the masters of exact time predictions. However, we are quite good in relative measurements. If you are asked to say how much a random car weighs, it will be problematic for you, and you will only be able to estimate the value by saying ‘somewhere around…’. On the other hand, if you are asked to say which car weighs less – a Smart car or a Land Rover – the answer will be obvious and simple.

Can you guess how many sweets are in the jar?

Why don’t we use our natural skills and benefit from them? For Agile, we use story points as estimation measurements. The idea was to put absolute time estimations to one side and to try to estimate the effort. Effort is the clue here, because each person completes the same task in a different amount of time, while the steps are always the same.

What are story points?

Let’s talk a little theory. A story point is a unit that measures the size of a story, not based on the amount of time but on the effort. It tells you how big one item is compared to another one. To help you understand it better, let’s put an estimation on everyday activities.

For me, boiling water is a task equal to 1 story point, baking a meringue cake would equal 8 story points, and making an omelette would be somewhere in between. What if someone asks how many minutes it will take to boil water? I wish I knew that; I’ve just bought a new kettle and have no idea! Sometimes the story requires using a completely new technology for a developer, and it is hard to guess the hourly effort.

We are 10Clouds: Introducing the DeFi Developer Roadmap

Now that you know a little about estimation tools, let’s find out how we use them for the backlog refinement.

Backlog refinement is the process when the team:

• reviews the items in backlog,
• discusses them,
• enriches them with details together with the Product Owner,
• and – finally – estimates them.

There isn’t one proper way that it should be handled. The main goal is to discuss what needs to be done and ensure the items are small enough so they can be completed during the sprint.

There are a few techniques for estimating backlog items, which can be easily found on blogs or in books. Check out the three most popular techniques, or dive into Mike Cohn’s book, Agile Estimating and Planning. You can also use your own creativity – as long as the items are sized according to one scale the team is familiar with.

Why is backlog refinement important?

Results in clear requirements

During the meeting, the Product Owner presents the items to developers, and the discussion begins. They have an opportunity to talk about the business goal, point out what is impossible to make or suggest better and more innovative solutions. It offers the biggest value because every person shares their knowledge, experience, and ideas – things that you can’t learn from books.

Posts important questions

The first step towards discovery is to become aware of what you still don’t know. Agile allows you to make mistakes, change your mind, and make improvements. This is why having good Agile Product Management is so important. As a Product Owner, you don’t need to be overstressed if the team questions your story. It is a good thing! They are smart people, and you play on one team; they give you alternatives, and you can take your time when improving the requirements. All you have to do is to trust them, and then you will see how much you’ll love their input.

Provides for better planning

Let’s assume the backlog is refined and tasks are estimated in real numbers. What comes next? Then you need to plan the sprint. The Product Owner sets the priorities and decides what needs to be completed at the end of the sprint, but the team decides how much they are actually able to finish within a sprint.

Here, the story points can help. After a few iterations, you can see how many of them the team burns. At the following planning meetings, it helps them to decide how much work to take on. If a team burns 30 story points (SP) in each iteration, and at the planning session, the Product Owner wants to convince developers they can complete 40 SP, it is clear to see that it probably will not be a successful sprint.

Remember that as a Product Owner, you are the owner of the product backlog, you keep an eye on the scope so that you are sure everything is just the way it should be; but after the sprint starts, the sprint backlog is managed by the team.

Common pitfalls of backlog refinement

Not doing backlog refinement at all

If the backlog is not refined, tons of questions appear during the ongoing sprint and – believe me – it takes much more time than a single refinement session. It also distracts team members from their work, and it sometimes forces changes in the plan and priorities, because completing the story requires the work of the others. Refining the backlog is the action that needs to be done before starting the sprint.

Not including the Product Owner

The Product Owner is responsible for the product backlog and creates it. When the team has questions during the estimation process, the Product Owner knows the requirement best, so this is the right person to resolve any doubts. If you don’t know what the story is about, you won’t be able to estimate it. As a consequence, the story will be excluded from the upcoming sprint.

Accepting a story that doesn’t meet the definition of ‘Ready’

Every team has its own ‘Ready’ definition, but it always defines the item that can be done within one sprint. It means that the team understands the story goal, acceptance criteria are in place, and the story is small enough to complete in one iteration.

Wrapping up

Having a refined and estimated product backlog helps the Product Owner to forecast when features will be done. You don’t need additional meetings or long hours spent discussing when you can have your product done.

Knowing the team’s velocity (average number of burnt story points per one sprint), you can divide stories into iterations. It helps keep product backlog well-organized so that future releases can be planned at a glance. Additionally, the team understands the requirements, and missing points are detected at an early stage. It minimizes the distraction caused by ambiguities during the sprint.

I can’t ensure that backlog refinement will solve all of your problems, but it helps the team follow one common goal, which is a pretty big success indeed.