Aspe improved user_story_writing_techniques_ppt

Hands-On to Better Agile Requirements

Copyright 2012 Davisbase Consulting LLC. Distribution without express permission is forbidden

‣  Steve Davis, Davisbase Consulting ‣  11 years of Agile Experience

‣  5 years of Agile Training and Coaching Experience

‣  Work with teams from many industries

Introduction and Agenda

‣  Agenda ‣  What are User Stories?

‣  Why User Stories are used?

‣  The components of a good User Story

‣  Wrap up and Q&A


What Are User Stories? • User Story

• A very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it (Kent Beck)

• A promise for a discussion

• Usually stated in this format:

• As a <user role> I want <functionality> so that ��<desired benefit>


User Story Example

• Ron Jeffries defines user stories as consisting of three parts:

•  Card: The description of the need

•  Conversation: The conversation to follow that will cover the details

•  Confirmation: The tests that confirm the story’s satisfactory completion

As a patient, I want to access test results online, so that I

can get them at my convenience without calling

my doctor.

A small piece of business value that can be delivered��

in an iteration


• Agile requirements are written from a customer’s perspective, in plain language to minimize the barrier to customer involvement.

• Understanding the why can be as important as the what.

•  Information gems exist in knowing why our customers want what they ask for.

Agile Requirements �Focus on the Customer - User Stories�

As an instructor, I want to post my presentation

online so that I do not need to send it.

As a patient, I want to access test results

online, so that I can get them at my

convenience without calling my doctor.



online so that I do not need to send

it.

As a patient, I want to access test results

online, so that I can get them at my convenience without calling

my doctor.

What

Why

What

Why


Who

Who


Agile Requirements!

Ability for user to post a presentation online.

Traditional Requirements!(no “why” included)!


online so that I do not need to send

it.



Why User Stories?

• User Stories allow the team to capture the requested features without investing long periods of time defining details that may change during development.

• User stories are not meant to represent all of the information the team will need in order to develop the feature.

• They are simply placeholders for a future conversation where the team will define the deep detail necessary to develop the feature.


Continuous, Just In Time" Requirements Elaboration LEAN

PRINCIPLE

Parts Warehouse

X 1,000,000’s Shock Absorber

NEW Shock Absorber

X Just what we��need right now

Manufacturing

! Need new Shock

Absorber ?

Best Available Parts | No Risk of Waste Just In Time Inventory Meant:


User Stories Are Created at the"Beginning of an Agile Project

PRODUCT BACKLOG All User

Stories High-level requirements that will require additional detail for development User stories are estimated and prioritized to drive a release plan

Example: Product will need user stories A - O completed before releasing


ITERATION 5 ITERATION 4 ITERATION 3 ITERATION 2 ITERATION 1

Additional Detail Is Gathered," But Only Right Before Its Needed

PRODUCT BACKLOG

Story A Story B Story C

Story D Story E Story F Story G

Story H Story I

Story J Story K Story L

Story M Story N Story O

DETA

ILED R

EQS A, B, C

DETA

ILED R

EQS D, E, F, G

DETA

ILED R

EQS H, I

DETA

ILED R

EQS J, K, L

DETA

ILED R

EQS M, N, O

All User Stories

High-level requirements that will require additional detail for development User stories are estimated and prioritized to drive a release plan

Example: Product will need user stories A - O completed before releasing


What are the components��of a good user story?

•  INVEST acronym (Bill Wake)

•  Independent

•  Negotiable

•  Valuable

•  Estimable

•  Sized appropriately

•  Testable


User Stories �

Independent • Avoid dependencies with other stories whenever possible • Able to deliver as a product increment independently

INVEST�

As a patient, I want to access test results online, so that I can get

them at my convenience without calling my doctor.

As a patient, I want to login to my online account so that I can see my account information securely.


Negotiable • Stories are NOT a contract, break them up or add additional stories or information if necessary • Too much detail up front gives the impression that more discussion later is not necessary

As a patient, I want to access test results online, so that I can get

them at my convenience without calling my doctor.

As a patient, I want to access all past test results online,

so that I can get them at my convenience without calling my

doctor.

User Stories �INVEST�


User Stories �

Valuable • Should show value to:

•  Users •  Customers •  Stakeholders

• The agile team needs to maintain awareness of the subjective nature of value

INVEST�


User Stories �

Estimable

•  Enough detail to allow the team to estimate, at a high-level, the size of work to deliver story

•  Challenges estimating if...

•  The story is too big

•  There is insufficient information about the story

•  We lack of domain knowledge

INVEST�


User Stories �

Small • Small enough to be completed in a single iteration if possible • Small for the near future • Larger stories are okay further out (Epics)

INVEST�TIM

E�


Testable • Acceptance criteria stated in customer terms • Automate whenever possible • We want to know up front - what will it take for this to be accepted?

As a retiree, I want to see a summary of my investment accounts on one screen so that I can decide

where to focus my attention

• All investment accounts linked to the user profileAccount number, name, total value today displayed

User Stories �INVEST�


What to Watch Out For

•  Mike Cohn’s ‘Catalog of Story Smells’ •  Stories that are too small

•  Stories too big....too many being split later

•  Interdependent stories

•  Goldplating

•  Too much detail

•  Interface detail too soon

•  Thinking too far ahead

•  Lack of customer participation, writing and prioritizing


Epics

• Epics are User Stories that cannot be completed in a single iteration.

• The larger the User Story, the more unknowns exist and the more difficult it is for a team to accurately estimate.

• When epics are discovered, teams should work to break the User Story down to it’s smaller components which are then estimated.


Breaking Down Epics • Breaking down this epic...

As a student, I want to setup a product wish list so that my

family can buy me the things that I want.

• What are some of the ways we could break this down? Ability to add or remove items

Ability to change quantities

Ability to limit access to selected family members

Automatically remove items that have been purchased Ability to select occasion for gift

Others??


Other Kinds of User Stories • Systems Stories, Foundational Stories

As the store product inventory database, I

want hourly updates to ensure the online store

only displays products in inventory


Other Kinds of User Stories: Spikes

SPIKE: As a developer, I want to research product recommendation

algorithm’s so that we can intelligently recommend products

based on past purchases.

Spikes do not result in end-user demonstrable software, therefore every Spike should include acceptance criteria.


Other Kinds of User Stories • Constraints [Not truly a user story, should not be sized or

prioritized and should be documented outside of the product backlog]

As a customer, I want to the system to offer access from smart phones so that I don’t have to be at a computer to

order.

‣  Other types of constraints: performance, design, security, data handling, and platform.


Things to Remember...

• Write stories that are demonstrable at the end of the iteration

• Decompose larger stories to reduce risk

• Ensure that you have your product owner’s participation in writing and prioritizing your user stories

• Capture and document spikes, constraints, and system stories as you discover them


‣ Find experts that can point you in the right direction if you need help or guidance. Get training if you need it.

‣ Share what you learn about the approach with those teams around you.

‣  It takes time to get good at anything, Agile is no exception, but the rewards are well worth the effort.

Your Call To Action


Your Questions, My Answers Note: For those questions we do not have time to answer during the webinar,�� I will be providing a written response.

Aspe improved user_story_writing_techniques_ppt

Education

Transcript of Aspe improved user_story_writing_techniques_ppt