User Stories Applied For Agile Software Development by Mike Cohn

1
User Stories AppliedFor Agile Software
Developmentby Mike Cohn

• Mike Kaiser

2
Mike Kaiser

• Over 5 years doing software in the insurance
  industry (development, testing, business
  analysis, solution analysis)
• Certified Product Owner
• Currently on second multi-million dollar agile
  initiative at Nationwide

3
Approach

• I have some experience, but this isnt my book we
  are talking about
• If I dont know the answer, I will do my best to
  say just that. Perhaps these are opportunities
  where we can learn from you
• Agile is not prescriptive. Your project is
  unique, you are unique

4
Agenda

• Overview / Why Change
• Writing Stories / INVEST
• User Role Modeling
• Gathering Stories

• User Proxies
• Estimating User Stories
• Why User Stories
• Additional 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
5
Introduction

• Software requirements is a communication problem
• This is normally between customers (incl.
  users/analysts/domain experts), and a
  technical team.

6
Need To Work Together

• When business dominates
• mandates functionality/dates with little concern
  that developers can meet both or if it is
  understood what is needed
• When developers dominate
• technical jargon replaces the language of the
  business and developers lose the opportunity to
  learn by listening

7
How Predictable?

• We cannot perfectly predict software development
• Users see early versions of software, they come
  up with new ideas and opinions change
• Because of the intangibility of software, most
  developers have a difficult time estimating how
  long things will take
• As such, we cannot lay out a perfect PERT chart
  showing all that must be done on a project

8
What is a User Story?
9
Example

• As a customer service representative, I can
  search for a customer so that I can view their
  account details.
• When searching by a valid account number, the
  account is shown
• When searching by a valid name and SSN, the
  account is shown
• If no results are found, show appropriate message
• Acceptance tests?

10
Some Guidelines

• Generally smaller scope is better
• and must be small enough to be completed by one
  pair in an iteration
• Generally the fewer the written details, the
  better
• Anyone can write a story
• why limit who can have a good idea?
• (does not mean it will be developed nor developed
  with those details)

11
INVEST

• Independent
• Negotiable
• Valuable (to users/customers)
• Estimatable
• Small
• Testable
• Our Experiences
• From Bill Wake, Extreme Programming Explored
  and Refactoring Workbook

12
Story Responsibilities

• Developer
• To help customers write stories that are promises
  to converse rather than detailed specs and that
  are INVEST
• If tempted to ask for a story about the use of a
  technology, instead describe the need in terms of
  its value to users/customer
• Customer
• Write promises to converse rather than detailed
  specs and INVEST

13
User Role Modeling
14
Why User Role Modeling?

• Many projects just do requirements from the
  perspective of user
• This simplification can be a fallacy that leads
  the team to miss stories

15
User Role Modeling Steps

• Brainstorm an initial set of user roles
• Generally dont need system roles
• Want to focus on the main user bases
• Organize the initial set
• Consolidate roles
• Refine the roles
• Frequency of their use
• Level of expertise with the domain
• General level of proficiency with computers
• Level of proficiency with software under dev.
• General goal for using software (convenience,
  rich experience)
• How long we spent. What we found.

16
Additional Techniques

• Personas
• Extreme Characters
• For a PDA
• Drug dealer
• Pope
• a 22 year old woman who is juggling multiple
  boyfriends

17
User Role Responsibilities

• Developer
• Participate in identification process
• Understand each user role
• While developing, consider how different roles
  prefer software to behave
• Customer
• Looking broadly in identification
• Ensure software focuses appropriately on the
  different roles/personas
• When writing stories ensure they are for at least
  one role/persona

18
Gathering Stories
19
Is It Elicitation and Capture Time?

• Terms like these imply requirements are out
  there. We just need them explained to us so we
  can lock them in a cage. ?
• Requirements not out in space waiting to be
  captured. Not a case of users already knowing
  requirements and just needing to elicit them.
• Whats a better metaphor???

20
Trawling

• Mental image that req. are captured in a fishing
  net
• Different-sized nets can be used to capture
  different-sized req. (can do multiple passes)
• size can be biz value, complexity, etc.
• Requirements, like fish, can grow in importance
  or shrink and die.
• You will not catch it all the first time and you
  will catch some flotsam
• Skilled practitioners will know where to look for
  stories

21
Story-Writing Workshops

• Includes developers, users, product owner, and
  others
• Low, low, fidelity prototype (made in the
  meeting, destroyed soon after)
• Start with a role/persona, then iterate through
  each of them
• Brainstorm components (could be a page, or
  section of a page doesnt matter)

22
Story-Writing Workshop Pt2

• Go through each component and brainstorm
• There is no lengthy debate on cards and limited
  negative feedback. Quantity over quality is the
  goal here
• Have a visible parking lot
• Want high level discussions. Again, goal is for
  as many stories as possible in a short time

23
Nonfunctional Requirements

• Many can be expressed as constraint stories.
  Automated tests can then be put in place and run
  each day
• Others cannot, and may need to be expressed in
  some other appropriate or traditional way

24
Estimating User Stories
25
When will you be done with these features?
Your Executive

• Best approach for estimating stories would be one
  that
• Allows us to change our mind when we have new
  information on a story
• Works for both epics and small stories
• Does not take a long time
• Is tolerant of imprecision in estimates
• Can be used to plan releases

26
Story Points

• Ideal days better than elapsed time or nebulous
  units
• Estimate as a team the team needs to own the
  estimate
• Delphi technique (on index cards) or party poker
  cards
• Triangulation
• Velocity and Central Limit Theorem

27
Estimation Responsibilities

• Developer
• Giving honest estimates
• Estimating as a team
• Consistent. Example, all 2 point estimates are
  similar
• Customer
• To participate in estimation meetings by
  answering questions and clarifying
• Not allowed to estimate stories yourself

28
Measuring Velocity

• Fully done, done story points are counted
• Partially completed stories do not count at all
• Dont imply precision by saying you completed 4.7
  points out of 8
• That last 10 can take 90 of the time
• The business value is not achieved until it is
  done, done (or do smaller stories)
• The actual velocity of the last two iterations is
  the planned velocity of the next

29
What Stories Are Not
30
Stories are not Use Cases

• Stories are smaller (lt10 points)
• UCs are long-living artifacts
• It is hard to keep interface requirements out of
  a UC. Story names are written from the
  perspective of business value (the rest is a
  conversation)
• Contract vs. conversation

31
Documents Handed-Off Are A Warning Sign

• Ping pong of a document
• Technical groups rewrite it (calling it something
  new, like Functional Specification) to hide same
  information different perspective
• Specs for complex projects are too big to read
  and hard to write with desired precision
• Blame Game (implied features or hidden
  out-of-scope statements)
• With conversations, nothing is final. We can
  always talk again
• Is this a good idea?

32
Why User Stories?
33
Stories Emphasize Verbal Communication

• Humans did not have written words for centuries
• Assumption that if something is written down,
  there is no ambiguity
• Lunch Menu Entrée comes with choice of soup or
  salad and bread.
• Soup or (Salad and Bread)
• (Soup or Salad) and Bread

34
Perfect?

• Traditional requirements seek to be perfect
• Can seem lofty and unattainable
• Even if you could get to perfectly explained
  written words
• Users refine their opinions as they learn more
• Problems of deferred defects and of verbal
  agreements undocumented when analyst capacity is
  low

35
Stories are Comprehensible

• Because stories are short, there is a better
  chance they will be read
• Because stories are written to show customer
  value, they are comprehensible to business and
  technical people

36
Stories Are The Right Size For Planning

• It is very hard to prioritize sections of a UC
• With stories it is much easier to prioritize scope

37
Stories Work For Iterative Development

• Do not need to write all stories before beginning
  coding
• Can write stories at whatever level of detail is
  appropriate (epics, last responsible moment)
• Can iterate on top of the stories from previous
  iterations

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

• Customers do not know exactly what they want
• Even if developers know all requirements, many
  details they need only become clear as the
  develop
• Even if all details could be known up front,
  humans are incapable of comprehending that many
  details
• Even if we could understand the details, product
  and project changes occur.
• People make mistakes.

39
Stories Support Opportunistic Development

• Developers work best by freely moving between
  requirements, designing at levels of abstraction,
  and development
• Allows developers see opportunities and then
  adjust design and approach
• Stories allow
• Users not knowing everything up front
• Developers not being able to fully comprehend a
  vast array of details
• Embracing change

40
Story Smells

• Interdependent Stories
• Goldplating
• Too Many Details (not INVEST)
• Thinking Too Far Ahead (waterfall mindset)