SCRUM BASICS
Refining the Refinement. Backlog refinement basics.
In Scrum, we run one Sprint after another. One Sprint ends and the next one starts immediately.
How do we make that happen? How do we know what to work on next? And how do we make sure the team has enough information about the new functionality to be able to start working on it in the next Sprint?
The magic is called Backlog Refinement
It is an ongoing activity of adding details to product backlog items. It means preparing them to be selected in the Sprint Planning and worked on in the next sprint or sprints.
I will explain how to do backlog refinement, what’s the product backlog, and the definition of ready (DoR). And about some useful practices to make sure the team has enough work ready for the next sprint.
What´s the objective of the backlog Refinement?
The goal is to achieve a shared understanding of the work that will be done and that each team member is aware of the scope and nature of the tasks they will face in the next sprint.
Refining the backlog is preparing the items, so they are ready to be selected in the Sprint Planning and become Sprint Backlog.
What is a product backlog?
If you have a product, you have a product backlog. Scrum Guide explains:
The Product Backlog lists all features, functions, requirements, enhancements, and fixes to be made to the product.
It is a wishlist of all the things you would like to do with your product.
Product Backlog is a living artifact, it never stops changing because the requirements, market needs, and technology keep on changing constantly!
Who is responsible for the Product Backlog?
The Product Owner is responsible for the product backlog including its content, availability, and ordering. It means they are responsible for maintaining the backlog organized and accessible for everyone but still, everyone in the team can add new requirements and more definition to the backlog items. It’s interesting to see user stories written by any team member.
User Stories or Product Backlog Items?
I’m using the terms User Stories and Product Backlog Items (PBI) interchangeably. User Stories come from Extreme Programming and are not required by Scrum, where you can find Product Backlog Items. In short, User Story is an informal, natural language description of one or more features of a software system. A common practice is to use User Stories by the teams in Scrum as their template helps structure them and bring the focus of the team to the user. How to write User Stories is a great material for another article, once I write it, you will be able to find it in the description below.
Nonetheless, a good user story is not one that’s perfectly written by one person but one that has been discussed in a team.
What does it mean to be “ready” for the Sprint?
Here is when the Definition of Ready comes in handy. Each team creates their Definition of Ready which serves as a checklist to deem an item ready for the Sprint. “Ready” stories should be clear, concise, and actionable.
So, how do we actually do this? As Backlog refinement is an act of adding details, estimates, and order to items in the Product Backlog, usually, that means meeting with the Scrum Team and discussing every aspect but not necessarily. It can be also done asynchronously and become an ongoing practice. Note that Scrum doesn’t add refinement to the list of Scrum events, so the form is free and up to the Scrum Team.
As I already mentioned, there can be different forms of doing the refinement, for example:
- A regular meeting of the Scrum Team — say once a week, where the Product Owner brings User Stories to refine. A variation would be that the Product Owner brings the Epics, one level higher than User Stories, with business context and the team writes the User Stories together using the User Story Mapping or other practice to help identify the stories for the new initiative.
- A collaborative document — the PO prepares a document with items to refine and everyone from the team can add details to the User Stories and comment on them in an asynchronous way. This can be an option after a good kick-off meeting about a new initiative and can be followed by a short meeting to clarify any doubts and arrive at conclusions before the team goes to the Sprint Planning.
What does a refinement meeting usually look like?
- Explanation of the business context and why the team should work on this next. Imagine there is new legislation in one country and you need to change the behavior of your app: you need to ask the users for permission to use their camera. You don’t just tell the team: “ask for permission”, you explain why, so they can better understand the context and knowing the problem can help find an optimal solution. This is preferably done with the stakeholders, like legal advisors in the company, in this case, to better understand the new legislation.
- Define feasibility — is it technically possible? Does it make sense? Product Owner brings the “what”, a problem to be solved by the team. And the team defines the “how” to implement the solution. Derive spikes, i.e. research stories, if needed, if you are not sure if the functionality is feasible so you can add or remove information as more insights are gathered and more is known.
- Slice user stories — check if the user stories fit into one Sprint. If not, split the user story into multiple smaller ones so they became smaller and easier to grasp.
- Add Acceptance Criteria — this goes into writing User Stories but also being test-driven and having the items testable. Mark Cohn calls them “the conditions of satisfaction” and it “is simply a high-level acceptance test that will be true after the agile user story is complete.” It helps the development team understand the desired outcome of the new functionality and is a base for the test scenarios of the new functionality.
- Definition of Ready — make a final check if all you need is defined according to your team agreement.
- Estimation — once all previous points are filled in, you can start estimating. The teams estimate in relative measure for many reasons. Firstly, to check if the team arrived at a shared understanding of the item and the estimations are similar. If not, it’s a sign more discussion about story details is needed. Estimations help to define the team’s velocity per sprint, the number of story points done each sprint. Thanks to it, it’s easier to predict how much work can be done per sprint and spot any issues if the velocity changes considerably from one sprint to another.
- Tools and techniques — There are different techniques that can help the team write and define the user stories: User Story Mapping, INVEST, SMART, etc.
To summarize:
Refinement is an ongoing activity of the Scrum Team to make sure the work, i.e. User Stories or Product Backlog Items are ready to be pulled into a Sprint. It is not just another Scrum event and it can take different forms.
From my experience though, having a regular session with the Scrum Team to refine user stories helps create a habit and builds the team owing to the fact that it serves as a perfect opportunity for knowledge sharing, both about the product and about the technology.
And that’s all for today! Hope you got some inspiration on how to conduct your refinements!
