User Stories AppliedUser Stories AppliedFor Agile Software For Agile Software

DevelopmentDevelopmentby Mike Cohnby Mike Cohn

Mike KaiserMike Kaiser

Mike KaiserMike Kaiser

Over 5 years doing software in the Over 5 years doing software in the insurance industry (development, insurance industry (development, testing, business analysis, solution testing, business analysis, solution analysis)analysis)

Certified Product OwnerCertified Product Owner Currently on second multi-million Currently on second multi-million

dollar dollar agileagile initiative at Nationwide initiative at Nationwide

ApproachApproach

I have some experience, but this isn’t I have some experience, but this isn’t my book we are talking aboutmy book we are talking about

If I don’t know the answer, I will do If I don’t know the answer, I will do my best to say just that. Perhaps my best to say just that. Perhaps these are opportunities where we these are opportunities where we can learn from can learn from youyou

Agile is not prescriptive. Your project Agile is not prescriptive. Your project is unique, you are uniqueis unique, you are unique

AgendaAgenda

1.1. Overview / Why Overview / Why ChangeChange

2.2. Writing Stories / Writing Stories / INVESTINVEST

3.3. User Role User Role ModelingModeling

4.4. Gathering StoriesGathering Stories

5.5. User Proxies User Proxies

6.6. Estimating User Estimating User StoriesStories

7.7. Why User StoriesWhy User Stories

8.8. Additional TopicsAdditional Topics

Our “stories” interjected throughout…

I would rather not cover all of this if we get a lot of value out of what we do cover

IntroductionIntroduction

Software requirements is a Software requirements is a communication problemcommunication problem

This is normally between This is normally between customers (incl. customers (incl. users/analysts/users/analysts/domain experts), domain experts), and a technical and a technical team.team.

Need To Work TogetherNeed To Work Together

When business dominatesWhen business dominates– mandates functionality/dates with little mandates functionality/dates with little

concern that developers can meet both concern that developers can meet both or if it is understood what is neededor if it is understood what is needed

When developers dominateWhen developers dominate– technical jargon replaces the language technical jargon replaces the language

of the business and developers lose the of the business and developers lose the opportunity to learn by listeningopportunity to learn by listening

How Predictable?How Predictable?

We cannot perfectly predict software We cannot perfectly predict software developmentdevelopment– Users see early versions of software, they Users see early versions of software, they

come up with new ideas and opinions changecome up with new ideas and opinions change– Because of the intangibility of software, most Because of the intangibility of software, most

developers have a difficult time estimating how developers have a difficult time estimating how long things will takelong things will take

– As such, we cannot lay out a perfect PERT As such, we cannot lay out a perfect PERT chart showing all that must be done on a chart showing all that must be done on a projectproject

What is a User Story?What is a User Story?

ExampleExample

As a customer service As a customer service representative, I can search for a representative, I can search for a customer so that I can view their customer so that I can view their account details.account details.– When searching by a valid account When searching by a valid account

number, the account is shownnumber, the account is shown– When searching by a valid name and When searching by a valid name and

SSN, the account is shownSSN, the account is shown– If no results are found, show appropriate If no results are found, show appropriate

messagemessage– Acceptance tests?Acceptance tests?

Some GuidelinesSome Guidelines

Generally smaller scope is betterGenerally smaller scope is better– and must be small enough to be and must be small enough to be

completed by one pair in an iterationcompleted by one pair in an iteration Generally the fewer the written Generally the fewer the written

details, the betterdetails, the better Anyone can write a story Anyone can write a story

– why limit who can have a good idea?why limit who can have a good idea?– (does not mean it will be developed nor (does not mean it will be developed nor

developed with those details)developed with those details)

INVESTINVEST IndependentIndependent NegotiableNegotiable Valuable (to users/customers)Valuable (to users/customers) EstimatableEstimatable SmallSmall TestableTestable Our Our

ExperiencesExperiences

From Bill Wake, From Bill Wake, Extreme Programming Explored Extreme Programming Explored and Refactoring Workbookand Refactoring Workbook

Story ResponsibilitiesStory Responsibilities

DeveloperDeveloper– To help customers write stories that are To help customers write stories that are

promises to converse rather than detailed promises to converse rather than detailed specs and that are INVESTspecs and that are INVEST

– If tempted to ask for a story about the use of a If tempted to ask for a story about the use of a technology, instead describe the need in terms technology, instead describe the need in terms of its value to users/customerof its value to users/customer

CustomerCustomer– Write promises to converse rather than Write promises to converse rather than

detailed specs and INVESTdetailed specs and INVEST

User Role ModelingUser Role Modeling

Why User Role Modeling?Why User Role Modeling?

Many projects just Many projects just do requirements do requirements from the from the perspective of perspective of “user”“user”

This simplification This simplification can be a fallacy can be a fallacy that leads the that leads the team to miss team to miss storiesstories

User Role Modeling StepsUser Role Modeling Steps Brainstorm an initial set of user rolesBrainstorm an initial set of user roles

– Generally don’t need system rolesGenerally don’t need system roles– Want to focus on the main user basesWant to focus on the main user bases

Organize the initial setOrganize the initial set Consolidate rolesConsolidate roles Refine the rolesRefine the roles

– Frequency of their useFrequency of their use– Level of expertise with the domainLevel of expertise with the domain– General level of proficiency with computersGeneral level of proficiency with computers– Level of proficiency with software under dev.Level of proficiency with software under dev.– General goal for using software (convenience, rich General goal for using software (convenience, rich

experience)experience)

How long we spent. What we found.How long we spent. What we found.

Additional TechniquesAdditional Techniques

PersonasPersonas Extreme CharactersExtreme Characters

– For a PDA:For a PDA:Drug dealer Drug dealer PopePopea 22 year old woman a 22 year old woman

who is juggling who is juggling multiple boyfriendsmultiple boyfriends

User Role ResponsibilitiesUser Role Responsibilities

DeveloperDeveloper– Participate in identification processParticipate in identification process– Understand each user roleUnderstand each user role– While developing, consider how different While developing, consider how different

roles prefer software to behaveroles prefer software to behave CustomerCustomer

– Looking broadly in identificationLooking broadly in identification– Ensure software focuses appropriately Ensure software focuses appropriately

on the different roles/personason the different roles/personas– When writing stories ensure they are for When writing stories ensure they are for

at least one role/personaat least one role/persona

Gathering StoriesGathering Stories

Is It Is It ElicitationElicitation and and CaptureCapture Time? Time?

Terms like these imply requirements Terms like these imply requirements are “out there”. We just need them are “out there”. We just need them explained to us so we can lock them explained to us so we can lock them in a cage. in a cage.

Requirements not out in space Requirements not out in space waiting to be captured. Not a case of waiting to be captured. Not a case of users already knowing requirements users already knowing requirements and just needing to elicit them.and just needing to elicit them.

What’s a better metaphor???What’s a better metaphor???

TrawlingTrawling

Mental image that req. are captured in a Mental image that req. are captured in a fishing netfishing net

1.1. Different-sized nets can be used to Different-sized nets can be used to capture different-sized req. (can do capture different-sized req. (can do multiple passes)multiple passes)• ““size” can be biz value, complexity, etc.size” can be biz value, complexity, etc.

2.2. Requirements, like fish, can grow in Requirements, like fish, can grow in importance or shrink and die.importance or shrink and die.

3.3. You will not catch it all the first time and You will not catch it all the first time and you will catch some flotsamyou will catch some flotsam

4.4. Skilled practitioners will know where to Skilled practitioners will know where to look for storieslook for stories

Story-Writing WorkshopsStory-Writing Workshops

Includes developers, users, product Includes developers, users, product owner, and othersowner, and others

Low, low, fidelity prototype (made in Low, low, fidelity prototype (made in the meeting, destroyed soon after)the meeting, destroyed soon after)– Start with a role/persona, then iterate Start with a role/persona, then iterate

through each of themthrough each of them– Brainstorm “components” (could be a Brainstorm “components” (could be a

page, or section of a page … doesn’t page, or section of a page … doesn’t matter)matter)

Story-Writing Workshop Pt2Story-Writing Workshop Pt2

Go through each “component” and Go through each “component” and brainstorm brainstorm – There is no lengthy debate on cards and There is no lengthy debate on cards and

limited negative feedback. Quantity limited negative feedback. Quantity over quality is the goal hereover quality is the goal here

– Have a visible parking lotHave a visible parking lot– Want high level discussions. Again, goal Want high level discussions. Again, goal

is for as many stories as possible in a is for as many stories as possible in a short timeshort time

Nonfunctional RequirementsNonfunctional Requirements

Many can be expressed as Many can be expressed as “constraint stories”. Automated “constraint stories”. Automated tests can then be put in place and tests can then be put in place and run each dayrun each day

Others cannot, and may need to be Others cannot, and may need to be expressed in some other appropriate expressed in some other appropriate or traditional wayor traditional way

Estimating User StoriesEstimating User Stories

““When will you be done with these When will you be done with these features?” – Your Executivefeatures?” – Your Executive

Best approach for estimating stories Best approach for estimating stories would be one that:would be one that:– Allows us to change our mind when we Allows us to change our mind when we

have new information on a storyhave new information on a story– Works for both epics and small storiesWorks for both epics and small stories– Does not take a long timeDoes not take a long time– Is tolerant of imprecision in estimatesIs tolerant of imprecision in estimates– Can be used to plan releasesCan be used to plan releases

Story PointsStory Points

Ideal days – better than elapsed time Ideal days – better than elapsed time or nebulous unitsor nebulous units

Estimate as a team – the team needs Estimate as a team – the team needs to own the estimateto own the estimate

Delphi technique (on index cards) or Delphi technique (on index cards) or party poker cardsparty poker cards

TriangulationTriangulation Velocity and Central Limit TheoremVelocity and Central Limit Theorem

Estimation ResponsibilitiesEstimation Responsibilities

DeveloperDeveloper– Giving honest estimatesGiving honest estimates– Estimating as a teamEstimating as a team– Consistent. Example, all 2 point Consistent. Example, all 2 point

estimates are similarestimates are similar CustomerCustomer

– To participate in estimation meetings by To participate in estimation meetings by answering questions and clarifyinganswering questions and clarifying

– Not allowed to estimate stories yourselfNot allowed to estimate stories yourself

Measuring VelocityMeasuring Velocity

Fully “done, done” story points are Fully “done, done” story points are countedcounted

Partially completed stories do not count at Partially completed stories do not count at allall– Don’t imply precision by saying you completed Don’t imply precision by saying you completed

4.7 points out of 84.7 points out of 8– That last 10% can take 90% of the timeThat last 10% can take 90% of the time– The business value is not achieved until it is The business value is not achieved until it is

done, done (or do smaller stories)done, done (or do smaller stories) The actual velocity of the last two The actual velocity of the last two

iterations is the planned velocity of the iterations is the planned velocity of the nextnext

What Stories Are NotWhat Stories Are Not

Stories are not Use CasesStories are not Use Cases

Stories are smaller (<=10 points)Stories are smaller (<=10 points) UCs are long-living artifactsUCs are long-living artifacts It is hard to keep interface It is hard to keep interface

requirements out of a UC. Story requirements out of a UC. Story names are written from the names are written from the perspective of business value (the perspective of business value (the rest is a conversation)rest is a conversation)

Contract vs. conversationContract vs. conversation

Documents Handed-Off Are A Documents Handed-Off Are A Warning SignWarning Sign

Ping pong of a documentPing pong of a document Technical groups rewrite it (calling it Technical groups rewrite it (calling it

something new, like Functional something new, like Functional Specification) to hide same information Specification) to hide same information different perspectivedifferent perspective

Specs for complex projects are too big to Specs for complex projects are too big to read and hard to write with desired read and hard to write with desired precisionprecision

Blame Game (implied features or hidden Blame Game (implied features or hidden out-of-scope statements)out-of-scope statements)

With conversations, nothing is final. We With conversations, nothing is final. We can always talk againcan always talk again– Is this a good idea?Is this a good idea?

Why User Stories?Why User Stories?

Stories Emphasize Verbal Stories Emphasize Verbal CommunicationCommunication

Humans did not have written words Humans did not have written words for centuriesfor centuries

Assumption that if something is Assumption that if something is written down, there is no ambiguitywritten down, there is no ambiguity

Lunch Menu: “Entrée comes with Lunch Menu: “Entrée comes with choice of soup or salad and bread.”choice of soup or salad and bread.”– Soup or (Salad and Bread)Soup or (Salad and Bread)– (Soup or Salad) and Bread(Soup or Salad) and Bread

Perfect?Perfect?

Traditional requirements seek to be Traditional requirements seek to be “perfect”“perfect”

Can seem lofty and unattainableCan seem lofty and unattainable Even if you could get to perfectly Even if you could get to perfectly

explained written wordsexplained written words– Users refine their opinions as they learn Users refine their opinions as they learn

moremore– Problems of deferred defects and of Problems of deferred defects and of

verbal agreements undocumented when verbal agreements undocumented when analyst capacity is lowanalyst capacity is low

Stories are ComprehensibleStories are Comprehensible

Because stories are short, there is a Because stories are short, there is a better chance they will be readbetter chance they will be read

Because stories are written to show Because stories are written to show customer value, they are customer value, they are comprehensible to business and comprehensible to business and technical peopletechnical people

Stories Are The Right Size For Stories Are The Right Size For PlanningPlanning

It is very hard to prioritize sections of It is very hard to prioritize sections of a UCa UC

With stories it is much easier to With stories it is much easier to prioritize scopeprioritize scope

Stories Work For Iterative Stories Work For Iterative DevelopmentDevelopment

Do not need to write all stories Do not need to write all stories before beginning codingbefore beginning coding

Can write stories at whatever level of Can write stories at whatever level of detail is appropriate (epics, last detail is appropriate (epics, last responsible moment)responsible moment)

Can iterate on top of the stories from Can iterate on top of the stories from previous iterationsprevious iterations

Can we find all requirements and Can we find all requirements and then design it in a top-down then design it in a top-down

manner? manner?

– Customers do not know exactly what they wantCustomers do not know exactly what they want– Even if developers know all requirements, Even if developers know all requirements,

many details they need only become clear as many details they need only become clear as the developthe develop

– Even if all details could be known up front, Even if all details could be known up front, humans are incapable of comprehending that humans are incapable of comprehending that many detailsmany details

– Even if we could understand the details, Even if we could understand the details, product and project changes occur.product and project changes occur.

– People make mistakes.People make mistakes.

Stories Support Opportunistic Stories Support Opportunistic DevelopmentDevelopment

Developers work best by freely moving Developers work best by freely moving between requirements, designing at levels between requirements, designing at levels of abstraction, and developmentof abstraction, and development

Allows developers see opportunities and Allows developers see opportunities and then adjust design and approachthen adjust design and approach

Stories allow:Stories allow:– Users not knowing everything up frontUsers not knowing everything up front– Developers not being able to fully comprehend Developers not being able to fully comprehend

a vast array of detailsa vast array of details– Embracing changeEmbracing change

Story SmellsStory Smells

Interdependent StoriesInterdependent Stories GoldplatingGoldplating Too Many Details (not INVEST)Too Many Details (not INVEST) Thinking Too Far Ahead (waterfall Thinking Too Far Ahead (waterfall

mindset)mindset)