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 […]
↧