Writing user stories is more than just changing the format of the requirements. Think differently about the product and the user and keep ideas simple and independent.
Fordham -How effective decision-making is within the IT department - Analysis...
User stories primer - how to think differently about constructing stories
1. In this session we’ll talk mainly about user stories and not the overall methodology. Some of
that will creep in along the way, but we won’t focus on it.
All you really need to know about agile for today is: Communicate more, Cut out waste by
questioning the process, and work in smaller increments.
2.
3. what is a user story: a high-level definition of a requirement, containing just enough
information so that the developers can produce a reasonable estimate of the effort to
implement it.
Typical formats
As a, I want to because
As a temporary library employee, I want to check in these books, so they can be
reshelved.
Given, when, then – enables more contexts (givens) & outcomes (thens.)
Given that I am new here, when a patron returns a book, then enable me to check
it in and tell me where it goes.
Remember Personas – think about the motivation of the subject of the story. E.g. "As a
library patron, I want to log in because ….. why?" A user doesn't want to log in ever.
The story may be "As the system owner, I want users to log in so we can ensure proper
authorization / use of our data/ system /// .. " Or what else? WHY do we want people
to log in? be clear about it.
4. •How user stories are different from requirements - The biggest difference is in the level of
detail. User stories should only provide enough detail to make a reasonably low risk estimate of
how long the story will take to implement. When the time comes to implement the story
developers will go to the customer and receive a detailed description of the requirements face
to face. Focus on user needs. Avoid details of specific technology, data base layout, and
algorithms.
•How user stories are different from Use Cases – What the user wants to do versus specific ways
in which the user may do it. ** User stories should typically address only ONE, happy-path
scenario for how the system will be used. ***Details usually found in a use case should not be
part of the user story. User stories should be one sentence. (Use cases or other dialog about
specific use/intention comes later, during development – as a conversation.)
•What is acceptance criteria? - define the boundaries of a user story, and are used to confirm
when a story is completed and working as intended. Essentially – what grade/level of quality is
acceptable for the story? (e.g. is a confirmation necessary? Is data validated before saving?
Don't just state the story in reverse. "As a patron, I want to find a book in your library."
Acceptance: (perhaps) Tell user whether or not we own the book. Tell user whether the book is
available. Tell user shelving location. Tell user about other formats.)
5. Iterative Design & Refactoring
> We don’t want to end up with this…
… nor design for this….
6. User Story: Just get across the chasm - To find out if that’s the place we want to go
One person at a time
Build in flexibility:
>NOT so you can add specific features later
>But so you can address UNKNOWN
change with minimal impact
Build in Quality:
>Appropriate architecture and completeness
ONLY for the requirements given.
>Quality – make sure the rope isn’t frayed and
is tied tightly
7. User Story: Just get across the chasm - To find out if that’s the place we want to go
One person at a time
The best way to build in flexibility and quality is to remain SIMPLE as long
as possible.
You *might* assume that the bridge will need to be bigger/ heartier in
time .. but the requirement TODAY is to get one person across. Will you
still use the wire when this becomes a highway bridge? Probably not –
but don't sink enormous pilings to string up a wire just because it'll
probably need to be replaced in the future. Today, just get it across as
quickly and cheaply as possible – BUT, make sure the structure is sound &
safe to use. (i.e. use appropriate architecture that will be easy to modify
IF needed.)
8. Story: I want to get there faster and with less effort
Design a pulley system
Quality - Can it still hold the weight? Do the pulleys turn freely?
Negotiable quality – is there a secondary safety line?
Should the rider have a helmet?
9. Story: More stable & user friendly
Holds more weight
Most people can get across
Quality: strong lashings. (NOT easily removed later when if
you want to upgrade the bridge!)
10. Story: More durable – more traffic
Holds more weight
Average vehicles can get across
Quality: Solid architecture to hold a car, but not meant to hold two cars or
support high speed traffic.
>Rope bridge is a sunk cost.
>How much will it cost to
refactor the rope bridge?
>Is it worth it?
11. Story: More scalable – able to support a tank …
Holds more weight
Any vehicle can get across, many at once
Quality: This is the mature product that meets the vision. ..until ……
12. Story: Support ancillary value propositions
Quality: Is the existing structure capable of supporting additional functions?
Or is it a significant change that requires cost justification?
13. Business Drivers
Categories
Workflow
Efficiency
Sell/Implement
Sooner/ Faster
Basic/Core
Sell More
Exciters
Reuse Data
Sustained
Growth &
Reduce Cost
Nonfunctional
Record Quality
Process Faster
System Stability
& Security
System
Scalability
SuperEpics
Integrate
other
tools
Less reliance
on experts
Import
Export
QA new
records
Fix existing
records
Macros
and
templates
Batch
operations
Security
Improve
Performance
Measure
Performance
14. INVEST
Independent
Negotiable
Valuable
Estimable
Small
Testable
A few good practices:
•INVEST
•Keep stories small , do the simplest thing possible
•Keep stories singular - no 'if/else' or 'what if' conditions (Use cases –vs- user stories.) "I want to borrow a book." .. Assume the book is available.
have $600 in fines, …
Refactoring: In order to add these requirements later, we'll have to create stories & develop them – LATER. Will that mean rework? Probab
that's OK. Costs less to rework later than to develop functionality that won't be used or will delay release. When you do refactor: 1) Do it r
requirements in front of you. 2) Assess the cost of adding the requirement – do you really want it?
15. Early stories – focus on delivering value – get
the product right first & focus on the inner
workings after getting some user feedback.
“Go ugly, early.”
16. Exercise – write user stories for : creating a vending machine for drinks
Start with the basic story:
As a thirsty person, I want to buy a drink from your vending machine
What would the acceptance be? Remember – thin slices and do the simplest thing.:Machine will take my money
Machine will have a drink selection mechanism (eg select product by position on shelf, or by drink name, etc)
Machine will deliver drink
Negotiable criteria: (Maybe these are specified or maybe they are not required to address yet.)
Will give me change back
Won't take money if sold out
Won't let me get two drinks, ensures I paid first, ...
Hinweis der Redaktion
In this session we’ll talk mainly about user stories and not the overall methodology. Some of that will creep in along the way, but we won’t focus on it.All you really need to know about agile for today is: Communicate more, Cut out waste by questioning the process, and work in smaller increments.
what is a user story: a high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.Typical formatsAs a, I want to becauseAs a temporary library employee, I want to check in these books, so they can be reshelved.Given, when, then – enables more contexts (givens) & outcomes (thens.)Given that I am new here, when a patron returns a book, then enable me to check it in and tell me where it goes.Remember Personas – think about the motivation of the subject of the story. E.g. "As a library patron, I want to log in because ….. why?" A user doesn't want to log in ever. The story may be "As the system owner, I want users to log in so we can ensure proper authorization / use of our data/ system /// .. " Or what else? WHY do we want people to log in? be clear about it.
How user stories are different from requirements - The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. Focus on user needs. Avoid details of specific technology, data base layout, and algorithms.How user stories are different from Use Cases – What the user wants to do versus specific ways in which the user may do it. ** User stories should typically address only ONE, happy-path scenario for how the system will be used. ***Details usually found in a use case should not be part of the user story. User stories should be one sentence. (Use cases or other dialog about specific use/intention comes later, during development – as a conversation.)What is acceptance criteria? - define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. Essentially – what grade/level of quality is acceptable for the story? (e.g. is a confirmation necessary? Is data validated before saving? Don't just state the story in reverse. "As a patron, I want to find a book in your library." Acceptance: (perhaps) Tell user whether or not we own the book. Tell user whether the book is available. Tell user shelving location. Tell user about other formats.) (e.g. not “Book is found by patron.”)
How user stories are different from requirements - The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. Focus on user needs. Avoid details of specific technology, data base layout, and algorithms.How user stories are different from Use Cases – What the user wants to do versus specific ways in which the user may do it. ** User stories should typically address only ONE, happy-path scenario for how the system will be used. ***Details usually found in a use case should not be part of the user story. User stories should be one sentence. (Use cases or other dialog about specific use/intention comes later, during development – as a conversation.)What is acceptance criteria? - define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. Essentially – what grade/level of quality is acceptable for the story? (e.g. is a confirmation necessary? Is data validated before saving? Don't just state the story in reverse. "As a patron, I want to find a book in your library." Acceptance: (perhaps) Tell user whether or not we own the book. Tell user whether the book is available. Tell user shelving location. Tell user about other formats.) (e.g. not “Book is found by patron.”)
The best way to build in flexibility and quality is to remain SIMPLE as long as possible.You *might* assume that the bridge will need to be bigger/ heartier in time .. but the requirement TODAY is to get one person across. Will you still use the wire when this becomes a highway bridge? Probably not – but don't sink enormous pilings to string up a wire just because it'll probably need to be replaced in the future. Today, just get it across as quickly and cheaply as possible – BUT, make sure the structure is sound & safe to use. (i.e. use appropriate architecture that will be easy to modify IF needed.)
The best way to build in flexibility and quality is to remain SIMPLE as long as possible.You *might* assume that the bridge will need to be bigger/ heartier in time .. but the requirement TODAY is to get one person across. Will you still use the wire when this becomes a highway bridge? Probably not – but don't sink enormous pilings to string up a wire just because it'll probably need to be replaced in the future. Today, just get it across as quickly and cheaply as possible – BUT, make sure the structure is sound & safe to use. (i.e. use appropriate architecture that will be easy to modify IF needed.)
How to handle iteration zero & infrastructure stories Consider the *other* personas involved in the system:1. As an architect, I want to reduce the time we currently spent on design reviews - so we can get them done earlier in the process.2. As a product owner, I want to use automated tests to ensure quality.3. As a developer, I want to version control my code because I expect to make frequent, incremental changes.
A few good practices:INVESTKeep stories small , do the simplest thing possibleKeep stories singular - no 'if/else' or 'what if' conditions (Use cases –vs- user stories.) "I want to borrow a book." .. Assume the book is available. Assume I don't have $600 in fines, …Refactoring: In order to add these requirements later, we'll have to create stories & develop them – LATER. Will that mean rework? Probably. Accept it – that's OK. Costs less to rework later than to develop functionality that won't be used or will delay release. When you do refactor: 1) Do it right for the requirements in front of you. 2) Assess the cost of adding the requirement – do you really want it?
Early stories – focus on delivering value – get the product right first & focus on the inner workings after getting some user feedback. “Go ugly, early.”