What are stories

Post on 08-May-2015

339 views 0 download

description

This presentation describes what a User Story is and what they look like. It differentiates between user stories and technical tasks helping people learn how to write better stories minus the "how" they are implemented. It includes several exercises.

Transcript of What are stories

Your Bard:Paul Boos

The basics of story writing

It’s a tale of 3 purposes…

Requirement

Test Cases

WBS

I’ll grant you three C’sCardConversationConfirmation

A User Story can be managed on a Card

3 x 5 4 x 6

A Card is a

P RO M I SEto have a

Conversation

With whomdo we

converse?

the Product OwnerBehold!

(representing the business)

A Storyhas a way to

Confirmit was

fulfilled

& “Analyzed”just-in-time

A Story isBroken Down

What doesa Story

looklike?

WHO + WHAT + WHY

Elemental Form:

Doctor + Get patient’s vitals & notes + View health changes

A more powerful potion:

Role|Persona + Function + Value

Doctor + Retrieve patient’s vitals & notes + View patient health changes:

better, worse, same?

Advanced Story Wizardry

As a ____, I want to ____,So I can _____.

Let’s see an example…

As a Doctor, I want to retrieve my patient’s vitals & notes,So I can assess if her/his health is improving, degrading, or stabilizing.

As a Doctor, I want to retrieve my patient’s vitals & notes,So I can assess if her/his health is improving, degrading, or stabilizing.

NOTE: biz function, not a UI element

How can we

AcceptanceCriteria?

foreshadow

Acceptance Criteria• Provide the details on what the story needs to do

and is understandable by everyone -- clarity.• Can be used as the basis for coding business

rules.• Are the conditions to fulfill that can often become

(automated) tests.• Are unique to each story.

• They are how to confirm that the story is completed to satisfaction. 19

20

Creating Acceptance Criteria

Acceptance Criteria:– Back of card– Define test scenarios – Used for Product Owner confirmation– Clarified through Q&A– Often negotiated

Given an operating sensor,When the temperature ≥ 300°F,Then display “High Temp” warning light.

Acceptance Criteria

User StoryAs an operator, I want a visual alert on the operator display when the coolant temperature is too high, so that I can avoid overheating the engine..

Elemental Form:

Bullet points of cases

• Show heart rate, temperature, white blood cell count, and % oxygen in blood

• Observation notes in chronological order

Patient Summary

A more powerful potion:

Bullet points with specifics

• Show heart rate in bpm, temperature in degrees Farenheit, white blood cell count (integer #), and % oxygen in blood to tenths of a percent

• Observation notes in chronological order with date/time nurse’s last name (“nothing siginificant” can be observed, but no blanks should be shown)

Patient Summary

Advanced Criteria Wizardry

Scenario: ________

Given ____, When ____,Then _____.

Let’s see an example…

Scenario: Imacik Pashunt Patient Summary

Given Doctor Will Heal has Imacik Pashunt assigned to him, When the Imacik Pashunt is entered to retrieve the patient summary,Then the Imacik Pashunt summary is shown with the following data:Nurse Notes shown

7 Aug @ 1815, Helpa, Patient complained of thirst, given water

7 Aug @ 1005, Helpa, Patient sleeping, but restless8 Aug @ 0210, Aiden, Nothing significant noted

AND Last Vitals shown7 Aug @ 1800, Helpa: HR: 110 bpm T: 98.7°F WBC: 5 O2:

33.2%

Scenario: Imacik Pashunt Patient Summary

Given Doctor Will Heal has Imacik Pashunt assigned to him, When the Imacik Pashunt is entered to retrieve the patient summary,Then the Imacik Pashunt summary is shown with the following data:Nurse Notes shown

7 Aug @ 1815, Helpa, Patient complained of thirst, given water &

7 Aug @ 1005, Helpa, Patient sleeping, but restless8 Aug @ 0210, Aiden, Nothing significant noted

AND Last Vitals shown7 Aug @ 1800, Helpa: HR: 110 bpm T: 98.7°F WBC: 5 O2:

33.2%

NOTE: biz action(s), not a UI element(s)

Cool Reason to do Advanced Wizardry:

We can automate our requirements as tests!

Using tools like – CucumberLettuce

JBehaveFitnessSpock

So how far should you take a Story…

…on this Magical Journey?

What is the best path?

It Depends

Confirmation

Automate Tests

Used to

Simple Story

Consider need:

repeatabilitycomplication

sizing

Some stories seem too large…

They’re

EPIC

We needto shrink

them

A Good Story adheres to the…

…principles of INVEST

ndependent

egotiable

aluable

stimatable

mall

estable

IN

V

E

S

T

Independentminimize dependencies (preferably to zero)

Negotiableability for Product Owners and Delivery members to make trade-offs

Valuablefulfills customer or end user needs

Estimableunderstood well enough to be estimated

Smallcomfortably short cycle-time

Testableability to be verified that it works

How far out do we plan these story details

Planning Horizons (your Kanban view)

Product Roadmap

Start of Elaboration

End of Elaboration

DailyWork

Epics

EpicsFeatures

Stories

Tasks

Acceptance Criteria are fleshed out here

So how do we evolve Stories?

Do we use lycanthropy?

Splitting Grooming

Conversation

Acceptance Criteria

yields

As a Doctor, I want to retrieve my patient’s vitals & notes,So I can assess if her/his health is improving, degrading, or stabilizing.

As a Doctor, I want to retrieve my patient’s notes,So I can assess if her/his health is displaying any evidence of health change.

As a Doctor, I want to retrieve my patient’s vitals,So I can assess if these give evidence for improvement, degradation, or stabilization.

Confirmation

Acceptance Criteriayields

Scenario: Imacik Pashunt Patient Summary

Given Doctor Will Heal has Imacik Pashunt assigned to him, When the Imacik Pashunt is entered to retrieve the patient summary,Then the Imacik Pashunt nurse summary is shown with the following data:Nurse Notes shown

7 Aug @ 1815, Helpa, Patient complained of thirst, given water &

7 Aug @ 1005, Helpa, Patient sleeping, but restless8 Aug @ 0210, Aiden, Nothing significant noted

There’s a spell for that…

IKIWISI

So the changes are continually

Story ElaborationAd-hoc when pulled for work

From feedback during developmentand

refined…

Let’s Practice

Back Story

We’re developing Release 2 of an application to support the potion ingredient inventory at Hogwarts College of Wizardry.

Exercise No.1Divide into 2 teams.The application needs to allow teachers and students the ability to find what potions or brews an ingredient may be used within and display these alphabetically. Potions or brews used in dark magic need to be restricted to only teachers. Wizards are impatient, better show the results in 2 seconds or less.

Elect a product owner and work with her/him to create a set of user stories; we’re looking for a minimum of who+what+why for each story.

Exercise No.1 DebriefHow many stories did you get out of that short description?

Let’s read a few.

Take 2 individual stories from your last exercise.Write these onto a a couple of flip charts.Teams swap flipcharts.For 3 min on each flip chart, write questions onto stickies about how you to confirm that the story is done.

59

Exercise No.2, Part 1

Swap the flipcharts back. Now have the original team take 5 minutes to write as many acceptance criteria in bullet format as possible for that story. Replace the stickies as the Q is answered.

60

Exercise No.2, Part 2

Exercise No.1 DebriefLet’s look at an example of your acceptance criteria.

What roles play into creating acceptance? Why?

Exercise No.3Take the 2 stories from the ones you generated; take 5 min for them and apply the INVEST criteria.• How you know it is Independent or if it isn’t, what dependencies

does it have to other potential stories?• What parts are Negotiable about it or if it isn’t, what makes the

constraints rigid; could we make improvements to improve this?• What tells you it is Valuable to the user, or if it isn’t how could it be

given value? • Could you Estimate its complexity, or if you cannot then what

would you want to know to get more understanding?• What gives you confidence it is Small; and able to be completed it

in an iteration you might typically have, or if not, what would give you more confidence?

• And what makes it Testable, or if not, how could you improve that?Record this information onto a flip chart to share

Exercise No.3 DebriefFor the stories you generated, what are your comments on size? Small? Large?

What brought you to that conclusion?

How do you think size effects cycle-time and throughput?

Exercise No.4Take one of the requirements provided.

At your table, turn this into a story with acceptance criteria.

Once you have done so, apply the INVEST criteria.

Exercise No.4 DebriefLet’s share our stories…

Could we identify a role or persona? What about the value statement?

How well did what we have map to our acceptance criteria?

How did we do in making the stories small enough?

And the team lived…

…withgreater knowledge

ofstory-writing.

Yet…

You have now finished basicstory writing

The Sleeper Has Awaken!