Post on 30-Oct-2014
description
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)