User StoriesAgile requirement gathering

By Shukla, Aditya PMP, PMI-ACP, CSM, CSPO, SPC, SCPM, SA

As a <user type>, I want to <function> so that <benefit>

Use

r Sto

ries E

xpla

ined

The tests that confirm the story's satisfactory completion

What is a user story?

The conversations that happen during backlog grooming

and iteration planning to solidify the details

The brief description of the need

A user story represents a small piece of business value that a team

can deliver in an iteration. While traditional requirements (like

use cases) try to be as detailed as possible, a user story is defined

incrementally, in three stages:

Use

r Sto

ries E

xpla

ined

SO……

User stories are not just small snippets of text. Each user story is

composed of three aspects:

Written description of the story, used for planning

and as a reminder

Conversations about the story that serve to flesh

out the details of the story

Tests that convey and document details that can

be used to determine when a story is complete

Use

r Sto

ries E

xpla

ined

Why use user stories?

Keep yourself expressing business value

Avoid introducing detail too early that would

prevent design options and inappropriately lock

developers into one solution

Avoid the appearance of false completeness and

clarity

Get to small enough chunks that invite negotiation

and movement in the backlog

Leave the technical functions to the architect,

developers, testers, and …

Use

r Sto

ries E

xpla

ined

As a <user type>, I want to <function> so that

<benefit>

Ex: As a consumer, I want shopping cart functionality

to easily purchase items online.

How to write user stories

Use

r Sto

ries E

xpla

ined

ID#

Name:

As a <user type>, I want to <function> so that

<benefit>

Description :……………………………………………………………..

Acceptance Criterion : ……………………………………………..

User story template

Without acceptance criterion story is incomplete and should be

not be accepted by team.

Use

r Sto

ries E

xpla

ined

Use

r Sto

ries E

xpla

ined

Well-formed stories will meet the criteria of

Bill Wake's INVEST acronym

I N V E S T

Use

r Sto

ries E

xpla

ined

Users or customers get some value from the story.

INVEST

We want to be able to develop in any sequence

Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.

Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.

Document acceptance criteria, or the definition of done for the story, which lead to test cases

The team must be able to use them for planning.

Use

r Sto

ries E

xpla

ined

Too formal or too much detail

Technical tasks masquerading as stories

Skipping the conversation

No acceptance criterion

AVOID

Use

r Sto

ries E

xpla

ined

Example

Too broad

A team member can view iteration status.

Too detailed

•A team member can view a table of stories with rank, name, size,

package, owner, and status.

•A team member can click a red button to expand the table to include

detail, which lists all the tasks, with rank, name, estimate, owner,

status.

Use

r Sto

ries E

xpla

ined

Example

Just right

As a team member I can view the iteration stories and their status so

that I know iteration progress.

Details:……

Acceptance

Criterion:

Use

r Sto

ries E

xpla

ined

Consumption / Usage

Final thoughts

Creation

Maintenance

User Stories Applied: For Agile Software Development by Mike Cohn

Not Use-Cases (more..)

Use

r Sto

ries E

xpla

ined