Difference between revisions of "User story"
(Therefore += Use the {{p|story splitter}} to make all {{p|user stories}} {{p|similar-sized items}}.) |
(→Sources: += Crisp » David Evans, Gojko Adzic » “As a, I want, So that” Considered Harmful) |
||
Line 172: | Line 172: | ||
|person=Savita Pahuja | |person=Savita Pahuja | ||
|title=Empirical Measurement of Cycle Time by Slicing Heuristic | |title=Empirical Measurement of Cycle Time by Slicing Heuristic | ||
}} | |||
{{WebSourceListItem | |||
|url=http://blog.crisp.se/2014/09/25/david-evans/as-a-i-want-so-that-considered-harmful | |||
|site=Crisp | |||
|person=David Evans, Gojko Adzic | |||
|title=“As a, I want, So that” Considered Harmful | |||
|about=using more effective ways to capture a story | |||
}} | }} |
Revision as of 15:47, 26 September 2014
…{{{context}}}
✣ ✣ ✣
{{{wish full}}}
- The cost of a story includes providing the capability and maintaining a healthy codebase for future work.
Therefore:
Use the story splitter to make all user stories similar-sized items.
✣ ✣ ✣
✣ ✣ ✣
Template
Legend
color | meaning |
---|---|
black | To be implemented in the current variant of the user story. |
red | Issues that must be researched and resolved before you can start with implementation. |
grey | Items that will not be implemented in the current variant of the user story (out of scope). |
Verb-sentences, please
When composing the title of a user story, use verb-sentences and active language. The verbs are the actions and activities users can do with your product. The nouns are the objects or parts that make up your product.
For example:
- To send a message.
- To delete a message.
- To close a partnership.
Context
Describe the context or situation in which this story shows its value at best.
Gist
Describe the essence, the ‘gist’ of the user story in its context.
Story Template
Slightly different from the “As a role I want to function so that I value.”
When I | situation | am in the city |
I want to | feature (verb sentence) | withdraw cash |
so that I | value, benefit | buy some ice cream and quench my thirst. |
Ready to Build
Describe the user’s adventure as a narrative, a story, until everyone can back brief the story crystal clear, lucid way. In short, make sure the user story is ready to build.
Issues
Issues that need to be resolved before the user story can be declared ready to build. Color open issues red. Color them black when resolved. For example:
- How many daily withdrawals are allowed?
- What is the maximum amount someone can withdraw and on what does it depend?
- Maximum daily withdrawal amount is minimum(account balance, credit limit, cash in ATM).
- Offer a loan when the withdrawal amount exceeds the account balance.
To do
Describe what needs to be done to get (a path through) the story ready to build, especially to split them into similar-sized items.
Seeing is believing
Tersely describe in steps how the path through the user story will be demonstrated. Pay special attention to edge cases. Steps in grey are excluded from the current revision of the story, and are used to illustrate what the complete story looks like.
Design
Describe the conceptual technical design of the story. Include any diagrams that clarify its implementation direction.
Acceptance
When appropriate, use specification by example and behavior-driven development in conduction with #Seeing is believing to obtain crystal clear acceptance criteria.
- See #Seeing is believing.
Scope
Explicitly specify what is in scope, and especially what is out of scope for this revision of the story.
- See #Seeing is believing.
In scope
- To be discussed.
Out scope
- To be discussed.
Decisions
List any decisions and their rationale.
- To be discussed.
Assumptions
List any assumptions on which the story, its design and decisions is based.
- To be discussed.
Sources
- Dan North & Associates » Dan North » What’s in a story?
- The Common Craft Blog » Lee LeFever » Why This Bathroom Sign Is a Great Explanation
- Mountain Goat Software » Mike Cohn » Advantages of User Stories for Requirements
- Boost » User stories: a beginner’s guide
- Stellman-Greene » Andrew Stellman » Requirements 101: User Stories vs. Use Cases
- Seth’s Blog » Seth Godin » The magic of a spec, about the level of spec required.
- HBR » Juan Pablo Vazquez Sampere » Generating Data on What Customers Really Want, about capturing a day in the life which in turn can be used to generate a whole bunch of user stories to fill a story map.
- Mountain Goat Software » Mike Cohn » 4 Reasons to Include Developers in Story Writing
- Alan Klement » Alan Klement » Focus On Causality, Skip Personas
- Alan Klement » Alan Klement » Replacing The User Story With The Job Story
- Alan Klement » Alan Klement » 5 Tips For Writing A Job Story
- Intercom » Paul Adams » The Dribbblisation Of Design
- InfoQ » Savita Pahuja » Empirical Measurement of Cycle Time by Slicing Heuristic
- Crisp » David Evans, Gojko Adzic » “As a, I want, So that” Considered Harmful, using more effective ways to capture a story.
- Faceless
- Martin Fowler
- Agile
- Lean
- Scrum
- Product
- Pearl
- Sparkle
- Dan North & Associates
- Dan North
- The Common Craft Blog
- Lee LeFever
- Mountain Goat Software
- Mike Cohn
- Boost
- Stellman-Greene
- Andrew Stellman
- Seth’s Blog
- Seth Godin
- HBR
- Juan Pablo Vazquez Sampere
- Alan Klement
- Intercom
- Paul Adams
- InfoQ
- Savita Pahuja
- Crisp
- David Evans
- Gojko Adzic