Tips for an Effective Agile Product Backlog Refinement
Starting work on a new user story can be overwhelming. A developer has to understand the area of code, who is the main stakeholder, what are the base requirements, technical considerations and main output. Gathering all this and more can be time consuming for a developer. Gathering this information beforehand as a team is far more effective. This is where a effective Agile Product Backlog Refinement helps.
So what can you do to enhance the effectiveness of your Agile Product Backlog Refinement? Here are some tips.
What is an Agile Product Backlog Refinement?
Before we get started, let’s have a refresher of what is a Product Backlog Refinement.
According to the Scrum Guide, the Agile Product Backlog Refinement is described as:
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.
The ideal output, user stories that are clear, well defined, and ready for development, will help not only developers, but all members of your Scrum team, and those outside of your team, understand what is being or about to be worked on. With that being said, here are some tips to improve your Agile Product Backlog Refinement.
Create and Use a Story Template
Creating a user story template has many benefits. A user story template will assist the person writing the story to ensure best practices are followed and all the required information is gathered. It will also reduce the amount of duplicate work the user story writer has to perform.
Using the user story template you create will help the team gather important information before a Product Backlog Refinement, making it easier to discuss. Using a template will also ensure development will go smoothly.
Here is an example of a user story template I have used in the past:
Story Title:
Issue Type: (Story, Bug, Tech Debt, Spike etc)As a (specific type of user or technology)
I want to (what they want to accomplish)
So that (why do they want to accomplish this)Acceptance Criteria:
Technical Considerations:
Testing Considerations:
Other Considerations:
Known Stakeholders:
There are many tools that will help you use a user story template. With Jira, you can create a template and then clone the template story. If you have both Jira and Confluence, ConfiForms is a great third party plug-in that you can make a customized form in Confluence that creates a story in Jira. Miro can also be used to push stories directly to Jira.
Two Definitions of Ready
You and your team are cruising along in your Product Backlog Refinement and ready to move onto the next story. Open up the story, and this is the only thing you see in the summary.
We need to fix the report. It is showing the wrong data.
Not very helpful. What report? What data is wrong? What should be the proper data? and many more questions. The person who wrote this story knows this information but was too lazy to write it down. Here is where a second Definition of Ready helps.
Definition of Done and Definition of Ready are two techniques mature Agile teams use in their work. The Definition of Done is a checklist of items that need to be completed to consider a user story done, and a Definition of Ready is a checklist of items that need to be completed to consider a user story to be ready to work on.
But what about this second Definition of Ready I mention. With a second Definition of Ready, Ready to Refine, a Agile Product Backlog Refinement will improve greatly.
The Definition of Ready to Refine should contain basic rules. Understand that Refinement is a place where a story takes shape through discussions and questions. One of the requirements could be that the user story uses a template. Another requirement could be UX designs must be attached to the user story.
Having this second Definition of Ready will save time at the Product Backlog Refinement. It was also encourage team members to use best practices when writing user stories.
Share Stories to be Refined
Joining a meeting without a background of what will be discussed already puts you behind. Just like having an agenda of each Agile ceremony in the meeting description, sharing which user stories to refine will help the Agile team prepare.
When the Agile team knows what will be discussed, team members can gather required information, read stories beforehand, and get a general idea of how the next few sprints may be planned.
Share the stories on the day before, or the morning of the Agile Product Backlog Refinement. A simple email or message in a chat with the list of stories will do. Encourage the Agile team to spend a few minutes reviewing the stories in advanced, but only if they have time.
Read Stories Beforehand and Provide Notes
When an user story is first written, it will not include all the information needed to size right away. The person writing the story may not understand the technical requirements, or need to gather more information from stakeholders.
Encourage the team to read stories ahead of the Product Backlog Refinement. It is not meant to be long, just even asking the team to spend a quick 15 minutes will be helpful. It is not homework.
The team can use the list of stories that will be refined from the list that was messaged. If a list hasn’t been sent out, ask the team to read the first few stories at the top of the product backlog. While they quickly glance at the user stories, ask them to write down notes, or tag people with questions in the comments.
Encourage the team to follow up on any questions they were tagged to answer in advance of the Product Refinement. The more information you have going to into a Product Backlog Refinement, the more effective this Agile ceremony will become.
Encourage Questions and keep notes in Comments
Effective Product Backlog Refinements are filled with great discussions, ideas, and questions. A great deal of information will be discovered. But we don’t want to lose this valuable information. The comments area of each story is a great place to keep this information.
Tracking key questions in the comments will help with gathering information. If the user story needs more information before it can meet the Definition of Ready, you won’t risk someone missing gathering the information. Tagging a person in the comment can also serve as a reminder.
Using the comments area of a story will improve time spent refining a user story, ensure key information is recorded, and overall improve the quality of the user story.
Establish Purpose and Ideal Outcome
Clearly defining the purpose and desired outcomes of all Agile ceremonies and meetings is essential. Meetings without clear objectives often become unproductive gatherings. Since everyone has busy schedules, aimless meetings can result in wasted time and frustration for team members.
One characteristic of a successful Agile team is the ability to produce top quality work quickly and easily. Establishing the purpose and ideal outcome of Agile Product Backlog Refinement helps a team focus on enhancing user stories and minimizing the risk of rework.
Continually reminding the team of the purpose and desired outcomes is essential. As a team grows, bad habits may begin to develop. Scrum teams can get comfortable and not see a need for better user stories or improvements to the Product Backlog Refinement. When you see that the outcome is not being achieved, remind team members of the ideal outcome before the next Product Backlog Refinement.
Limit Time per Story and Keep Conversations Focused
This is often the point at which a Product Backlog Refinement can go off track. The team may begin discussing one user story, but as the conversation progresses, it branches out to related stories, and continues to diverge until the original user story is forgotten. Going down a rabbit hole will lead to no stories being refined.
Focusing on the user story to discuss is key. Letting the conversation transform into other user stories, will just cause the original story to be incomplete. Once you know it, the Product Backlog Refinement ceremony is over, and a top priority story will not be ready at Sprint Planning.
A healthy Product Backlog usually aims for 2 to 3 Sprints worth of work that matches the Definition of Ready. If you are spending whole Product Backlog Refinements on one user story, you will not have enough work ready going into the next Sprint. Limit time to 10–15 minutes a user story. If the difference in sizes is one or two points, go with the higher. Once the discussion gets longer, it is clear the story is not ready to be refined further. Change your focus to gathering a list of the information needed and move on to the next user story.
“INVEST” in Good Stories
Breaking down large user stories into multiple small user stories can be difficult at times. There may not be a clear break point in the story, developers would rather have one large story, or the Product Owner may want everything at once. Large stories lead to carry over, and carry over leads to missed commitments. “INVEST” is a way to help with breaking down stories.
INVEST originates from an article written by Bill Wake as a checklist to asses the quality of a user story. If the story does not meet each point of the checklist, the Agile team should consider rewriting, or discuss ideas on how to break the story down.
A good user story should be:
Independent of all other stories and being able to implement them in any order.
Negotiable details of the user story that will be created together with the Stakeholders, Produce Owner, and the Agile Team.
Valuable output that is useful for the main consumer, whether it be a user or a technology.
Estimable to a good approximation. As easily estimable story shows the user story was refined well.
Small so as to fit within an iteration and to control any potential scope creep.
Testable outcome to prove the satisfaction of the Acceptance Criteria.
Using “INVEST” will help ensure that user stories are small, effective and contribute positively to the development process.
Relative Sizing
You completed refining story using “INVEST”, answered the important outstanding questions, used the story template, and the story matches the Definition of Ready. What next? It is time to size the user story.
User story sizing is a hard concept to grasp. Team members new to Agile default to using hours as the size. Other team members will just make a size big to cover every possible worst case scenario. Presenting Relative Sizing will help the team understand how to size a user story.
To start, find two to three user stories the team have completed in the past, ideally a story the entire team would know how to complete. Try to find user stories that was small, medium, and large. These stories will be your reference stories.
When it is time to size a user story, ask if the story is more or less complex than the medium story. If there is a wide range of sizes for the user story, ask the team members on the extremes to explain why they thing the story is the same, or close to the reference stories. Remind the team that the goal of sizing is not to be 100% accurate, but a rough estimate. As time goes on, user story sizing will become easier and more accurate.
Resetting the reference user stories as your team becomes more mature is key. As a team progresses, skills and knowledge continue to get stronger. Something may have been complex six months ago due to a lack of knowledge of the technology may be simple now. Setting new reference user stories every three to six months will make user story sizing more accurate, leading to strong Sprint commitment.
Conclusion
Implementing these tips will maximize the benefits of your Agile Product Backlog Refinement. A healthy Product Backlog Refinement will lead to higher quality user stories. Higher quality user stories mean more accurate Sprint Planning, and high quality iterations.
Share in the comments what tips that work for you and your team to improve this important Agile ceremony.
Find these tips helpful? Check out my tips for other Agile ceremonies:
Tips for an Effective Daily Scrum Stand-up
Tips for an Effective Agile Sprint Retrospective
Tips for an Effective Agile Sprint Review
Tips for an Effective Agile Sprint Planning
👏 If you have enjoyed reading my article, remember to comment, clap, and highlight. It will encourage me to write more content.
