Backlog Refinement

As we've discussed before, 0:00 the key contribution of the product owner is to maintain the product backlog. 0:01 The product backlog is a priority ordered list of items 0:06 that the team will eventually pull into a sprint to complete. 0:09 Product backlog items may include defects and technical items or technical debt. 0:13 As we learned before, 0:18 items that describe value to the user are described in user's stories. 0:19 User stories are a special type of product backlog item that describes who 0:24 will use the feature and why. 0:28 We'll learn more about how to construct user stories later in the course. 0:30 For now, we'll look at the Scrum event where these stories are discussed, or 0:34 the backlog refinement session. 0:38 Backlog refinement is also sometimes called backlog grooming, or 0:41 more playfully, story time. 0:44 However your team chooses to name the event, it is an opportunity 0:47 to review product backlog items, get input from team members, 0:51 add clarity to the items, and estimate the effort involved. 0:54 The product owner drives the conversation in backlog refinement. 0:59 The goal is to refine items in the backlog so that they are well understood, and 1:03 small enough to be incorporated into a sprint. 1:07 Generally, the product owner will begin with the items in the backlog that 1:11 are coming up, but may also incorporate new items or ones that he or 1:15 she anticipates will require a few passes 1:19 before they are ready to be taken into a sprint. 1:22 During backlog refinement, the product owner presents a product backlog item or 1:25 user story. 1:29 The product owner opens the floor to the team and 1:31 answers clarifying questions about what the story means or what it entails. 1:33 If the story is too big, 1:39 the team discusses how it can be broken into smaller pieces. 1:40 The team checks their shared understanding by drafting conditions of acceptance, or 1:44 acceptance criteria. 1:49 These describe the characteristics of a solution 1:51 without saying how the problem will be solved. 1:54 For example, a condition of acceptance might be 1:56 that the user sees relevant articles when they type a support question. 2:00 This is something that can be tested later, without having to work out all 2:04 the details of where the relevant articles are presented or how they will appear. 2:08 After a few items have been discussed, the team estimates the effort of each item. 2:14 There are many ways to estimate effort. 2:19 The most popular method is probably Planning poker. 2:21 In Planning poker, each team member gets a set of cards with story points or 2:25 effort points on it. 2:30 Each team member chooses one card and 2:32 displays it to the rest of the group, showing their estimate of the amount of 2:34 work involved in a particular user story or a product backlog item. 2:38 Story points are relative estimates of the amount of 2:42 effort it will take to complete an item. 2:44 In Scrum, we use the story points in place of time based estimates, 2:47 such as hours, because we recognize that those estimates are likely to be wrong. 2:51 It's much easier to compare two items and say that one requires a little more effort 2:56 than the other, or that one requires twice the effort of the other. 3:00 Generally, story points are assigned using a series where the steps increase in size. 3:04 This is because as we get into higher estimates, 3:09 we recognize that we really don't know how much effort something will take. 3:12 And in fact, 3:16 the item may need to be broken up into smaller parts in order to be estimated. 3:17 An example number series used for story points is the Fibonacci sequence. 3:22 The Fibonacci sequence is a series of numbers where each number 3:26 is the sum of the previous pair of numbers. 3:30 Don't worry too much about the meaning of the Fibonacci numbers. 3:33 There's a mathematical allure to the Fibonacci sequence, 3:36 which you may be interested in reading about. 3:39 But in this case, 3:42 we really just need a number sequence where each step is progressively greater. 3:42 That way, we can easily compare the effort of two product backlog items. 3:47 In fact, another sequence of numbers is also commonly used in Planning poker 3:51 based on powers of two, where each number is the double of the previous. 3:56 Again, the most importing thing here is to be able to compare the effort of 4:00 one item to another. 4:04 For example, 4:05 this story is twice the effort of another story because when team members display 4:07 their effort estimates in Planning poker, the team tries to reach consensus. 4:12 Often, the facilitator will ask team members with the highest and 4:17 lowest estimates to explain their reasoning. 4:20 For example, the Scrum master might facilitate by asking, 4:23 your estimate is lower than the others. 4:27 Is there anything about your thinking that you can share? 4:29 This is another opportunity to come to a shared understanding 4:32 on the product backlog item and the work it entails. 4:35