Backlog Refinement 101
Backlog Refinement 101
Answering questions related to backlog refinement sessions.
đ Hello,
Iâm Vibhor, and welcome to my weekly newsletter, the âWinning Strategy.â Every week I answer one question from you about agile, product, roles, processes, frameworks, career growth, working with humans and anything else thatâs stressing you at your office. Send me your questions here, and in return, Iâll offer actionable, down-to-earth, and straightforward advice.
Note: If you enjoy reading this post, would you mind showing your support by clicking the little gray heart below the title above? It would really mean a lot and help spread the word about this growing newsletter. đ
On to this weekâs question!
Q: Hi Vibhor! Want to get your insights on backlog refinement sessions. I hear everyone suggesting grooming the backlog before Sprint Planning but it remains the most ambiguous part of Scrum. How to sell it to the team who sees no value in it?
Thanks for the question.
To understand âBacklog Refinement,â imagine that you and your family are planning a vacation for next year.
Backlog refinement is like researching and creating a list of potential vacation destinations (PBIs). You and your family (the team) work together to understand the requirements and expectations of the upcoming get-together (the Sprint). The family works collaboratively to break the requirements (everyoneâs wants and needs) into realistic (allowed by the duration of vacation) and manageable chunks and then prioritizes those chunks based on various factors such as cost, time, and overall desirability.
This ensures that everyone is on the same page about what the vacation should look like and that the chosen destinations are well-defined and feasible.
Sprint Planning, on the other hand, is like creating a detailed itinerary for the vacation. Your family works together to select a subset of the prioritized destinations (user stories) to visit during the upcoming vacation (sprint) and then decides how (the day, booking tickets, who should lead) to visit those destinations for maximum fun.
In summary, backlog refinement is the process of defining and prioritizing the overall objectives of the product (Product Discovery), while sprint planning is the act of selecting a subset of those objectives and creating a (somewhat) detailed plan for achieving them during a specific timeframe (usually 2 weeks).
Is Backlog Refinement a Scrum event?
An event is a required meeting (according to the scrum guide).
Backlog refinement is not a Scrum event. It is a useful but optional exercise. It is optional because this exercise can be done as a part of the Sprint Planning meeting.
I would advise you not to get caught up with the technical jargon of the Scrum guide. Use whatever your âteamâ needs and discard the rest.
Who leads the refinement sessions?
The PO or Product Manager usually leads backlog refinement sessions. However, the Scrum Master or another team member can also take the lead occasionally.
The session leader takes on the following responsibilities:
Schedule the meeting, invite relevant participants, and ensure their attendance.
Keep the team focused on objectives and prevent off-topic discussions.
Move the conversation forward if the team gets stuck on a specific topic for too long.
Communicate essential information to the team after the session ends.
The lead makes sure that the meeting stays on track.
What are the best practices for PB refinement?
1. Frequency: Ideally, the refinement should be an ongoing activity, taking place throughout the Sprint. However, a dedicated refinement session can be scheduled regularly, such as once a week or once every two weeks, depending on the team's needs and the product's complexity.
2. Duration: Allocate a reasonable percentage of the team's capacity to backlog refinement, typically around 5-10%. For a 2-week Sprint, this may translate to 2-4 hours of refinement. It's crucial to strike a balance between spending enough time on refinement and not interrupting the team's focus on Sprint's objectives.
3. Attendees: The entire Scrum Team should be present during refinement sessions, including the Product Owner, Scrum Master, and the Development Team. This is to make sure that everyone is on the same page and can contribute their expertise. Occasionally, invite stakeholders or other SMEs to help clarify doubts or to provide additional input.
4. Follow the 15/5 Rule of Discussion: When refining a single item, it's best not to spend more than 15 minutes on it during the refinement session. It's important to timebox your refinement and revisit the item in a future session. Even if you feel satisfied with the refinement, it's a good practice to set it aside and review it again in the next meeting to ensure its completeness.
Also, don't let an unproductive conversation go on for more than 5 minutes. If a new idea is presented and you're still heavily in the "I don't understand" stage 5 minutes later, it's a good sign the PO needs to do more work offline. Come back to it in a future session.
5. Publish an agenda before the meeting: A well-structured agenda offers various benefits, including allowing team members to mentally prepare for discussions, ensuring that stakeholders or SMEs can be consulted when needed, and guaranteeing the presence of key team members with specific expertise. This enables a more productive and informed conversation.
What the agenda looks like?
Hereâs an example agenda for a typical 2-hour refinement session:
1. Welcome and introduction ~ 5 min (Can be skipped)
Introduce attendees and explain the goal of the meeting
Confirm that all stakeholders are in attendance
2. Review of Previous Sprint ~ 10 min (Can be skipped)
Review the progress made during the previous sprint
Identify any issues or blockers that arose during that sprint
Discuss any lessons learned from that sprint
3. Prioritization of Backlog ~ 15 min
Review the product backlog and prioritize user stories
Discuss any new user stories that have been added to the backlog
Identify any user stories that need to be removed or deferred
4. Making Selected User Stories Ready ~ 60 min
Use INVEST to ready the user stories
Identify acceptance criteria and define "done" for each user story
Discuss any technical or design challenges (dependencies) that need to be considered
6. Closing and Action Items ~ 15 min
Review the key takeaways from the meeting
Identify any action items or follow-up tasks that need to be completed before the next meeting
Discuss any upcoming events or milestones that need to be considered
7. Other topics ~ 10 min
Open forum for discussing any other relevant issues or topics that have not been covered in the meeting
Identify any further action needed to address these issues
Any other important information that the Scrum Master would like to communicate to the team.
Note: You can adjust the meeting duration as needed.
What a refined backlog looks like?
Most people use the acronym DEEP to visualize a refined backlog.
DEEP is nothing but a set of characteristics that a well-maintained product backlog should possess in order to support a Scrum team's work effectively.
DEEP stands for:
1. Detailed: The product backlog should contain enough detail for the Scrum team to understand the requirements of the items but not so much detail that it becomes difficult to manage. Items near the top of the backlog should be more detailed, while items further down the list can be less detailed, as they are not immediately needed for upcoming sprints.
2. Estimated: Items near the top of the product backlog should be given an estimate to indicate the effort required to complete the work.
3. Emergent: The product backlog must be treated as a living document that evolves over time. As new requirements, ideas, or insights emerge, they should be added to the backlog. This ensures that the product backlog remains up-to-date and relevant to the productâs needs.
4. Prioritized: The product backlog should be ordered according to the priority of the items, with the most important items at the top. Prioritization should be based on factors such as business value, risk, cost, and dependencies. This ensures that the Scrum team is always working on the most valuable items first.
DEEP PB = Refined PB
What a detailed user story looks like?
A detailed user story is SMALL with ACCEPTANCE CRITERIA.
Letâs imagine that your team is working on building an online bookstore. One of the high-level requirements is to allow users to search for books by title, author, or ISBN. Hereâs how you will detail this requirement.
1. Write the Epic: As a reader, I want to search for books by title, author, or ISBN so that I can easily find the books I'm interested in.
2. Split the Epic into small user stories:
As a customer, I want to search for books by title so that I can find the books I'm interested in.
As a customer, I want to search for books by author so that I can find books written by my favourite authors.
As a customer, I want to search for books by ISBN so that I can find a specific book using its unique identifier.
3. Write the acceptance criteria: Outline the specific conditions that must be met for each user story to be considered âdone.â For example, for the first user story, the acceptance criteria might be:
The search results should display books with titles containing the search keywords.
The search should be case-insensitive.
The search results should show the book title, author, cover image, and price.
The search should return results within 2 seconds.
4. Estimate the user stories: Collaborate with your team to estimate the effort required to complete each user story. For example, the team might agree that searching by title is a 3-point story while searching by author and ISBN are both 2-point stories.
5. Prioritize the user stories: The team then works with the Product Owner to determine the relative priority of each user story. For example, in this case, the Product Owner might decide that searching by title is the most important, followed by searching by author and then by ISBN.
Collection of âdetailed user storiesâ = Refined PB
Other things to do during backlog refinement
Remove user stories that are no longer relevant
Review and re-assess the priority of existing stories
Assign estimates to stories that werenât estimated before
Correct old estimates based on new information
Add, edit, or remove acceptance criteria based on new discussions
Clarify any ambiguities or uncertainties in user stories
Update story descriptions to reflect changes in requirements or scope
Address any dependencies, risks, or technical challenges related to user stories
Review the backlog against the Definition of Done to ensure all criteria are met
đ A handy technique to calculate the frequency
This is based on the length of your sprints and the team's preference for more frequent, shorter meetings or less frequent, long meetings. Here's a simple approach:
Determine the length of your Sprint (e.g. 2 weeks or 10 working days).
Work with the team to allocate a percentage of the team's capacity for refinement activities. This is typically 5-10%. For example, if you allocate 8% of a 2-week Sprint for refinement, that would amount to 0.8 days or 6.4 hours (considering an 8-hour workday).
Decide how many refinement sessions your team is comfortable with during a Sprint. This could be influenced by the productâs complexity and the team's preference. For example, you might choose to have one session per week (2 sessions per Sprint) or one session every two weeks (1 session per Sprint).
Divide the allocated refinement time by the number of sessions. For example, if you have 6.4 hours allocated and you want to hold 2 sessions per Sprint, each session would last for 3.2 hours.
Schedule the refinement sessions at regular intervals throughout the Sprint. This ensures they are spaced out to provide your team with enough time to focus on their work while still keeping the PB up to date.
Hereâs the thing.
The key is to strike a balance between having enough refinement time to keep the backlog well-groomed and not disrupting the team's focus on the sprint goal.
đ¤ˇââď¸ What to do if all members of the team are not available for refinement?
At a minimum, make sure you have the following attendees:
1. Product Owner: The PO is responsible for prioritizing and managing the PB, so their presence is crucial. They will provide the necessary context, clarify requirements, and ensure that the backlog items align with the overall product vision and goals.
2. Key dev team members: While it's ideal to have the entire dev team present, it's essential to have representatives from different functional areas or skill sets (e.g. front-end, back-end, QA, UX/UI). This ensures that all perspectives are considered, and the team can collectively estimate the effort required for each backlog item.
3. Scrum Master: Your role as a SM is to facilitate the refinement session, ensuring it stays focused and productive. Also, help the team in addressing any impediments or issues that arise during the discussion.
After the refinement session, communicate the results to the absent team members and make sure they have an opportunity to provide input or raise any concerns before the next sprint planning meeting.
đ
ââď¸ When should you cancel the refinement meeting?
Before cancelling a refinement session, explore alternatives such as rescheduling, shortening the duration, or delegating responsibility to ensure that the refinement process is not disrupted.
In the following situations, you may cancel the upcoming refinement session:
1. Insufficient attendance: If key attendees (Product Owner, Scrum Master, or crucial Development Team members) are unable to attend and cannot be replaced by suitable proxies, it might be best to cancel and reschedule the meeting. This ensures that the refinement process benefits from the necessary expertise and decision-making authority.
2. Overlapping with critical project events: If the refinement session conflicts with essential project events or deadlines, such as a major release, it may be best to cancel the meeting. In this case, ensure that the backlog refinement is rescheduled as soon as possible to maintain the momentum.
3. High team workload: If the team is under extreme pressure to complete their current sprint goals, it might be better to cancel the refinement session and allow the team to focus on their work. However, consider the impact on the upcoming sprint planning. You may need to allocate more time to it.
đ¤ How to get the teamâs buy-in for refinement sessions?
Get their buy-in by helping them understand the unique purposes of refinement sessions and the value they bring to the development process. Some of its benefits include:
Reduced time for the sprint planning meeting
Prioritization: Provides multiple opportunities to prioritize user stories
Clarity: Provides multiple opportunities to clarify user stories
Accurate estimates: Provides multiple opportunities to estimate user stories
Resource efficiency: Provides multiple opportunities to allocate the right people to the right tasks.
Risk reduction: Provides multiple opportunities to identify dependencies and risks
Continuous improvement: Provides multiple opportunities to adjust and adapt
Stakeholder engagement: Provides multiple opportunities for stakeholders to provide input, feedback, and suggestions
âł What if the team doesnât have time for refinement?
Be creative and use whatever time is available. Here are some suggestions:
1. Micro-refinement sessions: Schedule 10-15 minute daily refinement sessions to discuss one or two user stories.
2. Asynchronous refinement: Using tools like Google Docs or Confluence for team members to asynchronously review, comment, and refine user stories whenever they have a few spare minutes.
3. Priority Matrix: Use a priority matrix to identify the most important user stories for refinement quickly.
4. Time-boxed refinement techniques: Incorporate time-boxed refinement techniques like the Pomodoro Technique, where team members work on refinement for short, focused intervals (e.g. 25 minutes) followed by a short break.
5. Stand-up extension: Extend the daily stand-up meeting by 5-10 minutes to discuss user story refinement. This makes sure refinement discussions occur daily while minimizing the time commitment.
6. Pair programming for refinement: Encourage team members to engage in pair programming, where they can refine user stories as part of the development process. This practice can help identify and resolve issues more quickly.
7. Refinement reminders: Set up regular reminders or calendar events to remind team members to spend a few minutes on refinement activities each day.
8. Refinement chat channel: Create a dedicated chat channel (on Slack or Microsoft Teams) for refinement discussions. This will enable team members to discuss, refine, and clarify user stories in real-time without the need for formal meetings.
Treat these as suggestions only and customize as required.
đ
ââď¸ Common mistakes in refinement sessions
1. Not sharing the business case with the team: Developers need to understand the business problem they are solving to identify better edge cases, adjacent stories, and areas that need refactoring.
Example: Imagine your team is working on a new feature for an e-commerce website aimed at boosting sales by enhancing user experience. When the PO shares this goal with the team, they'll have a better grasp of the bigger picture, which may enable them to make well-informed decisions. They might even spot related stories, like tweaking the search function or streamlining the checkout process. Plus, they'll know if refactoring areas like the payment system is necessary before adding new features.
2. Ignoring the context of the user story: Providing context enhances team creativity, helps identify gaps between user stories, and allows developers to negotiate the sprint goal when necessary.
Example: Picture a user story about adding a new payment method to an e-commerce site. If your team doesn't know the site is expanding internationally, they might overlook opportunities to integrate currency conversion features or other localization aspects. By knowing the context, they can suggest improved solutions and negotiate the sprint goal, such as prioritizing the most important international markets.
3. Acceptance criteria not written collaboratively: Working together on acceptance criteria helps both the PO and devs understand the desired feature and catch missing information, preventing changes after development starts.
Example: Imagine a scenario where the Product Owner has created acceptance criteria for a user story centred on integrating a new search filter. Without the input of the developers, important aspects such as the filter's interaction with pre-existing filters or its effect on search performance could be overlooked. By working together to identify and address these potential issues, the development process can proceed more seamlessly, and the likelihood of necessary changes, later on, can be minimized.
4. PO leaves the meeting without clarifying the team's questions: Unclear user stories can lead to inaccurate estimates and increased effort during the sprint. Questions should be addressed in the refinement session, after refinement but before sprint planning, or in the next refinement session.
Example: Imagine a user story about integrating a new API that leaves your team questioning authentication or specific data requirements. If the PO doesn't tackle these questions during the refinement session, developers may make wrong assumptions. This may lead to increased effort or rework during the sprint. Addressing questions in a follow-up meeting or the next refinement session guarantees your team has the information they need to estimate and implement the user story accurately.
5. Insufficient stakeholder involvement: Not involving key stakeholders, such as customers, SMEs, or other relevant parties, can lead to missed requirements or misaligned priorities.
Example: Imagine your team is developing a feature for a healthcare application that helps doctors track patient progress. If you don't involve medical professionals (stakeholders) in the refinement process, you might miss critical requirements or specific needs that doctors have when using such a tool. By engaging these stakeholders, you can gather valuable insights and better tailor the application to meet their expectations.
6. Overloading the backlog with too many items: A cluttered backlog with an overwhelming number of items can make it difficult for the team to focus on the most important tasks.
Example: Imagine your team is working on a travel booking app, and the backlog contains a long list of items, including new features, bug fixes, and performance improvements. With so many items in the backlog, it becomes difficult for your team to identify which tasks are the most important or urgent. By reviewing and pruning the backlog and removing outdated or unnecessary PB items, you can help your team focus on delivering high-impact features and improvements.
7. Insufficient time allocated for backlog refinement: If teams don't allocate enough time for backlog refinement, they may rush through the process, leading to poorly defined user stories or overlooked details.
Example: Imagine your team is working on a social media platform that focuses on promoting local events and connecting users with similar interests. You have scheduled a 45-minute refinement session to discuss a variety of user stories related to user onboarding, event recommendations, and privacy settings. Due to the time constraint, the team quickly goes through the stories without having enough time to clarify doubts or explore potential edge cases. This rushed process can result in misunderstandings or never seen before challenges. By allocating proper time, your team can better understand each user story, ask questions, and brainstorm potential solutions.
đ 12 Popular tools to help with refinement
Story mapping: Organize user stories visually based on the user's journey, allowing for easier prioritization and identification of dependencies.
Hypothesis-driven development: Frame user stories as hypotheses to be tested and validated, encouraging experimentation and learning.
Shift and Share: Rotate participants in group discussions, allowing for diverse input and feedback on user stories.
Opt-in/opt-out: Allow team members to choose which user stories or refinement sessions they participate in, ensuring engagement and expertise.
Impact mapping: Visualize the relationships between user stories, outcomes, impacts, and deliverables to prioritize and align efforts with business goals.
Brainstorming: Encourage open discussion and idea generation to identify opportunities for improvement or refinement.
User Story Splitting Patterns: Break down large or complex user stories into smaller, more manageable pieces using specific patterns, such as breaking stories into tasks or focusing on different user roles.
Thinking hats: Use Edward de Bono's Six Thinking Hats technique to encourage different perspectives during refinement discussions.
Min specs: Identify the minimum set of requirements necessary to achieve the desired outcome, helping to focus refinement efforts.
Specific roles in refinement: Assign specific roles (e.g., facilitator, scribe, timekeeper) to team members during refinement sessions, ensuring an organized and efficient process.
Spikes: Use time-boxed research tasks to gather information needed for refining complex or uncertain user stories.
Value Poker: Similar to Planning Poker, use a consensus-based technique to estimate the business value of user stories, helping to prioritize the backlog.
This is it đ
Note: đ If you share parts of the post on social media, I request you to please use proper credits. I wonât be as frequent in sharing this kind of content if I have to track copies of it floating around on social media.đ
Also, if you have any questions (related to this topic), donât forget to use the comments section (on the website) to ask the community. I will try my best to get you an answer.
đđťââď¸ Your Questions!
If you want me to answer your questions in this newsletter, please send them my way using this link - Send me your questions.
If youâre finding this newsletter valuable, consider sharing it with friends or subscribing if you arenât already.
Till next week!
Sincerely,
Vibhor đ
P.S. Let me know what you think! Is this useful? What could be better? I promise you wonât hurt my feelings. This is an experiment, and I need feedback. You can reply to this email to send your message directly to my inbox.
âI share things I wish I knew in the starting years of my career in the corporate world"
Vibhor Chandel