Mais conteúdo relacionado

Similar a Backlog Refinement 101 & 202(20)


Backlog Refinement 101 & 202

  1. Backlog Refinement David Hanson July and August 2022
  2. 2 Backlog refinement is not a Scrum event, but instead is an ongoing activity during the Sprint required to decompose, describe, estimate, and order backlog items in the Product Backlog. This material is divided into two sessions. The first session will review the basics of backlog refinement, covering various options for conducting the activity. The second session will cover tips for maintaining a healthy backlog and potential anti-patterns. About the sessions… About my experience… Wrote my first user story in 2000 using XP. Refined a story in pairs, then began the work. Our goal: start-to-finish in a week. We usually failed. In 2008, applied Scrum, with one line stories. Discussed the story only briefly when pulling into the sprint, then in depth when beginning the work. Just-in-time worked. By 2013 was applying a definition of ready to user stories with acceptance in recurring backlog grooming, prior to sprint planning. So smooth! Introduction
  3. 3 About your experiences… …and why are you here?
  4. 4  Refinement: Why & How  Scrum Guide: 2017 vs. 2020  Options: How & When (4)  10% Time & Size (2)  Process Responsibility & Pattern (3)  Poker Planning (2)  Useful Resources  The “Fourth” Artifact  Common Backlog Items  Backlog Grooming Refinement  Developers’ Viewpoint  Tips for a Healthy Backlog (5)  Potential Anti-patterns (7)  Shu-Ha-Ri  Story Splitting (5)  Scaled Backlog Refinement  Sample Agendas  Scrum Master Role  Story Mapping (3)  Just Enough Refinement 101 (17) Refinement 202 (14) Appendix (12) Session 101, Session 202 and Supplemental Material
  5. 101
  6. 6 To have a steady flow of high value, ready stories for the team to deliver to the customer Why? How? That’s left undefined, for the team, to discover what works best for them Backlog Refinement
  7. 7 Development team should anticipate spending up to 10% of their time on refinement Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. 2017 2020 Refinement “is an ongoing activity to add details” During the Sprint: ● The Product Backlog is refined as needed; and, Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work. Scrum Guide Direction Backlog Refinement IS an activity during the Sprint event related the Product Backlog artifact. Backlog Refinement is NOT identified as a Scrum Event.
  8. Backlog refinement variations and activities
  9. 9 PO or team members prepare stories in advance PO reviews stories with team for refinement once or twice a week in recurring meeting Scrum Guide recommends up to 4 hours of sprint planning for 2-week sprint 4 hours is ample time to refine stories during planning PO with analyst or SME can prepare stories in advance Leverage abbreviated refinement meeting or sprint planning for review with team Backlog Refinement Meeting During Sprint Planning Refinement Specialists Pro: just-in-time without distractions Con: might find key story not ready Pro: less distraction, more expertise Con: less team, more silo Pro: most common, familiar approach Con: distracts team from sprint goal Refinement Options PO: Product Owner
  10. 10 Once or twice a week for an hour or two Preference for end of day refinement, so team remains focused on daily goal In daily Scrum, PO can request refinement for a ready story Meet after daily Scrum up to 30 minutes or alternative dedicated timeslot Make time between sprints for refinement (& improvements) Incorporate feedback from sprint review just-in-time for sprint planning Recurring Meeting Ongoing Daily Between Sprints Pro: continuous on-demand Con: distracts from daily goal Pro: keeps focus during sprint Con: diverges from Scrum Guide Pro: develops rhythm Con: another meeting When to Refine? Tip: schedule activity for a Monday and cancel when a holiday, assuming team generally has ample ready backlog
  11. 11 What worked? What didn’t work? What have you tried?
  12. 12 New > Refine < Ready To Do Doing Done Product Refinement Sprint Refinement Iteration Refinement Keyword Refinement State Good; some tools might leverage these keywords Better; customizing tool for purpose Fair; a clever hack supported by some tools Refinement Backlog Can you achieve the same results with less overhead? Product Backlog Best; no extra overhead and usually out-of-the-box “Refine” “Estimate” Ready 5 pts Not Ready Ready __ pts Ready __ pts Not Ready
  13. 13 If 1 of 5 team members has BA skills, that member could spend half-time refining backlog That’s 10% of the development team’s time The team could pull in spikes and accept ad hoc requests to support the PO in refining stories The team could allocate 10% of their capacity for this activity The team might meet daily for an hour to refine stories, except on first and last day of sprint That’s 10% of the development team’s time Business Analyst Spikes and ad hoc requests Refinement Meeting Final refinement with the full team left for Sprint Planning Final refinement already done, Sprint Planning could be abbreviated Final refinement with the full team left for Sprint Planning No more than 10% of Developers’ time How might 4 hours per developer per week be spent? Recommend some blend of all three
  14. 14 Smaller Teams Larger Teams Team Size How might smaller or larger teams impact backlog refinement?
  15. 15 Who is responsible for what? Who can add story to backlog? Who prioritizes or rejects new story? Who refines new story? Who decides if story ready? Who signs off on story before development begins? Product Manager Technical Manager Clients Product Owner Scrum Master Team Members
  16. 16 Product owner (PO) Not ready stories ordered by priority 1. Pull not ready story from top of backlog 2. PO reviews story and acceptance with team 3. Team asks questions and provides feedback 4. PO refines story and acceptance based on feedback a. Split by value or effort b. Add or modify details c. Reorder by priority or dependency 5. Team estimates story using poker planning 6. If research needed to point story, then spike added 7. If story too large, then team may split story 8. Repeat until timebox reached Ready stories, not ready stories with spikes, updated order Development team Backlog Refinement Meeting: A Common Pattern Supplier: Input: Process: Output: Consumer:
  17. 17 Time per story might be 5 to 10 minutes If more time needed, then story not ready Recommend simple close enough rules for pointing If not close enough, then story not estimable; therefore, not ready Split larger stories, if needed, during refinement Spikes should be defined with similar rigor to stories, except timeboxed Remove unnecessary and duplicate stories Defer lower value or less urgent stories Refinement Meeting Considerations It’s about the conversation and a shared understanding
  18. 18 Most common Agile estimation technique Leverages Fibonacci series: 1, 2, 3, 5, 8, 13, 21 Team initially establishes some very simple benchmark story as 1 pointer A relative estimation of complexity and effort Accounts for all the work from ready to done A 2-pointer is twice as complex as a 1-pointer Team very quickly “knows” the relative sizes against the baseline stories What How PO reviews story with team Team asks questions and PO responds SM asks if ready to estimate Team members each select a Fibonacci number SM asks team members to reveal estimates SM asks one low and one high to comment why consider simpler or more complex PO may provide more information SM asks team to re-estimate If team converges then story pointed Else story not ready Poker Planning PO: Product Owner SM: Scrum Master
  19. 19 Why points, not hours? Why relative effort and complexity? Why Fibonacci? Why high and low? Why converge? Why benchmark? Why whole team? Why not PO and SM? Why Alternatives Ideal days instead of story points Modified Fibonacci: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 Additional cards: 0, ?, ∞, , Benchmark: instead of 1 point, try 2 points Poker Planning Image:
  20. 20 Product Goal Definition of Ready Backlog Refinement Resources What other resources might be useful during refinement? Independent Negotiable Valuable Estimable Small Testable
  21. 21 Product Backlog and Sprint Backlog both contain Backlog Items Analogously: Sprint contains Planning, Daily Scrum, Review, Retrospective Artifact: Backlog Item* Commitment: Definition of Ready* Must commit to meet Definition of Ready before pulling into Sprint Backlog from Product Backlog Analogously: Increment Commitment: Definition of Done The Fourth Artifact *Not an official Scrum artifact or commitment, but I would argue that the individual element warrants consideration Independent Negotiable Valuable Estimable Small Testable As a <user>, I need <function>, so that <purpose>.
  22. 22 Initiative Epic Feature Story Spike Defect Impediment Kaizen Activity (Jira: Task) Story Spike Defect Kaizen Story Spike Defect Task (Jira: Sub-task) Impediment Activity (Jira: Task) Product Backlog Backlog Refinement Meeting Sprint Backlog Epics, Kaizens and Tasks are generally NOT discussed in Backlog Refinement Tasks may be defined during 2nd half of Sprint Planning or during Sprint itself Lack consensus on definition and scope of Feature relative to Epic Common Backlog Items Tools and company implementation may dictate the types of backlog items available
  23. 23 verb: groom; 3rd person present: grooms; past tense: groomed; past participle: groomed; gerund or present participle: grooming 1. a. brush and clean the coat of (a horse, dog, or other animal). b. (of an animal) clean the fur or skin of. c. give a neat and tidy appearance to (someone). d. look after (a lawn, ski slope, or other surface). 2. a. prepare or train (someone) for a particular purpose or activity. b. (of a pedophile) prepare (a child) for a meeting, especially via an internet chat room, with the intention of committing a sexual offense. Original term, now considered non-PC because of recent usage describing nefarious behaviors (definition 2b) Backlog Grooming Anyone know why this term has gone out of favor?
  24. 24 Concluding Questions Who pretty much follows an approach outlined here? How’s it working? What’s not working? How has your backlog refinement evolved? Did you come away with any take-aways? What might you try in your next backlog refinement? What was most valuable to you?
  25. Appendix 101
  26. 26 So, team can confidently commit to completing story within a sprint So, PO can separate high value, low effort from low value, high effort So, PO can identify hidden value and team identify hidden effort Why split stories? Different users need this and that for one thing or another 21 Value Effort
  27. 27 Value vs. Effort User needs this or that for something 8 User needs this for something 3 User needs that for something 5 Value Effort
  28. 28 Hidden Value or Effort User needs this or that for something 8 User needs that for something 5 Value Effort User needs this for something 5 User needs this and that for something else 3
  29. 29 Split by acceptance criteria Split by keywords: and, or, either, with, using, lists Split by user roles Split by happy and unhappy paths Split by workflow* A More Advanced Technique Split into tasks and reassemble Seek simplest set of tasks adding value, then add incrementally Some Simple Techniques Vertical, not Horizontal Do not split horizontally Do split vertically Story Splitting Techniques * Use with caution; don’t want to deliver one step in a workflow if doesn’t deliver value to user User Interface Database Middle Tier UI Browse DB Browse MT Browse UI Order DB Order MT Order UI Pay DB Pay MT Pay
  30. 30 Spikes: split off research of architectural design or technical implementation options Paths: consider the many paths the user may navigate, both happy and unhappy, as well as the many options Interfaces: first a simple interface, then a complex interface; first a mobile interface, then a web interface Data: support a subset a data, then an expanding data set; support correct data, then errant data Rules: consider the various business rules, starting with simple rules, and adding complexity Mountain Goat’s SPIDR Approach to Splitting
  31. 31 PI Planning involves the Scrum team in a form of backlog refinement In addition to epics and stories, SAFe recommends intermediate-sized capabilities and features, as well as architectural enablers Product managers, POs and representative SMEs from ARTs may refine capabilities and features System architects refine enablers, which can be epics, capabilities, features, or stories SAFe Scrum @ Scale PO Team should meet regularly for scaled backlog refinement to break down epics into stories, resolve dependencies, and align stories with respective teams Scaled Backlog Refinement
  32. 32 Purpose: Maintain steady flow of high value stories Activity: 1. Discuss near-term product goals 2. Start with highest priority story not yet pointed 3. Read story description and acceptance criteria 4. Confirm who, what, why and elaborate if needed 5. Confirm acceptance and elaborate if needed 6. If ready, point story using poker planning 7. If not ready, mark not ready 8. If too large, then split story 9. If uncertain, then add spike, if appropriate 10. Reorder priority of story if appropriate Attendees: Scrum Team, led by PO, facilitated by SM Backlog Refinement Scaled Backlog Refinement Purpose: Insure aligned backlogs across team of teams Activity: 1. Discuss near-term product goals 2. Order epics & stories in backlog to align with goals 3. Align epics or stories with respective team backlogs 4. Identify and resolve stories with cross-team dependencies (by ordering or splitting) 5. Optional: draft new epics or stories, refine existing epics or stories, split large stories Attendees: Product Owner Team, led by Chief Product Owner, facilitated by Chief Scrum Master My Most Recent Refinement Meeting Agendas
  33. 33 David Hanson 17:45 01:47
  34. 34  Refinement: Why & How  Scrum Guide: 2017 vs. 2020  Options: How & When (4)  10% Time & Size (2)  Process Responsibility & Pattern (3)  Poker Planning (2)  Useful Resources  The “Fourth” Artifact  Common Backlog Items  Backlog Grooming Refinement  Developers’ Viewpoint  Tips for a Healthy Backlog (5)  Potential Anti-patterns (7)  Shu-Ha-Ri  Story Splitting (5)  Scaled Backlog Refinement  Sample Agendas  Scrum Master Role  Story Mapping (3)  Just Enough Refinement 101 (17) Refinement 202 (14) Appendix (12) Session 101, Session 202 and Supplemental Material
  35. 202
  36. Exercise Preview Zoom annotation
  37. 37 Backlog Refinement: A Summary from the Developers’ Viewpoint The product backlog is maintained through product backlog refinement: § Refinement is the continuous act of adding detail, estimates, and order to items*. § Product Backlog refinement is the responsibility of the Product Owner. § The Product Owner may enlist the help of the Developers to refine the Product Backlog. § Refinement should not take up more than 10% of the Developers' time. § The Developers may create and add new Product Backlog items to assist the Product Owner. The Product Owner remains accountable and should always be the gatekeeper to the Product Backlog. § The higher the order of the Product Backlog item, the more refined it should be. § The Product Backlog should contain enough “ready” Product Backlog items for the Developers to pull into a Sprint Backlog in the next Sprint Planning and that can be “done” to accomplish a Sprint Goal. § Product Backlog refinement is an ongoing activity during the Sprint, not an official Scrum event. § The Product Owner and the Developers collaborate in the refinement process as an ongoing activity. * as well as decomposing and removal of items Courtesy: 17:52 01:47
  38. Tips for maintaining a healthy product backlog
  39. 39 Which Product Backlog appears healthiest? What’s wrong with the other backlogs?
  40. 41 Backlog Depth & Order Typical goal to maintain 1 to 3 sprints of ready pointed stories Arguably less is more, since a backlog is inventory and inventory is waste Order backlog based on risk, value, urgency, dependency, and tentative sprint goals Items lower in the backlog generally larger and not ready (e.g., epics, not stories) Number of backlog items should be relatively fewer in number Groom backlog to remove lower value items (consider rejecting or deferring) Assume team completes ~10 stories per sprint with average velocity 40 points Top backlog: ~20 ready stories mostly 2 to 5 points Mid backlog: ~15 stories not ready stories not pointed roughly 5 to 21 points Bottom backlog: ~10 epics perhaps sized S, M, L or 20, 40, 100 points Tips for a healthy product backlog Image: Essential Scrum: A Practical Guide to the Most Popular Agile Process
  41. 42 8 pts Ready If points not converging during poker planning, then not ready Do not repoint incomplete story started in prior sprint Tips for a healthy product backlog: Pointing Leverage spikes for research needed to get stories to ready Do repoint stories not started in planning if learned something new Independent Negotiable Valuable Estimable Small Testable 8 pts Not done 5 pts Done 3 pts To do 5 pts Ready 3 pts Ready This sprint Next sprint 18:06 01:47
  42. 43 What size stories might be ideal for your sprint backlog? Assume team’s average velocity is 40 points for 2-week sprint 8 5-point stories 8 point story 8 point story 8 point story 8 point story 5 8-point stories 21 point story 2 21-point stories 13 3-point stories 13 point story 13 point story 3 13-point stories 2-point stories 20
  43. 44 Product backlog items with less detail are better than product backlog items with more detail Just enough may be more for a new team Just enough will be less for a mature team <=> ? ->+ ! Less is More Imperfect is Good Product backlog items need not be perfect; if they are, then you are spending too much time Product backlog items are conversation starters; anticipate refining items during refinement Purphiktlee inpurphikt? Perfectly unperfect! Tips for a healthy product backlog item Just enough and just OK is just right
  44. Potential backlog refinement anti-patterns
  45. 47 Independent? - Team member may write own tasks, requiring another story written by another member to be developed in parallel Negotiable? - Product owner may be removed from the discussion and shared understanding, questioning story in sprint review Valuable? - Story may be written from developer’s perspective without understanding the desired outcome for the user Potential Anti-pattern: Developers write stories, not product owner While the product owner may delegate these activities to the team or team members, why isn’t the product owner more involved? Estimable? - Team members might defer to the individual who wrote the story with risks and opportunities overlooked Small? - Stories may be split horizontally by layer or skill set, rather than vertically, reducing collaboration and cross skill development Testable? - Acceptance criteria may become a task list, as the developer considers how the work will be delivered, not user expectations 18:17 01:47
  46. 48 A story to write a story, perhaps with signoff? Maybe even design teams adding to cycle time? Acceptance criteria and definition of done? Requirements Story Design Story Acceptance Story Best architecture and designs emerge Business and developers work together daily Software over documentation Potential Anti-patterns: Stories before ready and after done Consider a Scrumban workflow like Professional Scrum Kanban to track story before ready and after done. Continuous integration and continuous delivery? Deployment Story Give them the environment they need What was transformed: traditional practices or Agile processes & tools?
  47. 49 Activity Defects Kaizens Want velocity to decrease if create defects! Always pull an improvement and just do it? Want velocity to increase as routine activity automated! Potential Anti-patterns: To point or not to point? What would be the impact on velocity if pointed or not pointed? Spikes Timebox instead of pointing, but what size timebox?
  48. 50 Resist the temptation to delve into the “how” Discuss only enough to point confidently If really need to consider “how” at length before pointing, then consider adding a spike for research Discussing How Tasking Resist the temptation to break down the story into tasks during refinement Acceptance criteria shouldn’t be a task list either Potential Anti-patterns: Implementation details Leave these details for second half of sprint planning, when committing to do the work 1) Conduct analysis with business signoff 2) Design solution with architect approval 3) Write code with tech lead review 4) Test solution with QA manager check 5) Document support with manager signoff 6) Deploy with change control approval
  49. 51 Backlog should be force-ranked ordered list During refinement, may reorder, however, do not recommend assigning a sprint Promotes push instead pull culture* *In sprint planning, if story does not align with goal or velocity exceeded, team needs to push story back to product backlog Assigning Sprint Assigning Owner Story owner or lead should never be assigned Team member may volunteer to own or lead story, but save that for sprint planning Assign should be banned language in Agile* *It’s unfortunate that our “Agile” tools use legacy language like “Assigned” associated with traditional push culture Potential Anti-patterns: Assigning promotes traditional push culture ASSIGN 18:32 01:47
  50. 52 NOT READY Applying close enough rule during the first round Applying a not-so-close close enough rule Take the mode or the median Don’t take the mean Round up to next Fibonacci If not close enough, do not point, story not ready Don’t be tempted to drop the outliers Not Close Enough Averaging No Consensus Finding the mean requires extra effort, potentially implies false precision, and discourages finding consensus through shared understanding No consensus implies story not estimable and therefore does not pass INVEST criteria Looses the conversation which can generate a shared understanding and identify the risks and opportunities Potential Anti-patterns: Not so close averaging Scrum Inc promotes all these practices based on belief that estimation is wasteful and effort estimating should be minimized 5 5 8 8 8 2 3 5 8 1 3 3 3 5 8 8 5 5 8 8 8 6.8 5 5 8 8 8 2 5 5 5 1 3 5
  51. 53 Continued Planning or Re-planning Backlog refinement is pre-planning for future sprints, not continued planning or re-planning for current sprint Why is this happening? • Was sprint goal well-defined? • Were product backlog items ready? • Did sprint planning skip tasking? Potential Anti-patterns: Backlog refinement as current sprint re-planning Why? What? How?
  52. 54 Potential Anti-patterns: Shu-Ha-Ri I suspect we all follow one or more of these anti-patterns; if they work for your team, great Shu: When starting, I encourage following the rules, to create a solid foundation Ha: Then experimenting, bending the rules, testing to see if you get better results Ri: Eventually, we’ll just be Agile, transcending the rules, intuitively doing what works Starting with Shu can eventually lead to Ri Starting with Ha rarely leads to Ri without moving back to Shu Image: transcendence
  53. 55 Concluding Questions Who follows one or more potential anti-patterns? What are the negative impacts, if any? Why have those anti-patterns developed? What could you do to improve? Did you come away with any take-aways? What might you try in your next backlog refinement? What was most valuable to you here? 18:41 01:47
  54. Appendix 202
  55. 57 Scrum Master’s Role Related to Refinement No mention of the Scrum Master. Other than ensuring that refinement happens, is productive and positive, and perhaps facilitating as needed, what is the Scrum Master’s role in refinement? Regarding the Scrum Master’s service to the Product Owner, the Scrum Master’s role is: • Helping find techniques for effective Product Backlog management; • Helping the Scrum Team understand the need for clear and concise Product Backlog items; • Helping establish empirical product planning for a complex environment; On the other hand, the Scrum Master does not necessarily have to participate in refinement at all. 18:45 01:47
  56. 58 Who Story Workshops Where: in-person at a whiteboard with markers and stickies, if possible Quarterly objective Story mapping User story writing What Whole team Stakeholders and users, optional 6 to 12 participants Start of project to build initial backlog Then quarterly or every major release cycle A couple hours to a full day Focus on a single major objective Minimum viable product increments Better outcomes, better experience When Why
  57. 59 Users have Personas with Goal Activity becomes Epics or Themes Backbone becomes Features or Epics User Tasks become Stories First Release Slice is MVP User Goal Story Mapping
  58. 60 Patton’s Story Mapping Overview
  59. 61 A Smart Summary for just enough Sprint Sprint
  60. 62 David Hanson
  61. 64 What Else? Estimating epics:

Notas do Editor

  1. Prepared Sep 2021, Feb 2022, Mar 2022
  2. What it is instead of what it isn’t From 2001, paused using stories, instead leveraging incremental specs with Kanban. Awesome!
  3. Why did you attend? What do you hope to gain?
  4. 1
  5. Maybe add What and When
  6. Notes from Scrum Patterns: Order, decompose, estimate As well as track dependencies and value Split until ~10% backlog
  7. 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.
  8. Should I specify duration? Could replace between sprints with PI or sprint planning
  9. 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
  10. 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
  11. 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.
  12. 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.
  13. 5-15 minutes?
  14. Could include risk with complexity and effort If high risk, then suggest spike Does not include duration
  15. 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.
  16. 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)
  17. Skippable
  18. Skippable
  19. What was most valuable to you here?
  20. Add slides on how split stories?
  21. 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?
  22. 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.
  23. 1
  24. Who’s returning? Why are you here?
  25. 3
  26. Assume team has 1 week sprints and completes 4-5 items per sprint
  27. 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.
  28. 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.
  29. Why? Dr. Sutherland recommends splitting until ~10% of sprint backlog, which equates to about 10 stories per sprint.
  30. 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?
  31. 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
  32. Pointing everything potentially rewards activity. Pointing selectively ideally rewards accomplishment.
  33. Illustrate forecasting using velocity
  34. 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
  35. What was most valuable to you here?
  36. Simplify and add graphic: Single major objective Whole team, plus stakeholders and users optional Quarterly Leverage story mapping
  37. 3