How To: Backlog Refinement

The Scrum Guide states that, ” Product Backlog Items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog Refinement is the act of breaking down and further defining Product Backlog Items into smaller more precise items”

Although it is mentioned in the Scrum Guide, Backlog Refinement is an event that is often overlooked by teams or businesses who are just starting out. Time is spent reviewing Scrum training material with new teams and businesses and because Backlog Refinement doesn’t appear in any of the framework diagrams it is often glossed over leaving teams struggling to make sense of their backlogs. In past experience this was very common back in the day, it was the norm to have massive stories in the backlog that would just be too big to work on and if they were pulled in, they would carry over for Sprint after Sprint. Backlog refinement has made this less common as it has become more popular and people are now including it in their training materials.

As a team, we need to be confident that the stories we have in our backlog are prioritised and are refined to a sufficient size to allow us to complete them within one Sprint. The refinement session is the team’s chance to review the prioritised backlog along with the Product Owner. Reviewing the items within the backlog not only improves visibility and transparency but it helps the team break down the work into smaller chunks, reprioritise, ask questions, add detail and give initial estimates if possible. If there are any questions that cannot be answered the Product Owner must follow up and have these answered as quickly as possible to allow the team to refine at the next session.

Backlog Refinement sessions can be a regular occurrence for teams and it is solely the decision of the team what cadence they chose and what method they use to refine. Some teams may have the whole team present at refinement while some may opt for a 3 Amigo style refinement (Dev, QA, PO). Some teams may hold a session once per Sprint while some may have once per week. The important thing here is to choose what works for the team and regularly gain feedback on the effectiveness of the outputs and the cadence to make sure that they are effective.

What is the aim of backlog refinement?

The aim of backlog refinement is to take the prioritised stories that have not been subject to refinement and get an understanding of what is needed for the team to gain enough knowledge and understanding to complete these stories. We evaluate whether the requirements are clear enough for the team to be able to understand (The description) and how these will be signed off as complete (Acceptance Criteria). We also evaluate whether the story is small enough to be completed by the team within one Sprint. We will split the story down further if it is too large but still aim to keep the story valuable.

As we refine we may uncover new work. The team should then make the call on whether the new work is of a high enough priority that we should refine straight away and reprioritise the backlog or add the story to the backlog for a future refinement session.

We should leave the session with a prioritised backlog that will partly form the basis of our next Sprint. I say partly here because in my experience you can never tell when stories or bugs may slip into the prioritised backlog in the timescale between refinement and planning, this is normal and we need to cater for this. We should also leave with a list of actions that need to be followed up on before Sprint planning or next refinement. This can consist of a list of questions that may need answered, analytics data, etc.

What are the benefits?

I have found Backlog refinement sessions to be really useful in aligning teams towards their goals. Ultimately we are preparing our teams with enough knowledge and confidence that they can come into Sprint Planning safe in the knowledge that we have prepared and prioritised our backlog. There are no outstanding questions, dependencies have been called out and we can get to work straight away. There may be one or two stories that may have slipped in but these can be refined and added to the Sprint without much impact to the Planning Session. As we progress over time it should be as easy as pulling X amount of items from the Prioritised Backlog into our Sprint Planning session, having a conversation around how these help meet our goals, agree that these are the items that we should be working on and then crack on.

There is an old saying that I always relate to with Backlog refinement.. “Fail to prepare, prepare to fail”. In the early days we didn’t do refinement, we often failed as the stories were unclear and sometimes unrelated to our goal. Backlog Refinement brought us together as a unit giving ups the information that we needed to reach our goals as a team rather than individuals and our success rate increased.

Who Attends Backlog Refinement?

Depending on the method of refinement you choose you can either have the whole team present or select individuals as a 3 Amigos group. The Product Owner plays a vital role here though and it is paramount that they are present as they have the knowledge of the product vision, the roadmap and they are also the voice of the customer so are best placed to relay customer needs. They are required to be present to that they can answer any questions, offer any guidance and prioritise the backlog once items have been refined, new stories raised or stories have been removed.

The inner workings

When we enter stories into our backlog they do not need to be absolutely perfect. They are a placeholder for a conversation and the details will emerge as the team discuss and work out a plan of action for completing it. You can use the standard format for user stories below to help get the conversation started.

  • As an X I would like Y so that I can Z
  • Have a description (We need a rough outline of what the requirements are)
  • Have some Acceptance Criteria (Some criteria that you would use to measure if a story is complete or not)
  • Keep our INVEST requirements in mind

Idf what you want to achieve is hard to fit into a story we need to think a little differently. We should think of the goal that we are trying to achieve and what needs to be done to achieve this goal. This then allows the team to discuss the goal and the actions and find the best possible way to achieve this.

  • In order to complete X As a Y I need to do Z
    Have a description (We need a rough outline of what the requirements are)
  • Have some Acceptance Criteria (Some criteria that you would use to measure if a story is complete or not)
  • Keep our INVEST requirements in mind

The team will then work with the PO to discuss and evaluate the story. They can ask questions, suggest changes and estimate. If it is too big they can break it down into smaller parts taking care not to lose the value within the story. The team will then refine and estimate these smaller parts and reprioritise the backlog.

I hope this helps give some inspiration.

Published by The Daily Scrum

A CSP, CSM, CSPO who lives and works in Glasgow, UK.

%d bloggers like this: