Art of Storytelling - User Stories Smells and Anti-patterns
•
1 recomendación•1,072 vistas
Agilists employ user stories as a way to capture user requirements and drive the planning process for iterative and incremental delivery of software. Traditionalists with experience in “big requirements up front” often struggle with the brevity of user stories and how to best communicate requirements. In this presentation, we will look at common anti-patterns and mistakes that teams unknowingly employ when writing user stories. Come learn how to identify and avoid these mistakes. Understand what size is the right size for a user story and how to properly split a user story. Discover different boundaries for prioritizing stories. Learn how to decompose a story until it is ready for development. Leave with new insights on how to write effective user stories. Blog post available at: https://www.kaizenko.com/the-art-of-storytelling-user-story-smells-and-anti-patterns/
![User Story – Smells and Anti-patterns @fadistephan | kaizenko.com
Which Line is Most Important?
As we wait for the session
to start, meet your
neighbors and discuss
which part of the user story
is most important?
– Who?
– What?
– Why?
– Acceptance Criteria?
As a [role/who],
I want [feature/what]
so that [value/why]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
Último
Último (20)
Destacado
Destacado (20)
Art of Storytelling - User Stories Smells and Anti-patterns
- 1. By Fadi Stephan @FadiStephan User Story Smells & Anti-patterns
- 2. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com Which Line is Most Important? As we wait for the session to start, meet your neighbors and discuss which part of the user story is most important? – Who? – What? – Why? – Acceptance Criteria? As a [role/who], I want [feature/what] so that [value/why]
- 4. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com 20+ years of experience in software development Technology Consultant, Agile Coach and Trainer Co-organizer of the DC Scrum User Group (DCSUG) www.kaizenko.com @KaizenkoLLC @FadiStephan Fadi Stephan
- 6. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com Simple, clear, short description of customer valued functionality. 3 C’s: Card, Conversation, Confirmation. Represents customer requirements.
- 7. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com As a [type of user], I can [goal] so that [value] Title: Notes: Assumptions: Estimate: Constraints: Priority:
- 8. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com As a book shopper, I want to checkout using my credit card so that I can purchase a selected book. Checkout Using Credit Card Notes: Support mc, visa, amex 2 5 Constraint: Must use Chase p 13 pts
- 9. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com I can use mc, visa, amex I cannot use expired cards I can only use cards with valid cvv I can only use cards with valid zip code Checkout Using Credit Card
- 13. Right Size
- 14. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com Understandable
- 15. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com Iterative Development
- 16. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com Smells and Anti-patterns
- 17. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns 1. Forgetting about the Conversation
- 18. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns As a [type of user], I can [goal] so that [reason] Title: Notes: Assumptions: Estimate: Constraints: Priority:
- 19. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns As a [type of user], I can [goal] so that [reason] Title: Notes: Assumptions: Estimate:Constraints: Priority: “Get smaller cards”
- 20. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns As a [type of user], I can [goal] so that [reason] Title: Notes: Assumptions: Estimate:Constraints: Priority: “Get smaller cards”
- 21. How do I describe what I want? How do I validate that this work is done? How do I break this up and sequence my work? What are the details of what I need to code? http://www.flickr.com/photos/improveit/1470706210/in/photostream
- 23. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com 2. Thinking that Everything has to be a User Story As a developer, I want to install Jenkins so that I can enable continuous integration. Upgrade Dev Environment
- 24. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com 2. Thinking that Everything has to be a User Story As a team member, I need to go to the restroom so that … Take a Bio Break
- 25. Bugs
- 26. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com 2. Thinking that Everything has to be a user story As a Product Owner, I want bug 1342 fixed so that users can correctly edit their user information without getting stuck Fix bug 1342
- 28. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns 3. Thinking that a User Story has to be Everything • Excel spreadsheet with business rules • Wireframe • Workflow diagram • Design document • Use cases
- 29. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com 4. Skipping the Acceptance Criteria Checkout Using Credit Card I can use mc, visa, amex I cannot use expired cards I can only use cards with valid cvv
- 30. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns 5. Not Having A Definition of Done All Code Checked-in Unit Tests Passing Help Text Updated Acceptance Criteria Passing Integration Test Passing Performance Test Passing With a Sprint With a Release Security Audit Passing Regression Test Passing ContinuousImprovement With a PBI
- 31. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com 6. Taking on Stories that are Too Big or Risky http://www.flickr.com/photos/87857621@N00/191311751
- 32. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns Too Big or Risky http://www.flickr.com/photos/87857621@N00/191311751
- 33. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com 7. Splitting Stories Incorrectly
- 34. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com S l i c e s V e r t i c a l
- 35. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com Data Boundaries http://www.flickr.com/photos/7762644@N04/2533281806
- 41. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com 8. Not Having a Definition of Ready
- 42. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns 9. Skipping Product Backlog Refinement PBI PBI PBI PBI Add Split Reorder Remove High priority to next Sprint Granularity Fine Coarse Reorder
- 43. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns Progressive Elaboration Title As A User… UI Sketch Detailed AC Meets DoR EPIC Story Story Ready Story Ready Story
- 44. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com Recap 1. Forgetting about the conversation 2. Thinking that everything is a user story 3. Thinking that a user story is everything 4. Skipping the Acceptance Criteria 5. Not having a Definition of Done 6. Taking on stories that are too big or risky 7. Splitting stories incorrectly 8. Not having a Definition of Ready 9. Skipping Product Backlog Refinement
- 45. User Story – Smells and Anti-patterns @fadistephan | kaizenko.com Which Line is Most Important? As we wait for the session to start, meet your neighbors and discuss which part of the user story is most important? – Who? – What? – Why? – Acceptance Criteria? As a [role/who], I want [feature/what] so that [value/why]
- 46. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns Questions?
- 47. @fadistephan | kaizenko.comUser Story – Smells and Anti-patterns References • Agile Estimating and Planning, Mike Cohn • User Stories Applied, Mike Cohn • Mountain Goat Software: http://www.mountaingoatsoftware.com • Agile Product Design: http://www.agileproductdesign.com
Notas del editor
- Picture: http://www.flickr.com/photos/psd/2423294079/sizes/l/in/photostream/
- Mike Cohn: simple, clear, short description of customer valued functionality 3 parts: written description used for planning, conversation to flesh out details, tests to determine completeness. Ron Jefferies: 3Cs - Card, conversation, confirmation. Rachel Davies: user story represents customer requirements rather than documents them.
- Template: As a type of user, I can achieve some goal so that I can gain some value. Add a title, some notes, assumptions, constraints, priority, estimate.
- Examples
- Examples
- On the back, we add acceptance criteria. Use this template for acceptance tests: Given [context] And [some context] When [event] Then [outcome] And [another outcome]. Or simpler version of verify or test.
- User stories directly support the Agile manifesto: User stories support focusing on working software over comprehensive documentation. Conversation supports individuals and interactions and customer collaboration. Brevity and high level of user story supports responding to change.
- Emphasize verbal rather than written communication. Encourage conversation, face to face discussions as opposed to document handoffs.
- Encourage deferring details until you have better understanding about what you really need. Avoids unnecessary detailed planning which might change by the time we reach development time.
- Provide right size for planning. High level, focus on value and can be prioritized.
- Comprehensible by customers and developers. Picture: http://www.flickr.com/photos/90001203@N00/172506278/
- Works for iterative development. Start at high level and flush out details with each iteration and repeat.
- Too much info. Running out of room?
- Tom Poppendieck advises us to use smaller card. User story covers the who, what and why? It does not cover how? That is where the conversation comes in.
- Tom Poppendieck advises us to use smaller card. User story covers the who, what and why? It does not cover how? That is where the conversation comes in.
- The main purpose of a story is to act as a reminder and encourage conversation to flush out details the closer we are to implementing a story. Business, PM, Developer, Tester Picture :http://www.flickr.com/photos/improveit/1470706210/in/photostream
- User stories directly support the Agile manifesto: User stories support focusing on working software over comprehensive documentation. Conversation supports individuals and interactions and customer collaboration. Brevity and high level of user story supports responding to change.
- Combine many small items onto one larger story. Example: Bug reports can be combined into one “Fix Bugs” story.
- Use human user. Write story from user’s perspective and understand his goal and value for the story. Avoid using generic as a user or as a customer. Think of role as group of users that share common characteristics and based on those characteristics their interactions with system will be different. Think penny pinching college student, busy corporate lawyer, or juggling mother of 3. Try to profile roles and figure out how often will they use the system, how much domain knowledge do they have, are they technically savvy, what is their goal? Pain points? Use extreme users. Extreme users are not really target audience, but simply bringing them up can produce different context and lead to interesting discussion. For example, think of the Pope. Or think of a hacker. As a hacker, I can access customer’s payment information to pay for my vacation. Picture: http://www.flickr.com/photos/12426416@N00/163959411
- More examples
- Helps team understand when a story is complete. Scooping Helps team test against a criteria discussed and agreed to Emerge and evolve over time
- Size – Too big Cannot give accurate estimate: Story needs to be more manageable and enable more accurate estimate. Cannot fit into iteration: If for example iteration is 1 week long and story is longer than week then it needs to be split to fit into iteration. Cannot fit into what’s remaining of iteration: Team has already committed to 38 story points and there is still room for 2 point story but remaining stories are 3 story points or more. Picture: http://www.flickr.com/photos/87857621@N00/191311751
- Risk: If complex and risky, split to create spike story which is experimental in nature with main goal to gain technical knowledge. Picture: http://www.flickr.com/photos/95457978@N00/495352477
- Slice Vertically: Stories should represent some level of end to end functionality. This reduces overall risk and delivers value to customer. Do simplest thing that could possibly work. Important to not split stories into tasks like design, code front end, code middle tier, code back end. Better to deliver cohesive subset of all layers of feature than delivering all of one layer as standalone. Having entire backend ready without corresponding GUI is not very useful. Having feature that allows user to add entity through GUI and have it persisted is functionality that can be useful and provides some value.
- Data Boundaries: Separate local requirements from international requirement. Handling one type of credit card from another. Start with USD then add foreign currency. Picture: http://www.flickr.com/photos/7762644@N04/2533281806
- Operational boundaries: CRUD boundaries. Separating into search which returns search result count and then search display which displays actual results. Happy path 1st , exceptions next. Picture: http://www.flickr.com/photos/7729940@N06/3076476665
- Cross Cutting Concern: Features that effect multiple aspects of the application like security, logging, error handling can each be separated out of main functionality features. Screen with different menu options based on the login user’s credentials. Security specific feature can be split from main functionality of screen. Picture: http://www.flickr.com/photos/53611153@N00/303892944
- Performance constraints: Split functional requirement from non functional requirements. Example: Feature can be enabled without caching and then another story can handle caching specifics. Picture: http://www.flickr.com/photos/32165728@N00/183211819
- Dependency Story dependent on another story makes it hard to give correct estimate. Split so one story handles dependency and other handle specifics. Picture: http://www.flickr.com/photos/15923063@N00/4972049904
- A story contains multiple sub stories that are large enough to stand out on their own. Photo: http://www.flickr.com/photos/41317431@N00/2579139642/
- Priority: Multiple priorities within a story. Login story might have different priorities for authentication than for handling error conditions like locking out user after multiple logins. Necessity: Minimum needed to get working software. Flexibility: What are some alternative ways of doing it, what additional data we want to capture. Safety: Better validation rule to avoid ugly error messages. Comfort, luxury, and performance: More usable, sexier to look at (animation), hot keys. Opening game: Skeleton spans system and contains necessary features 2. Mid game: Add capability, flexibility and safety 3. End game: Finish with usability, performance, sex appeal and reserve time for unforeseen additions and adaptations Picture: http://www.flickr.com/photos/15639842@N00/4182148160