1

UnderstandingUser Stories

Rachel Daviesrachel@agilexp.com

My Agile timeline

20032000

Programmer on XP team

Agile Coach

Author

2009

Boarddirector Conference

chair

2

A few companies ..

About you ..

Does your team buildsoftware from:

• requirements specs?

• from user stories?

• from something else?

3

Embrace Change!

• Agile projects focus on delivering value earlyand often

• Scope changes allowed throughout the project• Agile requires involvement of business

throughout the lifecycle to steer priorities andexplain their needs.

Agile Manifesto

• Shared values and principlesfor better ways to developsoftware (2001)

• www.agilemanifesto.org

4

Individuals and interactions

over processes and tools

Working software

over comprehensive documentation

5

Customer collaboration

over contract negotiation

Responding to change

over following a plan

6

Key Agile Principles

• The goal of Agile Development is to satisfy thecustomer ���through early and continuous delivery ���ofvaluable software

• Business people and developers must worktogether daily throughout the project

• Changing requirements are welcomed, evenlate in development

• Focus on flow of value to help prioritize and plan

Traditional Requirements

• Are conveyed indocuments

• Written in impersonallanguage

• Tangled together so it’shard to separate outand prioritize

7

What other ways can we use tounderstand what software to build?

Try User Stories

• User stories help us explore what the softwareneeds to do from a user perspective.

• Knowing who the user is and what problemsthey are trying to solve helps us develop bettersoftware.

8

Questions help find context

Ask questions to uncover the user stories..• Who will use it?• What problem are they trying to solve?• What’s their goal?• Why is this valuable to them?Understand this before diving into solution

details

?

“One thing the customer wants the system to do.Stories should be estimable at between one tofive ideal programming weeks. Stories should betestable.”“Stories need to be of a size that you can build afew of them in an iteration”“Stories don't have to represent business value tothe customer team, but they do have torepresent progress. Only the customer teamknows what it will consider progress, so theyhave to do the slicing” Kent Beck

Time-boxed by definition

9

Card: user goal written on an index cardConversation: team gets to ask questionsConfirmation: acceptance criteria

Ron Jeffries, Xprogramming.com

Three Cs to a user story

Team Planning with User Stories

~ 2000

10

As a .. I want .. template

(2001)

Story Example

Find a book by ISBN

As a book buyer,I want to be able to find a book by

entering the ISBN numberso that I can find a specific book quickly

11

Example story card

As an operations engineer,I want to be able to

reconfigure the timeout of aspecific service request

without needing to restartthe backend service process

fromKerry Jones, BBC

Notice they are not "As a system”!

Acceptance Criteria

Elaborate user stories with examples todefine acceptance criteria

Focus in on demonstrable aspects that wecan use to confirm story is complete

12

But ..

Are these user stories?

• “As a user, I want ..X so I can have X• “As a developer, I want ..• “As a system, I want ..

Do these help us understand• user context?• business value?

Or are they a waste of time?

13

Fred’s user story template

• Doesn’t even print to asingle sheet of A4!• Passed between BA,Dev, Tester withoutconversation• Same problems astraditional requirements

Remember this

14

Why User Stories Work

• User stories add conversations to thedevelopment cycle

• These conversations do not mean thatdocuments are abandoned

• But you try to write down less wherepossible because that reduces overhead ofmaintaining documents

Stories Change Shape

User stories evolve thru conversation

15

Pinning down can kill the idea

Iterate software based on feedback

Beware of Epics

Sometimes a story is too large to be implemented in a single iteration, wecall these Epics.

Such stories will need to be broken down for reliable estimates.

16

What about non-functionalrequirements?

Any Questions?

Contact info:Email: rachel@agilexp.comTwitter: rachelcdaviesBlog: http://agilecoach.typepad.com/