Sharpen your Agile Axe by Brian Sjorber
- 1. Let’s Sharpen Your Agile Ax: It’s Story Splitting Time Presented by Brian Sjoberg 8/25/2016 Developed by Ken Furlong and Brian Sjoberg
- 3. • Agile/Lean Coach at Excella • Focus on Org. Transformation • DC Scrum User Group Introduction 3
- 4. • Types of Issues (User Stories, Tasks, etc.) • User Story Syntax • Definition of Ready • Definition of Done & Acceptance Criteria • Splitting User Stories • Tracking & Reporting (Bonus) Outline
- 5. • Types of Issues (User Stories, Tasks, etc.) • User Story Syntax • Definition of Ready • Definition of Done & Acceptance Criteria • Splitting User Stories • Tracking & Reporting Outline
- 6. • An artifact to facilitate communication • User story is a way to represent a customer’s request to the team that creates a product. • Helps prevent misunderstanding • Best option so far User Story
- 7. Create Shared Understanding 7 I’m glad we all agree. Credit: User Story Mapping
- 8. Create Shared Understanding 8 Oh! Credit: User Story Mapping
- 9. Create Shared Understanding 9 Ah Ha! Credit: User Story Mapping
- 10. Create Shared Understanding 10 I’m glad we all agree. Credit: User Story Mapping
- 11. To Do • Stand up server • Build database • Build API • Build UI • Perform QA • Deploy 1 2 3 4 5 6 7 8 9 0 + - x ÷. = S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Design Documents
- 13. To Do • Stand up server • Build database • Build API • Build UI • Perform QA • Deploy To Do Stand up server To Do Build Database To Do Build API To Do Build UI To Do Perform QA To Do Deploy
- 14. S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 S M Tu W Th F S 1 2 3 4 5 6 S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
- 15. 1 2 3 4 5 6 7 8 9 0 + - x ÷. = 1 2 3 4 5 6 7 8 9 0 + . = 1 2 3 4 5 6 7 8 9 0 + - . = 1 2 3 4 5 6 7 8 9 0 + - x . = 1 2 3 4 5 6 7 8 9 0 + - x ÷. = 1 1 2 3 4 5 6 7 8 9 0.
- 16. 1 2 3 4 5 6 7 8 9 0 + - x ÷. = To Do • Stand up server • Build database • Build API • Build UI • Perform QA • Deploy
- 17. Value vs. Work Task A chunk of work that is part of delivering a particular chunk of the product (value). User Story A chunk of the product (value) that customer recognizes as a part of the whole product (value) they requested.
- 18. Value vs. Work User Stories (Product) • New search screen • Reset button on an existing screen • Automation of a manual business process Tasks (Work) • Writing code • Setting up a database table • Testing that the code works • Security scanning
- 19. Where Does Information Live? 19 Search for Something As a user, I want to be able to search for everything and get back exactly what I need and do it quickly So that I spend the least time possible finding exactly what I need. Lorem ipsum dolor sit amet, mel ei alii alienum. Id ius graece commune constituto. Invidunt senserit sea no, id inani elitr indoctum mea, sed te molestie referrentur intellegebat. Dico nullam sententiae id pri, eos oratio populo vivendo cu. Elitr partiendo ei eam, ex pericula consequuntur mel. No assum perfecto intellegebat nec, ius ex utinam graeco cotidieque. Mel ei erant tractatos, ea duo brute omnes voluptatum, pro nobis mucius virtute in. Per ponderum electram an, amet atqui aeterno et cum. Eos an oblique iuvaret, illum altera fierent nam at. Ei summo affert vituperata his. Vel te option nonumes. Ne iracundia theophrastus usu, antiopam forensibus ex his. Has tantas vidisse democritum ut, primis mollis expetendis vis ne, ei sit consul utamur repudiandae. Ea sensibus sadipscing eum. Id viris convenire sed, id eirmod principes sit. Sed an eirmod deserunt similique. Te quot putent evertitur ius, an quo tantas nominavi explicari. Ex regione platonem mea, sed assum evertitur torquatos at, ne nostro moderatius definitiones per. Ne numquam debitis pri. Legere theophrastus an mea, sed alterum platonem vituperata eu, dicta libris dicunt nam ei. Inermis invidunt interpretaris eu ius. Id sea reque errem, tollit pertinax expetendis te eum. Dicam volumus suscipiantur an duo, ne per elit salutatus, duo ei nemore concludaturque. Ei soluta admodum ius, ius an deleniti tincidunt. Reque nulla aliquid ut pri. - The system shall respond in X amount of time with the search results - Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel. - Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel. - Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel. - Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel. - Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel. - Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit. - Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit. - Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel. - Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel. - Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit. - Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit. - Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel. - Has error oratio in. Eam putent omittam salutandi no, virtute detracto cu vel. - Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit. - Te illum dicit commune vix. Nibh tota nusquam nam ut, est ut saepe assueverit. Acceptance Criteria
- 20. • Not all information lives in a user story. • There can be a lot of information we need to capture and make available that do not belong in stories. Where Does Information Live?
- 21. • Design style guide • Wireframes • Use Cases • Security standards • Test scenarios Other Information 21
- 22. • Large chunks of work that don’t pertain to a particular user story • Some use ‘technical user story’ and ‘research spike’ – Work that cuts across multiple stories (e.g., setting up an environment) – Work that pertains to larger initiative but perhaps not specific stories (e.g., research something) – Work that multiple folks will be collaborating on or that needs to be visible to others “Tech Stories”, “Spikes”
- 23. • Set up Jenkins for Continuous Integration • Set up Cucumber for Automated Acceptance Testing • Why does business care? – Jenkins – Improve health of code base that will result in faster and more reliable release delivery – Cucumber – Improve code quality by catching bugs earlier in development that will result in less defects and time to market Tech Story Examples 23
- 24. • A larger, loosely defined user story that we expect to be broken down into smaller chunks and to be defined in progressively more detail as it gets closer to being built • When an Epic is fully broken down into stories, the Epic could cease to exist (rather than serving as a category or “umbrella” for those stories) Epics
- 25. Epics 25 Epic – Initial Search Simple Search (No Perf) Auto Complete Search Suggestions after Search Search (w/ Perf)
- 26. • A user story is a chunk of the __________. • A task is a chunk of the ___________. • A chunk of technical work that doesn’t pertain to a particular user story, ____________. Review
- 27. • Types of Issues (User Stories, Tasks, etc.) • User Story Syntax • Definition of Ready • Definition of Done & Acceptance Criteria • Splitting User Stories • Tracking & Reporting Outline
- 28. • As a _____________________________ • I want ____________________________ • So that ___________________________ Standard User Story Format Starving Student on a Low Budget to find and purchase food quickly from my mobile device I can fill my stomach without spending a lot of money WHO WHAT WHY
- 29. • As a _____________________________ • I want ____________________________ • So that ___________________________ Standard User Story Format Starving Student on a Low Budget to find and purchase food quickly from my mobile device I can fill my stomach without spending a lot of money Important to know Whom this work is going to benefit. We can more easily determine the best solution and uncover implicit needs. It is critical to understand Why the Who wants the What they’re asking for. It greatly informs the final shape the solution will take and can help flag up flaws or unintended side effects in the design. WHO WHAT WHY What is most important? The Who, the What, or the Why?
- 30. 1. Customer is the person/group requesting value from team building the product 2. Ideally, customers would write the user story for the team 3. Usually, an expert assists the customer in understanding what they really want/need Notes about the customer
- 31. • Who is the “Who” in a user story? • Is the “Who” ever the team doing the work, e.g., “As a developer, I want to go do something, so that I can do something else.”? • Who typically writes the user story? Review
- 32. • As a user, I want to use HTTPS so that my connection is secure. Review 36
- 33. • As a developer, I need to determine a serialization strategy, so that I can send the API the data it needs. Review 37
- 34. • As a mobile teen user, I want to search on my phone for music that I just heard on the radio so that I can listen to it again whenever I want. Review 38
- 35. • Types of Issues (User Stories, Tasks, etc.) • User Story Syntax • Definition of Ready • Definition of Done & Acceptance Criteria • Splitting User Stories • Tracking & Reporting Outline
- 36. • When the Definition of Ready (DoR) is met, the user story could be developed. • The Definition of Ready applies to all of a team’s user stories and is more generic, e.g.: – Immediately actionable – Negotiable – Valuable – Estimated – Sized-appropriatey – Testable When Can We Start?
- 37. Product Backlog Refinement 41 Definition of Ready I N V E S T Why is this needed?
- 38. • Types of Issues (User Stories, Tasks, etc.) • User Story Syntax • Definition of Ready • Definition of Done & Acceptance Criteria • Splitting User Stories • Tracking & Reporting Outline
- 39. • When the Definition of Done (DoD) and Acceptance Criteria (AC) are both met, the user story is DONE. • The DoD applies to all of a team’s user stories and is more generic • AC pertain to a specific story When Are We Finished?
- 40. DoD Example All Code Checked-in Unit Tests Passing Acceptance Criteria Passing Integration Test Passing Performance Test Passing With a Product Back Item (PBI) With a Sprint With a Release Security Audit Passing Regression Test Passing
- 41. Continuously Improve DoD All Code Checked-in Unit Tests Passing Acceptance Criteria Passing Integration Test Passing Performance Test Passing With a PBI With a Sprint With a Release Security Audit Passing Regression Test Passing ContinuousImprovement
- 42. Continuously Improve DoD All Code Checked-in Unit Tests Passing Acceptance Criteria Passing Integration Test Passing Performance Test Passing With a PBI With a Sprint With a Release Security Audit Passing Regression Test Passing ContinuousImprovement
- 43. • Present Tense Indicative Statements, i.e., they are either TRUE or FALSE. Acceptance Criteria
- 44. Correct • There is a button in the upper left corner of the screen. Present Tense Indicative Statements Incorrect • Button in the upper left corner of the screen • Put the button in the upper left corner of the screen. • There will be a button in the upper left corner of the screen. • We need a button in the upper left corner of the screen.
- 45. • Present Tense Indicative Statements, i.e., they are either TRUE or FALSE • Generally FALSE before the product has been built • Must be TRUE for the user story to be accepted • Include Functional and Non-Functional Requirements • Complete (All I See Is All There Is) • Un-ambiguous (no etc., TBDs) Acceptance Criteria
- 46. Correct • The drop down contains each of the days of the week. • The screen loads in 1.5 seconds or less 95% of the time with strong 4G signal. Unambiguous Incorrect • The drop down contains Monday, Tuesday, etc. • Load time is sufficiently fast.
- 47. • Present Tense Indicative Statements, i.e., they are either TRUE or FALSE • Generally FALSE before the product has been built • Must be TRUE for the user story to be accepted • Include Functional and Non-Functional Requirements • Complete (All I See Is All There Is) • Un-ambiguous (no etc., TBDs) • Speak in the language of an official Domain Model / Glossary • Include Examples when helpful Acceptance Criteria
- 48. • Determine if each of the following are well- formed acceptance criteria: – “New fields” – “Add the new fields to the JSON response.” – “The JSON response will contain a ‘Type’ field.” – “The JSON response contains a ‘Type’ field.” – “The JSON response is returned in less than 500 milliseconds 95% of the time with a strong 4G signal.” Review
- 49. • If all of the acceptance criteria are TRUE, is the story accepted? • Who determines whether the acceptance criteria are TRUE? • What do we do if a story is partially done at the end of a day, week, iteration, or release? Review
- 50. • If we are using story points, should the team receive some points for completing some of the work? Review
- 59. • Types of Issues (User Stories, Tasks, etc.) • User Story Syntax • Definition of Ready • Definition of Done & Acceptance Criteria • Splitting User Stories • Tracking & Reporting Outline
- 60. • There are several “fault lines” along which you can split most stories. • These fault lines usually appear pretty clearly in the acceptance criteria, if they are well-formed and complete • Helpful to well-form a story before you split it too far – Until well-formed, it may appear irreducibly complex when it really isn’t Splitting Stories
- 61. Defer Performance As a user, I can search for flights between two destinations ...(slow - just get it done, show a “searching” animation). ...(in under 5 seconds). Examples of Splitting Stories Operations (e.g. CRUD) As a user, I can manage my account. ...I can sign up for an account. ...I can edit my account settings. ...I can cancel my account.
- 62. Major Effort As a user, I can pay for my flight with VISA, MasterCard, Diners Club, or Amex. ...I can pay with Visa. ...I can pay with all four credit card types (VISA, MC, DC, AMEX). Examples of Splitting Stories Data Entry Methods As a user, I can search for flights between two destinations. ...using simple date input. ...with a fancy calendar UI.
- 63. • Well defined Acceptance Criteria (AC) for a large story can typically be broken down into smaller stories with own AC • Example AC – I can create a user – I can delete a user – I can update a user’s information Acceptance Criteria Splitting Credit: SmallerStories.com
- 64. • Form groups of 3 • Discuss ways to split one or more of the stories on the worksheet Group Exercise
- 65. • Look for connector words: – And, Or, If – When, But, Then – As well as, Commas Conjunction Splitting Credit: SmallerStories.com
- 66. • Form groups of 3 • Discuss ways to split one or more of the stories on the worksheet Group Exercise
- 67. • Look for words that could be replaced with more specific terms – Nouns, verbs, adjectives, adverbs can all be generic – For example • Vehicle -> Car -> Honda Civic • Animal -> Dog -> Pug Generic Words Splitting Credit: SmallerStories.com
- 68. • Form groups of 3 • Discuss ways to split one or more of the stories on the worksheet Group Exercise
- 69. • Pretend User Story is done • What happens when the functionality is used? • If there is a sequence, then it may be possible to break into smaller stories Timeline Analysis Splitting Credit: SmallerStories.com
- 70. • Form groups of 3 • Discuss ways to split one or more of the stories on the worksheet Group Exercise
- 71. • Types of Issues (User Stories, Tasks, etc.) • User Story Syntax • Definition of Ready • Definition of Done & Acceptance Criteria • Splitting User Stories • Tracking & Reporting Outline
- 72. Tracking & Reporting Things Things we track in a tool Things we report on • User Story • Task • Spike • Meeting • Epic • Administrivia Where does each type of thing fall?
- 74. How do we measure the factory?
- 76. How do we measure the flow in the factory?
- 77. To Do Doing Done
- 78. To Do Doing Done
- 79. To Do Doing Done
- 80. To Do Doing Done
- 81. To Do Doing Done
- 82. To Do Doing Done
- 83. When will we be done?
- 84. To Do Doing Done
- 85. To Do Doing Done
- 86. To Do Doing Done
- 87. To Do Doing Done
- 88. To Do Doing Done
- 89. To Do Doing Done
- 90. Let’s Wrap Up
- 91. • Types of Issues (User Stories, Tasks, etc.) • User Story Syntax • Definition of Ready • Definition of Done & Acceptance Criteria • Splitting User Stories • Tracking & Reporting Let’s Wrap Up
- 92. • Comments/Feedback – [email protected] – 301-404-0765 Thank You
- 93. Back Up 105
- 94. • Card – Small and could fit on a 3” x 5” card • Conversation – It is placeholder for a conversation to occur in the future. Pointer to other documents • Confirmation – Objectives identified through conversation are placed here. Three C’s of User Stories 106
- 95. • We track chunks of the product/value in a cumulative flow diagram (CFD) • It is critical to maintain the discipline of not creating user stories that aren’t chunks of value. • If there is an optics problem with capacity drains, we need to solve that in a different way. Cumulative Flow
- 96. What is this telling us?
- 97. What is this telling us?
- 98. What is this telling us?
- 99. What is this telling us?
- 100. • Anything outside the teams control that prevents the team from making progress • Many use ‘impediment’ to denote anything outside the team’s control that fully blocks or just slows them down. • When a blocker or a lesser impediment is identified, the team should escalate the issue so that it can be resolved. Blockers