This is an excerpt from Exploring Scrum: The Fundamentals.
Scrum Backlog Refinement includes moving Stories into the Back Burner and further refining them until they are Ready to go to Planning. In order to do this there are some basic things that must be done:
- It must be determined if Backlog Items are to be worked on soon; if they are, then they are candidates for moving to the Back Burner. Note that these Items can come from the Fridge, the Freezer, or the InBox.
- There are a number of factors to consider when moving Items to the Back Burner:
- If the Item is already ‘small’ enough to be a Story, it may be moved to the Back Burner directly for further refinement, or
- If the Item is an Epic, Stories must be extracted from it and moved to the Back Burner. In either case,
- The Stories that are moved should be examined, and rewritten if necessary, so that their goals are simple, clear, and correct.
- Once Stories are in the Back Burner, they are further refined to make them Ready for Planning.
These things should be obvious, but you’d be surprised how confusing it can get once you start doing it. By concentrating on one thing at a time, it gets easier. Nevertheless, there are a number of issues involved, which I will now discuss.
Refinement, Waste, and Targets: First of all, we don’t want too many Stories on the Back Burner, as this is inventory (and hence waste) in the Lean sense. By moving Stories to the Back Burner, the Team is predicting what they will be working on soon. This prediction is non-agile (as all predictive behavior is), and is (at least partially) reinventing the notion of having a detailed requirements document. In practice, this could be ok, but philosophically, this bothers me… just sayin’…[contextly_sidebar id=”U0I8LtEHfyYzFPLzQeO1KQfrRfHDxrXh”]Therefore, I recommend that a Team has no more than two or three Sprint’s worth of Stories in the Back Burner at any given time, and sometimes I think that even this is a bit much.
On the other hand, the Team needs some predictability – they usually feel better if they have some targets to shoot at. Since the Team is usually working within the context of a Release, these targets often take the form of fixed (even if ambiguous) Release Goals. Having Release Goals as targets that put bounds on what the Team does allows the Team some mid-term predictability and stability. This tension between the Team wanting to know what’s going on and needing to keep the inventory down is an ongoing issue for all Teams, and resolving it in favor of smaller inventory is a good sign of Team maturity – the more work on the Back Burner, the more immature the Team usually is.
Activities of Backlog Refinement: Now let me be a little more specific about what Backlog Refinement is, and expand on the basic responsibilities I presented above. Each of these activities is the responsibility of the Team, led by the Product Owner, and may involve help from the Stakeholders and SMEs. Many Teams view this as a ‘PO thing’ – and it is – but the Product Owner must feel free to use the Team and SMEs as his or her staff to help with this. Anyway, here they are:
Prioritize Items in the Backlog for further Refinement: The first thing to do is figure out which Items need to be in the Back Burner to be Refined. These Items could come from the Fridge (the usual source), the Freezer, the InBox, or just ‘show up.’ This prioritization is based on many factors, including which Capabilities are in scope, how close to releasable each of them is, and the prioritization strategies discussed later in this chapter. We usually do this prioritization with input from Stakeholders, and is clearly a responsibility of the Product Owner.
Place Stories in the Back Burner for further Refinement: Once the Items have been prioritized for moving to the Back Burner, the Team (with input from SMEs) analyzes each Item, (possibly) rewrites it, and actually moves it to the Back Burner. If the Item is already a Story (not an Epic) the Story may be moved over as-is or re-written and moved. If the Item is an Epic, Stories must be extracted from the Epic and placed in the Back Burner. This extraction could involve various forms of analysis (Use Case analysis, State-Based analysis, User Experience analysis, and so on), often assisted by SMEs. The resulting Stories should be small and, if functional, defined by just one positive test. It is likely that this analysis is something the Product Owner and Stakeholders will need help with – that this analysis usually requires expertise that these people don’t have.
Draft the Story’s Agreement and/or Tasks: In order to make the Story ’10 minutes away’ from being finalized during Planning, the Team often needs to draft the Story’s Agreement and/or Tasks. It is natural for the Team to discuss how the Story will get Done, and these drafts are just documenting these conversations. However, remember that the Agreement and Tasks are not finalized until the Sprint Planning itself and that this is, therefore, merely a draft. Storyotypes are very useful in preparing these drafts, as Storyotypes contain standard Agreements and may contain sample Tasks.
Size the New Stories: If your Team requires it, it may also need to size the new Stories in StoryPoints, EffortPoints, or both. The sizing in EffortPoints may be useful for the Team’s Sprint Planning, and the sizing in StoryPoints is necessary if it is tracking the expenditure of budgeted StoryPoints. In the latter case the Team must also re-size the Epic it is extracting the Story from, in order to keep the Epic’s StoryPoint budget current. The sizing of a Story should be done as the Story’s Acceptance Criteria and Agreement become clear, and should be re-done if they change in any significant way.
Preparing SMEs for Sprint Planning: Refining Stories should include getting commitments from SMEs ahead of time (before agreeing to the Story at Sprint Planning) if their participation is necessary for completion. For example, this is often true of Analysis Stories or Architectural Stories, where getting info from SMEs could be the whole point. This is a bit of predictive planning, and could be replaced with verifying the SMEs availability during Sprint Planning itself, but it seems to me that setting it up ahead of time is reasonable mitigation of the risk of them not being available. It seems to me that giving the SME a ‘heads up’ is a simple matter of manners and living the Team Values.
Finding new Capabilities: Even though it’s not actually in scope for Backlog Refinement, it often happens that the Team working with SMEs will find new Capabilities. These Capabilities should be placed in the Fridge, the Freezer, or the InBox (whichever is appropriate), in order to be dealt with later. I recommend that these new Items not be dealt with in detail as they’re found, but sometimes it’s tempting to do so because the SMEs are with you. It certainly seems reasonable to get a one paragraph description of the Capability as long as the SMEs are there, and if the Team must do it, it should keep the conversation short.
Refinement Sessions versus Refinement Stories: I just discussed some of the activities that take place during Backlog Refinement, but when do we do it? Basically there are two choices: Refinement Sessions as part of the Team’s process, and Refinement Stories that are prioritized as part of the Backlog. Each of these methods has its strengths and weaknesses, and I recommend that most Teams do both.
Specifically, I recommend that the whole Team, as a group, has 4 hours of Refinement sessions a week, probably in two 2-hour bursts. These sessions could include SMEs and should focus on Items that will be coming up soon. I recommend that the Team should have a maximum of two or three Sprint’s worth of Stories ready to go in the Back Burner, so this limits the extent of these Sessions.
I also recommend that the Team have specific Refinement Stories that are worked on by one or two Team Members working with SMEs. These Stories should be used when either the SMEs are not available for Refinement Discussions, or when the Refinement itself is complex. Refinement Stories are a specific kind of Analysis Story, and usually focus on extracting and refining Stories from Epics, rather than finding new Items – which is the focus of other types of Analysis Stories.
To learn more about Backlog Refinement, check out chapter 3.9 of Exploring Scrum, which can be purchased on Amazon.