user stories - agile requirements - iiba pittsburgh · pdf fileuser stories - agile...

Revision 1.0

User Stories -

Agile Requirements

• 634 Alpha Drive, Pittsburgh, PA 15238 • 888-762-3683 • www.pmcentersusa.coPM Centers USA, LLC, 2015 #888.762.3683 [email protected] www.PMCentersUSA.com

PM Centers USA, LLC, 2015 #888.762.3683 [email protected] www.PMCentersUSA.com

Purpose

Examine the nature of User Stories in the

context of Agile

Why does Agile need a different way to do

requirements?

How are User Stories created?

How are User Stories estimated and

prioritized?


1. Agile Requirements

2. What are User Stories?

3. The Three C’s

4. Story Sizing

5. Story Prioritization

6. Story Estimation

Topics



• Agile differs from Waterfall in several

ways:

Work is done in small pieces

Work is done only as needed, just in time

Documentation is minimized and done as

needed, if needed

Formality is reduced

• These differences impact the way

requirements are done on Agile projects


Requirements on an Agile Project

• Waterfall: requirements fully defined early in

project and change management used

• Agile: requirements evolve during the

project

‘Lightweight’ approach of writing brief descriptions

of what pieces and parts are needed by the product

List of these descriptions make up the Product

Backlog – and this is prioritized by the Product

Owner so highest value work is done first


Low Overhead Requirements

• The Product Backlog needs to be flexible – too

much work too early may be wasted

• Only the requirements needed for each sprint

are written and analyzed in detail

• Formal Requirements documentation does not

meet these needs

• What works are User Stories Simple to write

Easily changed as needed

A good fit for Agile!


A User Story is a requirement written from an end

user’s perspective. It usually follows this format:

As a <user>

I want to <do something>

so that <I get value>


It is NOT required to use this method for Agile or

even Scrum - User Stories simply help us think in

terms of our end users and provide a mechanism

that supports change


User Story Examples

• As a Facebook user, I want to update my profile so

that potential friends may find me.

• As a telecommuting employee, I’d like to be able to go

seamlessly from my cell phone to my office phone all

the while staying on the conference call so that I don’t

have to leave and then re-enter the conference.

• As a reports admin, I wish to add reports to a batch so

that I can save time every month.

• As a seller, I want to display an option for a buyer to

buy my product now so that I get paid right away.


User Stories are INVESTments

• Independent - any story could be the next one done

• Negotiable - a story is a promise for communication,

not a contract!

• Valuable - Don’t create technical stories. The story

must be valuable to your customer.

• Estimable - If you can’t estimate the story, it might be

too big.

• Small (or sized appropriately) - It should be small

enough to fit in the sprint, but not too small!

• Testable - If it is not verifiable, you can never tell if you

are done.


Example Story View

of Architecture Layers

For each story, the basic idea is to take vertical cuts in the

architecture rather than working horizontally

UI

Layer 1

Layer 2

DB

How we used

to break up

work

How Agile

says to do

stories

This creates many

dependencies and delays

business value


3. The Three C's

As ___________________

I want to _______________

So that ________________

Acceptance criteria:

•__________________

•__________________

•__________________

Card

Conversation

Confirmation


The Three C’s in Action

Card: As a user I want to be able to pay with a credit card

Conversation:

• TEAM: What credit cards are valid?

• PO: Diners, MasterCard, VISA & AMEX, but not Discover.

• TEAM: What should I do if the card check comes back

invalid (card reported lost or stolen, expired, doesn’t exist?

• PO: Give them a nice message explaining why it is not

valid, and let them try to enter another card.

Confirmation:

Test that Discover is not accepted

Test that expired cards are not accepted

Confirm that rejected cards are not accepted

(and so on…)


Story Writing

• Start with Requirements Elicitation in the same old

way – Business Analysts talking with the Customer

• Writing takes the form of User

Stories instead of formal

requirements documentation

• Ideally the business should

write the stories, but in practice

it is the BA’s led by the Product Owner

• Start with large Epic stories and decompose from

there


Story Writing Reality

• In a perfect world, all the stories would be

complete and prioritized before the first sprint

• In reality, the Product Owner does well to simply

keep ahead of the team, ensuring that enough

prioritized stories exist for each sprint

• Story Time: short meeting in middle of a Sprint

where team works with the Product Owner to

further decompose the highest priority User Stories

in the Product Backlog for upcoming Sprints

• Final refinement of the stories will be done as part

of each sprint’s planning


Other Considerations

Non-functional requirements: Performance, accuracy,

portability, reusability, maintainability, interoperability,

usability, security, etc.... “Product Backlog Items”

Area Sample Constraint

Maintainability

Automated unit tests must exist for all components

Automated unit tests must be run in their entirety at least once

every 24 hours

Interoperability

The system shall be written in Java.

All configuration data shall be stored in XML files.

Data shall be stored in MySQL.

CapacityThe database will be capable of storing 20 million members on

specified hardware while still meeting performance objectives


4. Story Sizing

• Stories need to be split into

digestible pieces, not too big

or too small

• Too-large stories are called

Epics, and they need to be split up

• This division is the same thing that needs to be

done outside Agile, so the same thinking can be

used – the work must be estimable


Some Ways to Split Stories

• Spike - Implementation

• Manual - Automated

• Buy - Build

• Batch - Online

• Single User - Multi

User

• API only - User

Interface

• CRUD

• Generic UI - Custom UIAdapted from Bill Wake www.xp123.com

• Static - Dynamic

• Ignore errors -

Handle errors

• Small vs. large scale

• Few vs. many

features

• Main vs. many

alternate flows

• Follow the workflow


Story Writing Planning

Product VisionYearly by the product owner

Product RoadmapBi-yearly by the product owner

Release PlanningQuarterly by the product owner and team

Iteration PlanningBi-weekly by the team

Daily PlanningDaily by the team and individuals

Image adapted from Mike Cohn,

www.mountaingoatsoftware.com

Initial Stories –

high level

Product Owner

refines Stories

Team refines

Stories for design

Grooming – 1 or

2 Sprints ahead



• The Product Owner is responsible for

prioritization

• The goal is to properly order the User Stories

so that the team can design each sprint

• Many factors drive prioritization:

Cost/Benefit analysis

Regulatory climate

Dependencies on/from other work


Determining Value

• Financial value - how much money will the

organization make or save by having the new

feature?

• Cost - cost of developing and perhaps supporting

the new feature

• Impact - amount and significance of learning

needed and new knowledge created by

developing the features

• Risk - amount of risk removed or incurred by

developing the new feature (includes difficulty of

work)


Prioritization Techniques

• High/Medium/Low as a first-pass

• “Buy a Feature” – timeboxing or budgeting

• MoSCoW

• Run/Grow/Transform


Pareto Analysis

• Also known as the 80 / 20 rule

• It states that, for many events, about 80% of the

effects come from 20% of the causes

• In Agile, this is often used to say that 80% of the

business value in a project comes from 20% of

the features

• Think about the principle of

“maximizing the work not done”


MMF and MVP

• Minimum Marketable Feature (MMF)

The smallest set of functionality that must be

realized in order for the customer to perceive

value - we use this concept in decomposing

stories

• Minimum Viable Product (MVP)

Just the minimal amount of features that let a

product be deployed


Kano Analysis

• Basic

• Performance

• Excitement

How do YOU measure

business value?


6. Story Estimation

www.agileevolution.com

• This is one of the hardest things to do properly in

project work, and Agile is no exception

• Most of the known estimation

techniques can be used with

Agile – there are some unique ones

• The stories must be sized properly

– if you are having problems

estimating, revisit the sizing

• Agile often does two estimates: Relative and Time


“Ready State” Product Backlog

• The product owner must always ensure that the product

backlog is in a ready-state by staying one step ahead of

the team

• Good estimation helps the team gauge how much

prioritized product backlog it can plan

• Not everything needs to be in the Ready State, but

everyone must be aware that the Stories not in there are

automatically prioritized downwards – they will not be

worked on this sprint!

Product Backlog Formula For Success:

Prioritization + Estimation + Small (at top) = “Ready State”


Relative Sizing vs. Time


Story Point Scale

{0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100}

small medium large

“easy”

“simple”

“known”

“difficult”

“complex”

“unknown”

A twist on this is affinity estimating (grouping stories).


More Considerations

• Definition of Done – when will this really

be complete? Who decides?

• Dependencies – what other work

depends on this?

• Complexity of work – how difficult is this

going to be to do?

• Existing framework – how hard will this

be to fit into what already exists?


Acceptance Criteria

Write acceptance criteria for

this story

___________________

___________________

___________________

___________________

___________________

___________________

___________________

As a job seeker,

I can post my

resume to the

website

Is there a difference in the estimate if acceptance criteria

is “support 1000 users” vs. “support 10 million users”?


Lifecycle Elements


Planning Poker

• Each estimator selects a set of cards

• Product owner or customer reads item to be estimated

• Item is discussed

• Each estimator privately selects a card representing his or

her estimate - card is not shown to other estimators

• Once each estimator has privately selected a card, all cards

are revealed at the same time

• If everyone played the same card, that’s the estimate

• If estimates are not the same, the group discusses the

estimate, focusing especially on any outlying values

• Repeat until estimates converge


Affinity Estimating

Another popular technique for relative estimates is based on

grouping as an approach to relative size

• Draw a range on a whiteboard from small to large (some

teams may choose to use story point labels from 1 to 40)

• Have team members silently place

stories in that range

• Allow people to move stories and

discuss briefly the reasons or ask

the PO for clarifications

• Look for natural size groupings of

stories and line them up

• Use a technique like planning poker to estimate the size of

each group instead of each individual item


Move Relative Estimates to Time Ones

• Projects need actual hour/day estimates, not

just relative ones!

• You must move your estimates to Time at

some point towards the end

• Use all the estimation techniques that work

anywhere, even outside Agile:

PERT or Three-point

Analogous estimating

Bottom-up estimating

Parametric estimating




3. The Three C’s

4. Story Sizing


6. Story Estimation

Review


Questions?

user stories - agile requirements - iiba pittsburgh · pdf fileuser stories - agile...

Documents