User stories for BAs: overview and tips
•Download as PPTX, PDF•
2 likes•1,298 views
This document provides an overview of user stories and tips for writing them. It discusses the common elements of As, I want, So that and gives examples. Common smells or anti-patterns that indicate issues are described, including stories that are not measurable, too big, or have too much/little detail. The document concludes with an activity where attendees match example stories to smells and discuss how they could be improved.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to User stories for BAs: overview and tips
Similar to User stories for BAs: overview and tips (20)
More from Ryan Thomas Hewitt★CSM★CSPO★ITIL
More from Ryan Thomas Hewitt★CSM★CSPO★ITIL (9)
Recently uploaded
Recently uploaded (20)
User stories for BAs: overview and tips
- 1. User Stories: overview & tips Ryan Hewitt - Lead BA (DWP)
- 2. Overview of user stories As I want So that A ROLE GOAL / DESIRE BENEFI T
- 3. Overview of user stories As I want So that AN APP USER TO SHARE IMPORTANT STORIES MY FRIENDS CAN DISCOVER & COMMENT ON THESE STORIES Social media - share button (BBC Sport)
- 4. Overview of user stories
- 5. + Acceptance criteria + Expected volumes + BDD tests + Sketches & flow diagrams + Comments Overview of user stories
- 6. Overview of user stories • Customer valued functionality • Deferring detail • Verbal communication • Comprehensible by everyone • Right size for planning • Build tacit knowledge
- 7. ● Units of work ● Requirements ● Plan & prioritise Overview of user stories
- 8. ● Build the wrong thing ● Poor estimates ● Blockers ● Rework ● Low velocity ● Unhappy team :-( Overview of user stories
- 9. Tips
- 10. Tips • Start with goal stories & break down • Slice the cake • Write closed stories • Put A/Cs on cards • Size the story to the horizon • Keep the UI out as long as possible • Some things aren’t stories Mike Cohn, ‘User Stories Applied’
- 11. Tips • Include user roles • Write for one user • Write in active voice & user’s language • Don’t forget the purpose Mike Cohn, ‘User Stories Applied’
- 12. Tips As a Product Owner I want industry data (MI) about pensioners So that I can decide who to include in the Private Beta As a customer I want the spelling & content to be correct in the prototype So that we pass our internal assessment
- 13. User story smells They’re anti-patterns … an indicator that something’s amiss. Common in most teams … avoidable! Mike Cohn
- 14. User story smell Smell 1: Make everything a story As a developer… As a product owner...
- 15. Tip Smell 1: Make everything a story User Story Epic Bug Task Spike ● Agree the categories of work
- 16. User story smell Smell 2: Stories are not measurable
- 17. Tip Smell 2: Stories are not measurable Think it as a hypothesis. How will we validate it? … ● Forecast the value ● Measure it
- 18. User story smell Smell 3: Stories are too big!
- 19. Tip Smell 3: Stories are too big! ● Should be Sprintable ● Use SPIDR to break down
- 20. User story smells Smell: Too much/little detail Smell: Sliced by technology layer (not vertical slices) Smell: Dependencies on other user stories
- 21. How we improved them
- 22. How we improved them Smell Agree its a smell? Observed it? What would you do? #1 #2 #10 Match it Story 9 Story 4 Story 1
- 23. How we improved them Smell #2 Make all user stories incredibly detailed Is it a smell? Yes - especially if the team don’t need the detail Yes - some stories are simple Smell Yes - but it’s hard to know what to include
- 24. How we improved them Observed it? Yes - Product Owner wants all user stories defined for next 3 months Yes - developers won’t estimate without lots of detail Yes - when we write too much - devs ignore the ticket!! What would you do? Smell #2 Make all user stories incredibly detailed Smell Agree an example “good” ticket with the entire team Only put in necessary info. Have regular convos + demos!!
- 25. Activity time Smell Agree its a smell? Observed it? What would you do? #1 #2 #10 Match it Story 9 Story 4 Story 1
- 26. Summary ● Overview of stories (what, why, impact) ● 3 common smells ● Activity of smells & example stories @DWP_BA @rthewitt01
Editor's Notes
- Lead Business Analyst at DWP. Various companies for 10 years. Overview of user stories on Agile projects & tips for improving the quality What, Why, lifecycle of a user stories, impact of wrong Tips & 3 common pitfalls - smells Activity
- As a user, I want feature, so that <benefit> AS A <WHO> I WANT <WHAT> SO THAT <WHY> VALUE
- Why - user need. Expected business benefit End user to value Simple, short description of functionality from a user’s perspective Description of customer valued functionality
- Card, Conversation, Confirmation
- Dive into the detail of a story: What - happy path, edge cases, NFRs, sketches, flow diagrams Acceptance tests - when it’s good enough to release. Functionality, usability, analytics to measure the value
- 1. Description of customer valued functionality Why - user need. Expected business benefit End user to value 3. Simple, short description of functionality from a user’s perspective
- In most Agile teams user stories are the units of work in a Sprint. Items on a board. BA perspective >> primary artifacts. BAs user stories are way to break work into small pieces & where requirements are captured Smaller improves momemtum
- Poor estimates = lack of understanding and unclear requirements Velocity They’re hard to do Volumetrics, business goals, endpoints NFRs Accessibility Measurable Bad stories >> blockers, poor estimates, dependencies etc In most Agile teams user stories are the units of work in a sprint. Help break work into small pieces They capture requirements and ensure we have slices of functionality. Built the right thing
- Good as a pointer. But still find people were writing stories like this …. Independent — Can the story stand alone by itself ? Negotiable — Can this story be changed or removed without impact to everything else? Valuable — Does this story have value to the end user? Estimable — Can you estimate the size of the story? Small —Is it small enough? Testable — Can this story be tested and verified?
- Stories for the next few iterations should be written at sizes that can be planned into those iterations. More distant stories can be larger and less precise
- “Story smells” is a term used by Mike Cohn. It describes anti-patterns/bad practices he’s seen working with user stories
- “Story smells” is a term used by Mike Cohn. It describes anti-patterns/bad practices he’s seen working with user stories Established teams … new teams
- Based on my experience Frankenstein piece User stories are one type of item on the Product Backlog. Other types include: bugs, tasks, epics, spikes. The user story format should not be used for everything in a Sprint. The user must be an end user of the system. They can be personas or types of user (e.g. admin, front end staff, passive debtor, app user etc). BA’s, Product Owners, GDS are not users. As a developer … I want … So that). User stories are written from the perspective of end users. User stories are one type of item in the product backlog. Other types of item include: bugs, tasks, epics and spikes. Item can be in a Sprint without being user stories. Don’t spend time thinking how a technical sub-task can fit into the user story format.
- User stories are one type of item on the Product Backlog. Other types include: bugs, tasks, epics, spikes. The user story format should not be used for everything in a Sprint. The user must be an end user of the system. They can be personas or types of user (e.g. admin, front end staff, passive debtor, app user etc). BA’s, Product Owners, GDS are not users. As a developer … I want … So that). User stories are written from the perspective of end users. User stories are one type of item in the product backlog. Other types of item include: bugs, tasks, epics and spikes. Item can be in a Sprint without being user stories. Don’t spend time thinking how a technical sub-task can fit into the user story format.
- Goldplating
- SPIDR … agree what too big is
- Working level. But could be better. The 10 smells are based on my observations I ran an activity with Business Analysts. We discussed each smell and our opinions on them 10 user story smells Smell Why we think it’s wrong 10 sample stories
- Do you agree it’s a smell? Have you observed it? What would you do if you encountered it? Any smells that are missing? There are 10 example user stories. They are bad user stories Match each user story with the relevant smell
- User stories should specify the appropriate level of information. As a story is worked on more detail will emerge. It needs to contain enough information for the team. Do you agree it’s a smell? Have you observed it? What would you do if you encountered it? Any smells that are missing?
- Do you agree it’s a smell? Have you observed it? What would you do if you encountered it? Any smells that are missing?
- Do you agree it’s a smell? Have you observed it? What would you do if you encountered it? Any smells that are missing? There are 10 example user stories. They are bad user stories Match each user story with the relevant smell
- What stories are. Why they’re used. Typical content 3 common smells: size, everything as a story, measurable Activity