Difference between revisions of "User story"

From Pearl Language
Jump to navigation Jump to search
(→‎Template: += Issues)
(+= “What can I get by …?”)
 
(29 intermediate revisions by the same user not shown)
Line 3: Line 3:
|stage=Sparkle
|stage=Sparkle
|theme=Agile, Lean, Scrum, Product
|theme=Agile, Lean, Scrum, Product
|background={{quote|The cost of a story includes providing the capability and maintaining a healthy codebase for future work.|Martin Fowler}}
{{quote|If you can't write a user story in a tweet, it's too big.|@allenholub}}
Ask, “What can I get by …?” rather than “When is it going to be done?” The first opens up a world of options, the second will constrict you into a commitment (and death walk). —Troy Magennis.
|therefore full=Use the {{p|story splitter}} to make all {{p|user stories}} {{p|similar-sized items}}.
}}
}}
==Template==
===Story Template===
{|rules="rows" cellpadding="10"
|-
|{{SubtleCellLabel|In order to}}
|'''safely buy some ice cream and quench my thirst'''<br/>''value, benefit, outcome & behavioral '''change'''''
|-
|{{SubtleCellLabel|when}}
|'''I am in the city'''<br/>''situation, context''
|-
|{{SubtleCellLabel|as a}}
|'''relaxed, first time tourist here''',<br/>''(qualified) role''
|-
|{{SubtleCellLabel|I want to}}
|'''withdraw cash'''<br/>''feature as verb sentence; potential entry in user manual''
|-
|{{SubtleCellLabel|unlike}}
|'''carrying a thick wallet loaded with cash, prone to theft, making me worried'''.<br/>''contrast with current solution''
|}
Different from the “As a ''role'' I want to ''function'' so that I ''value''.”
 
==Use a formal specification language==
Leslie Lamport on Distributed Systems and Precise Thinking:
{{quote|The benefit of using [a formal specification language] is that it teaches you to think rigorously, to think precisely, and the important point is the precise thinking. So what you need to avoid at all costs is any language that's all syntax and no semantics.|Leslie Lamport}}
 
==Story==
===Legend===
===Legend===
{|
{|rules="rows" cellpadding="10"
|-
|-
!aling="left"|color
!align="left"|color
!meaning
!align="left"|meaning
|-
|-
!aling="left"|'''black'''
!align="left"|'''{{color|black|black}}'''
|To be implemented in the current variant of the {{p|user story}}.
|To be implemented in the current variant of the {{p|user story}}.
|-
|-
|'''red'''
!align="left"|'''{{color|red|red}}'''
|Issues that must be researched and resolved before you can start with implementation.
|Issues that must be researched and resolved before you can start with implementation.
|-
|-
|'''grey'''
!align="left"|'''{{color|grey|grey}}'''
|Items that will '''not''' be implemented in the current variant of the {{p|user story}} (out of scope).
|Items that will '''not''' be implemented in the current variant of the {{p|user story}} (out of scope).
|}
|}
===Verb sentences, please===
 
When composing the title of a {{p|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.
===Verb-sentences, please===
When composing the title of a {{p|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:
For example:
Line 27: Line 58:
*To '''delete''' a message.
*To '''delete''' a message.
*To '''close''' a partnership.
*To '''close''' a partnership.
*To '''view''' a product’s location. ''(relationship between product and location)''


===Story Template===
===Context===
Slightly different from the “As a ''role'' I want to ''function'' so that I ''value''.”
''Describe the context or situation in which this story shows its value at best.''
{|rules="rows"
 
|-
===Gist===
|When I
''Describe the essence, the ‘gist’ of the {{p|user story}} in its context.''
|''situation''
 
|am in the city
{{author|Gojko Adzic}} pro tip: “In order to…” should ideally be a behavioral '''change''', not just a behaviour, so it's observable and measurable.
|-
|I want to
|''feature'' (verb sentence)
|withdraw cash
|-
|so that I
|''value'', ''benefit''
|buy some ice cream and quench my thirst.
|}


===Ready to Build===
===Ready to Build===
Describe the user’s adventure as a narrative, a story, until everyone can {{p|back brief}} the story crystal clear, lucid way. In short, make sure the {{p|user story}} is {{p|ready to build}}.
''Describe the user’s '''adventure as a narrative''', a story, until everyone can {{p|back brief}} the story crystal clear, lucid way. In short, make sure the {{p|user story}} is {{p|ready to build}}.''


===Issues===
===Issues===
Line 53: Line 76:
*{{color|red|How many daily withdrawals are allowed?}}
*{{color|red|How many daily withdrawals are allowed?}}
*What is the maximum amount someone can withdraw and on what does it depend?
*What is the maximum amount someone can withdraw and on what does it depend?
**€500
**Maximum '''daily''' withdrawal amount is minimum(''account balance'', ''credit limit'', ''cash in ATM'').
*{{color|grey|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 {{p|ready to build}}, especially to split them into {{p|similar-sized items}}.'' Consider using {{p|gherkin}} as a formal language to do so. Remember, the goal of a {{p|story}} is to have a good conversation
 
===Seeing is believing===
''Tersely describe in steps how the path through the {{p|user story}} will be demonstrated. Pay special attention to edge cases. Steps in '''{{color|grey|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 {{p|specification by example}} and {{p|behavior-driven development}} in conduction with [[#Seeing is believing]] to obtain {{p|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====
*{{color|red|To be discussed}}.
====Out scope====
*{{color|red|To be discussed}}.
 
===Decisions===
''List any decisions and their rationale.''
*{{color|red|To be discussed}}.
 
===Assumptions===
''List any assumptions on which the story, its design and decisions is based.''
*{{color|red|To be discussed}}.
 
==Junk items==
Junk can be items that are added while in a hurry. The need to be rewritten as good stories later to get them {{p|ready to build}}, but were initially just tossed into the bin so to remember. Others are things like “Upgrade Linux server” that could be rewritten as a story, but there is little benefit to do that. Also, items like that tend to be well understood and are often short-lived.
 
A little bit of junk on your wishlist is totally fine, especially when it won’t be there long.
 
 
==User out of sight==
Sometimes, the functionality being described starts to get a little too distant from real users and writing user stories when real users are nowhere to be found feels artificial or even silly.
 
Borrowing from {{p|feature driven development}}, you can write these stories remote from real users in this format:
 
:''action'' '''the''' ''result'' ['''by'''|'''for'''|'''of'''|'''to'''] ''object''
 
For example:
*Estimate the closing price of stock
*Generate a unique identifier for a transaction
*Change the text displayed on a kiosk
*Merge the data for duplicate transactions
 
All verb-based sentences with at least one noun. Each noun represents an object in your system. Multiple nouns in a single sentence indicate a relationship between the objects.
 
This can be a particularly good syntax when developing something like an Application Programming Interface (API) and object-oriented systems. It works equally well on other types of back-end functionality.
 
==FDD==
Also, check out {{p|feature driven development}}. It also uses verb-sentences and is well suited for object oriented development. See e-mail on June 2, 2015, from Mike Cohn, titled “Not Everything Needs to Be a User Story: Using FDD Features”.


==Sources==
==Sources==
'''left overs''' need to extend WebSourceListItem to accommodate ‘epilog’ or ‘about’
 
*, about the level of spec required.
*http://martinfowler.com/bliki/ConversationalStories.html
*about capturing {{p|a day in the life}} which in turn can be used to generate a whole bunch of {{p|user stories}} to fill a {{p|story map}}.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
{{tag|story}}
{{WebSourceListItem
|url=http://www.betterprojects.net/2017/05/writing-better-user-stories.html
|site=Better Projects
|person=Craig Brown
|title=Writing Better User Stories
}}
{{WebSourceListItem
{{WebSourceListItem
|url=http://dannorth.net/whats-in-a-story/
|url=http://dannorth.net/whats-in-a-story/
Line 93: Line 193:
|person=Seth Godin
|person=Seth Godin
|title=The magic of a spec
|title=The magic of a spec
|about=about the level of spec required
}}
}}
{{WebSourceListItem
{{WebSourceListItem
Line 99: Line 200:
|person=Juan Pablo Vazquez Sampere
|person=Juan Pablo Vazquez Sampere
|title=Generating Data on What Customers Really Want
|title=Generating Data on What Customers Really Want
|about=about capturing {{p|a day in the life}} which in turn can be used to generate a whole bunch of {{p|user stories}} to fill a {{p|story map}}
}}
}}
{{WebSourceListItem
{{WebSourceListItem
Line 105: Line 207:
|person=Mike Cohn
|person=Mike Cohn
|title=4 Reasons to Include Developers in Story Writing
|title=4 Reasons to Include Developers in Story Writing
}}
{{WebSourceListItem
|url=http://alanklement.blogspot.nl/2013/09/replacing-user-story-with-job-story.html
|site=Alan Klement
|person=Alan Klement
|title=Focus On Causality, Skip Personas
}}
{{WebSourceListItem
|url=http://alanklement.blogspot.nl/2013/09/replacing-user-story-with-job-story.html
|site=Alan Klement
|person=Alan Klement
|title=Replacing The User Story With The Job Story
}}
{{WebSourceListItem
|url=http://alanklement.blogspot.nl/2013/09/5-tips-for-writing-job-story.html
|site=Alan Klement
|person=Alan Klement
|title=5 Tips For Writing A Job Story
}}
{{WebSourceListItem
|url=http://insideintercom.io/the-dribbblisation-of-design/
|site=Intercom
|person=Paul Adams
|title=The Dribbblisation Of Design
}}
{{WebSourceListItem
|url=http://www.infoq.com/news/2014/09/slicing-heuristic
|site=InfoQ
|person=Savita Pahuja
|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
}}
{{WebSourceListItem
|url=http://www.infoq.com/news/2014/10/ser-lamport-interview
|site=InfoQ
|person=Sergio De Simone
|title=Leslie Lamport on Distributed Systems and Precise Thinking
|about=using formal language for requirements and coding
}}
}}

Latest revision as of 05:22, 2 July 2019

…{{{context}}}

✣  ✣  ✣

{{{wish full}}}

The cost of a story includes providing the capability and maintaining a healthy codebase for future work.
—Martin Fowler
If you can't write a user story in a tweet, it's too big.
—@allenholub

Ask, “What can I get by …?” rather than “When is it going to be done?” The first opens up a world of options, the second will constrict you into a commitment (and death walk). —Troy Magennis.

Therefore:

Use the story splitter to make all user stories similar-sized items.

✣  ✣  ✣



✣  ✣  ✣

Story Template

In order to safely buy some ice cream and quench my thirst
value, benefit, outcome & behavioral change
when I am in the city
situation, context
as a relaxed, first time tourist here,
(qualified) role
I want to withdraw cash
feature as verb sentence; potential entry in user manual
unlike carrying a thick wallet loaded with cash, prone to theft, making me worried.
contrast with current solution

Different from the “As a role I want to function so that I value.”

Use a formal specification language

Leslie Lamport on Distributed Systems and Precise Thinking:

The benefit of using [a formal specification language] is that it teaches you to think rigorously, to think precisely, and the important point is the precise thinking. So what you need to avoid at all costs is any language that's all syntax and no semantics.
—Leslie Lamport

Story

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.
  • To view a product’s location. (relationship between product and location)

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.

Gojko Adzic pro tip: “In order to…” should ideally be a behavioral change, not just a behaviour, so it's observable and measurable.

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. Consider using gherkin as a formal language to do so. Remember, the goal of a story is to have a good conversation

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.

Scope

Explicitly specify what is in scope, and especially what is out of scope for this revision of the story.

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.

Junk items

Junk can be items that are added while in a hurry. The need to be rewritten as good stories later to get them ready to build, but were initially just tossed into the bin so to remember. Others are things like “Upgrade Linux server” that could be rewritten as a story, but there is little benefit to do that. Also, items like that tend to be well understood and are often short-lived.

A little bit of junk on your wishlist is totally fine, especially when it won’t be there long.


User out of sight

Sometimes, the functionality being described starts to get a little too distant from real users and writing user stories when real users are nowhere to be found feels artificial or even silly.

Borrowing from feature driven development, you can write these stories remote from real users in this format:

action the result [by|for|of|to] object

For example:

  • Estimate the closing price of stock
  • Generate a unique identifier for a transaction
  • Change the text displayed on a kiosk
  • Merge the data for duplicate transactions

All verb-based sentences with at least one noun. Each noun represents an object in your system. Multiple nouns in a single sentence indicate a relationship between the objects.

This can be a particularly good syntax when developing something like an Application Programming Interface (API) and object-oriented systems. It works equally well on other types of back-end functionality.

FDD

Also, check out feature driven development. It also uses verb-sentences and is well suited for object oriented development. See e-mail on June 2, 2015, from Mike Cohn, titled “Not Everything Needs to Be a User Story: Using FDD Features”.

Sources

Retrieved from "http://pearllanguage.org/index.php?title=User_story&oldid=3003"