Mark Levison
Posts: 877
Nickname: mlevison
Registered: Jan, 2003
|
Mark Levison an agile software developer who writes Notes from a tool user.
|
|
|
|
ScrumMaster Tales – Product Backlog Refinement in Action
|
Posted: May 20, 2014 8:59 AM
|
|
The ScrumMaster Tales is a series of stories about ScrumMaster John who attended one of my courses. He is the ScrumMaster for the WorldsSmallestOnlineBookstore. Learning from past mistakes, Product Owner Sue schedules a regular Product Backlog Refinement session once a week, on Thursday’s just after lunch. The goals are to ensure the Product Backlog is well prepared for the next Sprint Planning session and to help the Product Owner flesh out the Product Backlog further into the future. She invites the whole team, and most of the time they all attend. Instead of a formal meeting agenda, she just has a rough checklist she shares with the team: Acceptance Criteria for topmost items Split 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 Sue and the team review the current state of the Product Backlog. The topmost items are estimated, well split (1, 2, 3 Story Points in size), and have at least 2-3 Acceptance Criteria associated with them. However down at position fifteen, there is a Story “As a Julia[1] (a Real Estate Agent and Frequent book buyer), I want to be able buy a gift card to thank a fantastic recent client”. The estimate on this one is a 20, so it’s agreed a split is required. As they discuss the Story, several themes emerge: How will the recipient redeem the gift card (Sue says it’s already covered in a later story – also sized 20). Will the gift card be printable or just electronic? Electronic for now. Does the Story include delivering the Gift Card? Yes, by Email. Are fancy graphics and clever text important? Yes, but in the very first version Sue says it would be okay to do without them. What gift card amounts are supported? $10, $25, $50 and $100. Are gift cards refillable, or one-time use? Undecided. When they’re done, they’ve created some new stories and estimated all of them. Story Estimate As a Julia I want to be able buy a $10 gift card so that I can thank a fantastic client. Limitation – not delivered just generated 5 As a Julia I want my newly purchased gift card sent by email to its recipient so they can use it quickly. 13 As a Julia I want to be able to refill a gift card I previously purchased. 8 As a Julia I want to be able to buy a gift card in denominations of $25, $50 and $100 so I can have choices in how much money I want to spend. 13 As a Julia I want fancy graphics and text on my gift card to satisfy my inner diva. 8 On seeing that refillable gift cards will cost 8 Story Points, Sue says, “That’s expensive for the value I get,” and pushes it down in priority. She also sees that combined cost of the base Story $10 gift card and the alternative denominations gift card is 18 Story Points, still 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 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 browser when the buyer sees it Looks the same in: Outlook, Gmail, Hotmail, iPad, iPhone, and Android phone All of this discussion led Sue to realize that being able to use the gift card is as important as buying them. As a result, the team repeated the whole exercise for the Story to “Use a gift card”. … They wrap up the session by discussing the needs of new publishers who Sue is talking to about working with the bookstore. They outline the rough shape of some stories to support the need, but don’t bother estimating them, saying that the talks with the publisher are still in early stages. Analysis Product Backlog Refinement is intended to help the team ensure that they truly understand the Product Backlog. Outcomes: Greater Understanding: Telling people about something you want built makes it likely they don’t see the same thing you do. By engaging team members in refining the Stories, Sue helps grow a common understanding. Greater Engagement: When you’re involved in creating a Story, you feel a greater sense of ownership and engagement in getting to done. Engage the Subconscious – Our subconscious does an excellent job of generating connections and seeing relationships between things. However, it works on its own schedule, often slowly. By seeing the Stories several times before Sprint Planning, and having a few days between seeing a Story and trying to plan for it, our brains have time to make the connections. In addition to benefiting the team, Sue improves her understanding of her own Product Backlog and what can be built for a reasonable amount of time. She also gains input on building a better product from the Team Members. What has your team gained from ongoing Product Backlog Refinement? [1] At the WorldsSmallestOnlineBookStore we use Persona’s to give us a richer description of an end user. In this case the relevant person is “Julia”. In this case two things matter: She is a frequent book buyer and user of our site; She gives her clients gift cards to thank them for their business.
Read: ScrumMaster Tales – Product Backlog Refinement in Action
|
|
Previous Topic
