user stories cohn ndc2010

8/8/2019 User Stories Cohn NDC2010

1/16


2/16

Copyright Mountain Goat Software

Balance is critical

If either side dominates, the business loses

If the business side dominatesfunctionality and dates are mandated with littleregard for reality or whether the developersunderstand the requirements

If the developers dominate

technical jargon replaces the language

of the business and developers lose theopportunity to learn from listening


We need a way ofworking together sothat resource

allocation becomes ashared problem

Project fails whenthe problem ofresource allocationfalls too far to one

side

3

4


3/16


If developers are responsible

May trade quality for additional features

May only partially implement a feature May solely make decisions that should involve

the business side

If the business is responsible

Lengthy upfront requirements negotiation andsignoff

Features are progressively dropped as thedeadline nears


We cannot perfectly predict a softwareschedule

As users see the software, they come up withnew ideas

Too many intangibles

Developers have a notoriously hard timeestimating

If we cant perfectly predict a schedule, we

cant perfectly say what will be delivered

5

6


4/16


We make decisions basedon the information

we have

but do it often

Rather than making one all-encompassing set of decisions

we spreaddecision-making

across the project

Thisiswhereuser

storiescomein


Agenda

What stories areWriting user stories

Why user stories

7

8


5/16


Ron Jeffries three Cs

Card

Stories are traditionally written on note cards.

Cards may be annotated with estimates, notes, etc.

Conversation

Details behind the story come out during conversationswith product owner

Confirmation Acceptance tests confirm the story was coded correctly


Samples from a travel website

Asauser, Iwantto

reserveahotelroom.

Asauser,I wantto

cancelareservation.

As a vacation traveler,I want to see photos of

the hotels.

As a frequent flyer, Iwant to rebook a past tripso that I save time

booking trips I take often.

9

10


6/16


Where are the details?

As a user, I can cancel a reservation.

Does the user get a full or partial refund?

Is the refund to her credit card or is it site credit?

How far ahead must the reservation be cancelled?

Is that the same for all hotels?

For all site visitors? Can frequent travelers cancel later?

Is a confirmation provided to the user?

How?


Details as conditions of satisfaction

As a user, I cancancel a reservation. Verify that a premium member can

cancel the same day without a fee.Verify that a non-premium member ischarged 10% for a same-day cancellation.Verify that an email confirmation is sent.

Verify that the hotel is notified of anycancellation.

11

12


7/16


Details added in smaller sub-stories

As a user, I cancancel a reservation.

As a site visitor, I amemailed a confirmation ofany cancelledreservation.

As a non-premiummember, I can cancel upto 24 hours in advance.

As a premium sitemember, I can cancel a

reservation up to thelast minute.


Techniques can be combined

These approaches are not mutually exclusive

Write stories at an appropriate level

By the time its implemented, each story willhave conditions of satisfaction associatedwith it

13

14


8/16

2009 Mountain Goat Software Copyright Mountain Goat Software

The product backlog iceberg

Sprint

Release

FutureReleases

Priority


Stories, themes and epics

Epic

A large userstory

ThemeA collection of

related userstories

15

16


9/16


An example

As a VP Marketing, I want toselect the timeframe to use

when reviewing the performanceof past promotional campaigns,so that I can identify and repeatprofitable ones.

As a VP Marketing, I can selectwhich type of campaigns (directmail, TV, email, radio, etc.) toinclude when reviewing theperformance of historicalpromotional campaigns.

As a VP Marketing, I want toreview the performance ofhistorical promotionalcampaigns so that I canidentify and repeat profitableones.


As a VP Marketing, I want tosee information on directmailings when reviewinghistorical campaigns.

As a VP Marketing, I want tosee information on televisionads when reviewinghistorical campaigns.

As a VP Marketing, I want tosee information on email adswhen reviewing historical

campaigns.

17

18


10/16


AgendaWhat stories areWriting user stories

Why user stories


Use this template

As a , I want so that .

Logging in

See how many user stories you can write about

logging in.

Examples: As a registered user, I am required to log in so that I

can access the system.

As a forgetful user, I can request a passwordreminder so that I can log in if I forget mine

19

20


11/16


Includes whole team plus possibly someexternal stakeholders

Typically not done every sprint

Brainstorm to generate stories

Goal is to write as many stories as possible

Some will be implementation ready

Others will be epics

No prioritization at this point


As a frequentflyer, I want tobook a trip usingmiles.

As a frequentflyer, I want torebook a trip Itake often.

As a frequentflyer, I want torequest anupgrade.

As a frequentflyer, I want tosee if my upgradecleared.

Start with epics and iterate

As a frequentflyer, I want tosee check myaccount.

As a frequentflyer, I want tobook a trip.

As a frequentflyer, I wantto

Frequent Flyer

21

22


12/16


AgendaWhat stories areWriting user stories

Why user stories

2009 Mountain Goat Software Copyright Mountain Goat Software

So why user stories?

Shift focus from writing to talking

If requirementsare written down The user will getwhat she wantsthen

At best shell getwhat was writtenYoubuiltwhatI

askedfor,butits

notwhatIneed.

23

24


13/16


Words are imprecise

Entre comes withsoup or salad and bread.

(Soup or Salad) and Bread

(Soup) or (Salad and Bread)


Examples

The user can enter a name.It can be 127 characters.

The system shouldprominently display a

warning message wheneverthe user enters invalid data.

Must the user enter aname?

Can it be other than 127

chars?

What does shouldmean?

What does prominentlydisplay mean?

Is invalid data defined

elsewhere?

25

26


14/16


Additional reasons

Stories are understandable

Developers and customers understand themPeople are better able to remember events ifthey are organized into stories

Support and encourage iterativedevelopment

Can easily start with epics and disaggregatecloser to development time


Yet more reasons

Stories are the right size for planning

Stories support opportunistic development

We design solutions by movingopportunistically between top-down andbottom-up approaches

Stories support participatory design

27

28


15/16


What if we had stories instead?


Dont forget the purpose

The story text we write on

cards is less important than

the conversations we have.

29

30


16/16


Informationand

registrationat

www.programutvikling.no


Mike [email protected]

www.mountaingoatsoftware.com

twitter: mikewcohn(720) 8906110

31

32

user stories cohn ndc2010

Documents