Backlog Refinement 101 & 202

Editor's Notes

• #2: Prepared Sep 2021, Feb 2022, Mar 2022
• #3: What it is instead of what it isn’t From 2001, paused using stories, instead leveraging incremental specs with Kanban. Awesome!
• #4: Why did you attend? What do you hope to gain?
• #5: 1
• #7: Maybe add What and When
• #8: Notes from Scrum Patterns: Order, decompose, estimate As well as track dependencies and value Split until ~10% backlog
• #10: Large team: perhaps only a subset of team refines stories with PO prior to planning Everyone on team writes stories; potential for wide range of story style and quality; potential anti-pattern to be discussed later PI Planning is also opportunity to define and refine stories. A Scrum Book: The Spirit of The Game; mentions refinement initially during planning, but teams found the meeting too long.
• #11: Should I specify duration? Could replace between sprints with PI or sprint planning
• #13: Where to find the refinement backlog in your tool? Some teams may define a sprint without dates as the Refinement Backlog Stories can be ordered in that backlog Pull from that backlog to sprint backlog Some teams tag or label story with “Refine” or “Estimate” keyword Define query to return stories with that keyword Alternatively filter product backlog view on keyword Customize story workflow with Refine state after New, before Ready Once story drafted, move to Refine state Once story refined, move to Ready state Simply order product backlog per priority New stories not ready, define with team or skip Ready stories w/o points, refine and estimate Ready stories w/ points, already refined
• #14: Alone, each approach is probably too much, but a blend of all three might just right. Might also suffice with 5% of Developer’ time, especially if PO is dedicated to team and writing majority of stories. Larger teams would need more analyst or meeting time than smaller teams, since larger teams should complete more or larger stories. PI Planning
• #15: Scrum guide had recommended 5 to 9 developers per team. Arguably, here, one team is too small and the other team too large. Recent trend is towards smaller teams, maybe 4 to 8. Small teams: less diversity and insight into what might make the story easy or hard; if one member unavailable may be hard to ensure success. Large teams: anticipate larger backlogs and more time on refinement; might consider refining stories with subset of team and reviewing with entire team only in planning. In this example, I’d recommend splitting the 10-person team into two 5-person teams.
• #16: Who can add? Anyone, although less likely clients. Who accepts, rejects, and prioritizes? PO, only PO. Everyone else can try to convince him! Who refines? Better when PO leads with assistance from team. If PO delegates to team or team member, PO remains accountable. Who decides story ready for sprint? Team members; enforced by SM.
• #17: 5-15 minutes?
• #19: Could include risk with complexity and effort If high risk, then suggest spike Does not include duration
• #20: Why points, not hours? Good at affinity sizing, poor at estimating; hours would depend on skill and experience level. Why relative effort and complexity? Good at relative sizing, this larger than that; sometimes the effort is big even though simple, sometimes complexity requires rework, research, or risk; creates ambiguity in the estimation, that’s okay. Why Fibonacci? As size increases estimation may be “accurate” but not “precise”; deviation in estimate increases with size; avoid debating is this a 6 or 7? Why high and low? Rapidly identify risks and opportunities; no need to ask every low or every high; can always catch in next round. Why converge? If doesn’t converge, then does it pass the “estimable” criteria in INVEST? If not converging, story may need rework or spike to research. Why benchmark? Helps team get started. Caution later stories may be smaller, so may want to introduce ½ pt or benchmark at 2 pt. Why whole team? Want shared understanding, range of viewpoints, and all work represented. Coding might be easy but testing complex or vice versa. Why not PO and SM? Only those that do the work estimate. For mature teams, I don’t mind when the PO and SM also estimate.
• #21: Sprint Goal, if known in advance Product Roadmap helps too User Personas if available Definition of Done, maybe Not shown: Story Map INVEST AD (actionable, demonstratable)
• #23: Skippable
• #24: Skippable
• #25: What was most valuable to you here?
• #27: Add slides on how split stories?
• #29: Order might matter. If “this and that” done last, might be 2 or 3 points; if done second, might be 3, 5, or 8 points; if done first might be 8 or 13 points? Consider some actual examples?
• #32: Dan Mezick recommends top backlog have stories of roughly similar size, mid backlog have epics roughly sprint size, and bottom backlog have bigger initiatives. Dan recommends that a product owner team facilitate definition of the mid backlog epics independent of the Scrum team.
• #35: 1
• #36: Who’s returning? Why are you here?
• #37: 3
• #40: Assume team has 1 week sprints and completes 4-5 items per sprint
• #42: Dan Mezick recommends top backlog have stories of roughly similar size, mid backlog have epics roughly sprint size, and bottom backlog have bigger initiatives. Dan recommends that a product owner team facilitate definition of the mid backlog epics independent of the Scrum team.
• #43: When defects increase, velocity decreases; when activity automated velocity increases. When only stories pointed, velocity becomes a proxy for value (admittedly imperfect proxy). If pointing defects then make sure team has quality metric. If pointing everything then make sure team has value metric. Also set expectation with PO and stakeholders, that if story passes acceptance and passed user acceptance, then it’s a new story, not a defect.
• #44: Why? Dr. Sutherland recommends splitting until ~10% of sprint backlog, which equates to about 10 stories per sprint.
• #48: Good balance? 80% PO, 20% team, when starting? 50% PO, 50% team, when mature and team productivity outpaces PO? 20% PO, 80% team, when single PO supporting team of teams? Anyone might start 20% story with PO filling in 60% details and 20% updated during refinement?
• #49: Requirements Consider instead tracking this as work to get a story from not ready to ready PO should be accountable for maintaining a ready backlog greater than the team velocity Design Consider if design required for story to be ready or if design can be part of story implementation Design teams might establish set of approved design patterns for development teams to use Acceptance and Deployment Consider instead tracking this work as overhead in supporting users during acceptance and release engineers during deployments If user discovers an error or new requirement, then add defect to sprint backlog or story to product backlog Advanced teams may automate these steps and incorporate into Definition of Done
• #50: Pointing everything potentially rewards activity. Pointing selectively ideally rewards accomplishment.
• #52: Illustrate forecasting using velocity
• #54: Consider a mid-sprint Reverse Scrum* Review progress towards sprint goal Adjust sprint goal & backlog if warranted Still have need for replanning? Consider a shorter sprint Especially if sprint goal changes week-to-week Consider Kanban Especially if priorities change day-to-day
• #56: What was most valuable to you here?
• #59: Simplify and add graphic: Single major objective Whole team, plus stakeholders and users optional Quarterly Leverage story mapping
• #69: 3