Story Time - Writing Effective User Stories

STORY TIMEThe Art of Writing Effective User Stories

Pravin Singh

ONCE UPON A TIME……there was a methodology.

It was called Waterfall.

THEN CAME AGILE

• Iterative, Incremental, based on Inspect & Adapt

• Very Lightweight – focused on working software, not on processes

• Requirements evolve over time

• So does Design

ARCHITECTURE DESIGN: WATERFALL

Platform

Feature 1

Feature 2

Feature 4

Feature 5

ARCHITECTURE DESIGN: AGILE

Feature 1

Feature 2

Platform

Feature 3

Platform

Feature 4

Platform

Agile does not mean ‘No Design’. It means ‘Just in Time – Just Enough’ design.

BUT WHY USER STORIES?

• Requirements are a communication problem.

• Those who want the software must communicate with those who build it.

• If business side dominates, functionality and dates are mandated with little regard for reality.

• If developers dominate, technical jargon replaces the language customers can understand.

• Many customers cannot articulate their needs until they see something running.

You built what I asked for, but it’s not

what I need.

OK, WHAT ARE THEY?

The 3 C’s

• Card – stories are traditionally written on notecards, and these cards can be annotated with extra details

• Conversation – details behind the story come out through conversations with the Product Owner

• Confirmation – acceptance tests confirm the story is finished and working as intended

ANATOMY OF A USER STORY

• “As a <role>, I want <feature> so that <benefit>.”

• “In order to <receive benefit> as a <role>, I want <feature>.”

• “As a <role>, I want <feature> so that <benefit>. I’ll know it’s done when <acceptance criteria>.”

• “As a <role>, I want <feature>.”

SOME EXAMPLES

• As a logged in user, I want to edit my profile so that my information is always up-to-date.

• As a traveler, I want to search for available flights between two cities so that I can plan my travel.

• As a user closing the session, I want to be reminded to save any unsaved documents so that I do not accidentally lose my work.

• As a business owner, I want a prettier error message so that users won’t send me as many angry emails when things go wrong.

WAIT, WHERE ARE THE DETAILS?

As a user having booked a hotel stay earlier, I want to cancel my reservation

• A premium member can cancel a reservation the same day without a fee

• Non-premium member is charged 10% for the same-day cancellation

• An email confirmation is sent

• The hotel is notified of the cancellation

These can be theacceptance criteriafor the story, or can

be child stories.

“INVEST” IN GOOD USER STORIES

• I – Independent (of all others, to the extent possible)*

• N – Negotiable (not a specific contract for features)

• V – Valuable (to the business, or to the end user)

• E – Estimable (to a good approximation)

• S – Small (enough to fit within an iteration)*

• T – Testable (in principle, even if there isn't a test for it yet)

* The more we break the stories down to make them smaller, the more difficult it becomes to keep them independent. It’s a tread-off we should be aware of, and balance independence with size.

…AND “SMART” TASKS

• S – Specific

• M – Measurable

• A – Achievable

• R – Relevant

• T – Time-boxed

HOW TO CREATE USER STORIES?

• Start with Users

• Create Personas with goals

• Derive Epics from Persona Goals

• Progressively decompose Epics into User Stories

• Make the Stories ‘Ready’ (clear, feasible, testable)

• Add Acceptance Criteria

…AND HOW TO SPLIT THEM?

The Wrong Patterns

• By Technology Layer

“Add item to shopping cart – DB Design”,

“Add item to shopping cart – Front End”

• By Activity

“Add item to shopping cart – Coding”,

“Add item to shopping cart – Testing”

• By Developer

“Add item to shopping cart – Andy”,

“Add item to shopping cart – Peter”

• By Sprint

“Add item to shopping cart – Sprint 1”,

“Add item to shopping cart – Sprint 2”

…AND HOW TO SPLIT THEM?

The Right Patterns

• By Workflow Steps

• By Simple/Complex

• By Business Rule Variations

As a traveler, I can search for flights between two destinations.

...specifying a max number of stops.

...including nearby airports.

...using flexible dates.

As a traveler, I can search for flights with flexible dates.

...as “± n days of x.”

...as “a weekend in December.”

As a marketing manager, I can publish a news story to the corporate website.

...I can publish a news story directly to the corporate website.

...I can publish a news story with editor review

...I can publish a news story with legal review.

…AND HOW TO SPLIT THEM?

The Right Patterns

• By Major Effort

• By Variations in Data

• By Data Entry Methods

As a blogger, I can create new blogs. ...in English.

...in Japanese.

...in Arabic.

As a traveler, I can search for flights between two destinations.

...using simple date input.

...with a fancy calendar UI.

As a user, I can pay for my flight with VISA, MasterCard, Diners Club, or American Express.

...I can pay with one credit card type (of VISA, MC, DC, AMEX).

...I can pay with all four credit card types (VISA, MC, DC, AMEX).

…AND HOW TO SPLIT THEM?

The Right Patterns

• By Performance

• By Operations (e.g. CRUD)

• By Breaking Out a Spike

As a user, I can manage my account. ...I can sign up for an account.

...I can edit my account settings.

...I can cancel my account.

As a user, I can pay by credit card. Investigate credit card processing.

Implement credit card processing (as one or more stories).

As a traveler, I can search for flights between two destinations.

...(slow - just get it done, show a “searching” animation).

...(in under 5 seconds).

“

”The Story Text we write on the card (or in Rally/Jira) is less important than the conversations we have.

LASTLY, DON’T FORGET THE PURPOSE