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.
Dramatis Personae:
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,[1] 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[2] 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[3] 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[4] (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.
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.
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.
[2] Mark’s note: It is strongly recommended that the Product Owner not show up at Product Backlog Refinement with prepared User Stories. My personal experience is that team members see these items as complete/correct and it kills further discussion on them. It’s much better to bring rough ideas to the session and work with the team to make them real User Stories.
[3] Caveat: Scrum works perfectly well in an environment where the Development Team doesn’t estimate – in that case, they can skip the estimation portion of refinement. You would also expect a Team that wasn’t estimating to put more effort into splitting Items at the top of the Product Backlog so that they’re approximately the same size.
[4] In order to better understand different kinds of end users, those working on WorldsSmallestOnlineBookStore.com have started using Personas to give a richer description of each. In this case, the relevant persona is known by the name “Julia.” Two things matter in this context: she is a frequent book buyer and user of the site, and she gives her real estate clients gift cards to thank them for their business.
Image attribution: Agile Pain Relief Consulting
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Hello,
Thank you very much for these articles and for these stories.
I have the following question:
– what’s the difference between sprint planning and product backlog refinement, since sprint planning is there to discuss the product backlog, estimate them, and split the stories.
– How much effort does backlog refinement take on teams.
– The final question is whether we do the backlog refinement in one meeting before the sprint planning or in multiple meetings during the sprint.
Thank you.
Foaud – sorry that I’ve been a bit behind in answering comments here. I think the key issue here is that you summary of Sprint Planning: “is there to discuss the product backlog, estimate them, and split the stories” isn’t one I would agree with. That is a rough outline of Backlog Refinement. Sprint Planning has three purposes – agree on Sprint Goal; select the Product Backlog Items for the Sprint and decide how achieve those PBIs.
When Backlog Refinement is done during Sprint Planning, the team tend to rush through the refinement portion. When they attempt to select PBIs they bog down because they’ve not had enough time to understand.
My frequent quip is that the leading cause of crappy Sprint Planning is not enough time in Backlog Refinement. As to the amount of time it takes? Simple spend enough time with the Team and PO that the top 10-15 PBIs are always well understood.
To better sense the overall flow of Scrum see: https://agilepainrelief.com/the-story-of-a-sprint