In Scrum, Product Backlog Refinement is an essential meeting of the Product Owner and the Development Team to gain clarity and a shared understanding of what needs to be done through discussion and sharing of ideas. The following is a guide example of how to run an effective Product Backlog Refinement meeting.
Steve – a ScrumMaster and the hero of our story
Paula – the Product Owner of Steve’s team
Learning from their recent experience with bad User Stories, ScrumMaster Steve, Product Owner Paula, and the Development Team schedule a Product Backlog Refinement meeting, after lunch, to refine the User Stories and discuss them ahead of Sprint Planning.
Product Backlog Refinement is normally a meeting where the Product Owner and the Development Team discuss the items at the top of the Product Backlog. This used to be known as Product Backlog Grooming, but the use of the term ‘grooming’ (to make neat and orderly) is no longer recommended. The goal is to ensure that the Product Backlog is clear and understood by everyone before the Sprint, not just make it look good.
Getting Ready for Product Backlog Refinement
Paula doesn’t use a formal meeting agenda; instead, she has a rough checklist she shares with the Team:
- Share story stubs or ideas written by herself and rewrite them to be effective User Stories through discussion with the Team
- Acceptance Criteria for topmost items in the Product Backlog
- Split User Stories that are too large for their current position in the Product Backlog
- Estimate Split Stories
- Acceptance Criteria for newly created Stories
- Estimate Stories without Estimates
- Create New Stories based on newly identified Stakeholder needs
Product Backlog Refinement Is All About Discussion and Asking Questions
Paula and the Team review the current state of the Product Backlog. They refine the User Stories by discussing the context for a desired product feature and what kind of value it is meant to give the user. They follow this with a discussion about how to best deliver that value. This solves the previous problem they had with the User Stories lacking a clearly defined ‘Why’ statement. It also gives the Development Team the needed context and clarity to provide accurate and useful estimates, since they have now been part of the discussion. ScrumMaster Steve’s guidance toward having this backlog refinement session, instead of blindly launching into Sprint Planning, has been a huge help.
The topmost items are estimated by the Development Team, appropriately split (1, 2, or 3 Story Points in size), and have at least two or three Acceptance Criteria associated with them.
But in order for a User Story to be useful, it must also be specific and focused. Further down in the Product Backlog there is a Story: “As a Julia (a Real Estate Agent and Frequent book buyer), I want to be able to buy a gift card to thank a fantastic recent client.” The estimate on this one is 20, so it’s agreed that they need to split this User Story.
As the Scrum Team discusses the Story, they ask Paula several questions for clarification:
- How will the recipient redeem the gift card? Paula says: it’s already covered in a later story, which is also estimated to be 20.
- Will the gift card be printable or just electronic? Paula: Electronic for now.
- Does the Story include delivering the Gift Card? Paula: Yes, by email.
- Are fancy graphics and clever messaging important? Paula: Yes, but in the first version, it would be okay to do without them.
- What gift card amounts are supported? Paula: $10, $25, $50 and $100.
- Are gift cards refillable, or one-time use? Undecided.
From this discussion, they create some new Stories and estimate them:
- As a Julia, I want to be able to buy a $10 gift card so that I can thank a fantastic client. Limitation – not delivered just generated – Estimate: 5 points
- As a Julia, I want my newly purchased gift card sent by email to its recipient so that they can use it immediately. – Estimate: 13 points
- As a Julia, I want to be able to refill a gift card I previously purchased. – Estimate: 8 points
- As a Julia, I want to be able to buy a gift card in denominations of $25, $50, and $100 so that I have choices in how much money I want to spend. – Estimate: 13 points
- As a Julia, I want fancy graphics and text on my gift card to satisfy my inner diva. – Estimate: 8 points
On seeing that refillable gift cards will cost 8 Story Points, Paula says, “That’s expensive for the value I get,” and pushes it down in priority. She also sees that the combined cost of the $10 gift card Story and the alternative denominations gift card Story is 18 Story Points – quite large. She asks the Team if it would be cheaper to do gift cards with any amount. They come back with an estimate of 8, pointing out that it’s still more complex than the basic Story.
They create a new Story, sized 8, and move onto establishing some basic acceptance criteria:
Basic “Buy Gift Card” Story
- Price Range $5 – 100
- Tax not charged to gift card buyer
- Receipt displayed
- Gift card displayed in buyer’s order history
Basic “Send Gift Card” Story
- Get a friend’s email address
- Assume valid email and don’t do checking – will be handled later
- Send Gift Card via email
- Text-only gift card
“Fancy Text and Graphics” Story
- Looks good in the browser when the buyer sees it
- Looks the same in: Outlook, Gmail, Hotmail, iPad, iPhone, Android phone
All of this discussion leads Paula to realize that being able to use a gift card is as important as buying one. As a result, the Team repeats the whole exercise for the Story to “Use a gift card.”
They wrap up the session by discussing the needs of new publishers who Paula is talking to about selling their products through the bookstore. They outline the rough idea of some Stories to support this need but don’t bother estimating them, as the talks with the publisher are still in their early stages. They can expand and refine them in a future Product Backlog Refinement session if the need arises, rather than spending time unnecessarily speculating now.
How to Have an Effective Product Backlog Refinement Meeting
Product Backlog Refinement is intended to help your team clearly understand the Product Backlog and the User Stories in it. To ensure you will always have a successful meeting, there are three outcomes I suggest that new ScrumMasters aim for:
- Greater Understanding – Merely telling people you want something built will likely result in you not getting what you envision. Instead, start with a collaborative mindset that is focused on engaging the Team and Product Owner, and refining User Stories based on a shared understanding of what function they are meant to deliver, who it’s meant to help, and why it’s important.
- Greater Conscious Engagement – When you’re involved in creating a User Story, you get to feel a sense of ownership of the product. As a result, you are much more likely to be motivated to engage in getting to “done.”
- Greater Subconscious Engagement – Our subconscious does an excellent job of generating connections and seeing relationships between things. However, it works on its own schedule, often slowly. Ideally, you should have a few days separating Backlog Refinement and Sprint Planning, allowing everyone to see the User Stories several times (perhaps on a big whiteboard at the front of the room) before Sprint Planning, giving everyone’s brain time to make connections between seeing the Story and then trying to plan for it.
In addition to benefiting the Team and the Product Owner, you will likely find that you improve your own understanding as a ScrumMaster of the Product Backlog and what can be developed within a reasonable amount of time.
Product Backlog Refinement is a vital part of Scrum. It increases the effectiveness and communication of the entire Scrum Team and, as a result, builds a better product for your client.
Do you want to coach your team towards better solutions?
The WorldsSmallestOnlineBookStore.com Team went from facing ineffective User Stories, to having a productive Backlog Refinement session and a clear path for the next Sprint. This was largely due to ScrumMaster Steve identifying the challenge and coaching everyone toward a solution that they could apply collaboratively, which improved communication between Product Owner Paula and the Team. If you would like to learn how to handle some of these common, real-life issues that organizations face in their Scrum evolution, consider attending one of our workshops, where you’ll receive hands-on learning of the challenges – and solutions – and tips on how to integrate them into your Scrum.
Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. If you are new to the series, we recommend you check out the introduction to learn more about the series and discover other helpful articles.
» Next Scrum by Example – The Story of an Incomplete Sprint
See all blog posts