User Stories

1
User Stories Planning Game

• XP 2000
• Cagliari, Sardinia
• Ron Jeffries
• http//www.Xprogramming.com
• ronjeffries_at_acm.org

2
User Stories Planning Game

• Introduction
• Getting Stories
• Estimating Stories
• Release Plan
• Iteration Plan
• Special Topics
• Discussion
• Questions are welcome throughout!

3
Business Value

• Extreme Programming
• Delivers and
• Steers by
• Business Value
• Business Value belongs to the customer!

4
Cards, Cards, nothing but Cards

• Stories on cards
• Estimates on cards
• Release planning with cards
• Iteration planning with cards
• Designing with cards

5
Why Cards

• Tangible
• Non-threatening
• Modular
• Replaceable
• Biodegradable
• Provide fiber

6
Card Issues

• Losing them
• Distributing them across the world
• Paper cuts

7
Process Overview

• Customer writes stories on cards
• Customer defines acceptance test for story
• Programmer estimates stories
• Customer selects stories for release
• Customer selects story for iteration
• Programmer defines tasks for story
• Programmer signs up and estimates tasks
• Programmer does tasks (with partner)
• Customer accepts completed stories

8
Introduction - discussion
9
Getting Stories

• Stories
• must belong to customer
• must have business value
• must make sense to programmer
• must be estimatable
• Stories must belong to customer

10
Story Parts

• Card
• text describing the story
• Conversation
• the real understanding
• Confirmation
• the acceptance test

11
Example Story

• Cost of Living Allowance (COLA)
• EEs may receive COLA. Some unions pay a fixed
  amount per pay. Some pay a percentage of base.
  Amount or percentage varies by union and
  location. COLA rates change at specified times
  for different unions.
• Each EE receives COLA in each check.

12
COLA Conversation
13
COLA Confirmation

• Acceptance Test
• Provide EEs from each union and from no union.
  Pay each EE for three pay periods, test whether
  COLA amount properly calculated.
• Determine whether COLA amount properly displayed
  on check or EFT stub.

14
Employee GUI Story

• Change obligation printout in EE GUI to look like
  the check stub. Copy attached.

15
Employee GUI Discussion
16
Union Dues

• Biweekly bargaining unit EEs are charged union
  dues automatically. Dues vary by union, location,
  time in grade, and by SSN (10 EEs).
• Dues are taken ONLY in first pay of month.

17
Union Dues Discussion
18
Getting Stories

• Joint effort, programmers and customers
• Dont outnumber them
• Get customers writing
• Help customers focus on value
• Help customers keep stories estimatable
• Stories belong to customer!!

19
Getting Stories

• Customer writes stories
• dont create
• dont translate into tech talk
• just UNDERSTAND
• Therefore
• educate customer on issues
• dont take responsibility back
• Listen, dont tell
• Tell me about ...

20
Getting Stories

• Offer flexibility when easier
• Withhold flexibility when harder

21
Getting Stories

• Offer flexibility when easier
• Instead of just four adjustment entries, how
  about we accept any number, in a scrolling list?

22
Getting Stories

• Withhold flexibility when harder
• Do you want to be able to sort and search on all
  combinations of all fields?

23
Getting Stories

• Split stories that are too big to estimate
• We want to be able to query the database and find
  any record based on any attribute. We need
  reports with summaries on all major dimensions,
  and two- and three-dimensional graphs. We need
  faster-than-light communication and the ability
  to walk on water.

24
Getting Stories

• Split parts with different priorities
• In this story with the display and the sorting
  and the filtering, is each of those features
  equally important? No? How about if we break them
  out?

25
Story Issues

• Non-functional stories
• Duplication
• Big stories
• Generic Stories

26
Non-functional Stories

• System must be easy to use
• System must be able to support 30,000 users
• System runs on Windows, Linux, and BeOS
• No one can steal anyone elses data

27
Non-functional Stories

• Some need up-front attention
• Security
• Some just need to be remembered
• Performance
• Easy to use
• Some need continuing attention
• Portability
• Easy to use
• Remember Refactoring

28
Non-functional Stories

• Refactoring
• Code is done when it
• runs all the tests
• expresses every concept you want to express
• contains no duplicate code
• has minimum classes and methods.

29
Non-functional Stories

• Write them on cards
• Discuss them
• Remember them
• Watch for testing opportunities
• Performance?
• Watch for refactoring opportunities

30
Duplication in Stories

• Blah blah blah
• Send the calculated amount to General Ledger as
  Account 1234
• mumble mumble
• Send the calculated amount to General Ledger as
  Account 3261

31
Duplication in Stories

• Should we split the story?
• Pro
• May be too big in early stories
• Dont know how to do general ledger
• Con
• Doubles number of stories
• Should be done together anyway

32
Duplication in Stories

• One possible solution
• Split first few
• Perhaps on the fly in iteration planning
• Watch for commonality
• Refactor
• Build Tools
• Get General Ledger to be trivial

33
Big Stories

• Change the system over from Oracle to DB2
• Estimate
• Well, we have about 100 SQL scripts, and each one
  will take a day to convert, plus about three
  months to set up DB2, so eight months!

34
Big Stories

• You may just be out of luck
• Focus on business value
• Break it down into one-week stories relating to
  product features
• Make report 100 work on DB2

35
Big Stories

• Setting up DB2
• You may just have to dedicate some people and
  time to it.
• Recognize this is very bad.
• The people arent being guided, and they arent
  delivering business value
• Customer really is getting less value day to day

36
Big Stories

• Commit to
• make everything a story
• everything in a few days
• completely incremental project
• You may surprise yourself

37
Generic Stories

• Acceptance Testing
• GUIs
• OK for Release Planning
• Trouble for Iteration Planning
• Make placeholders - dont work on them

38
Getting Stories - discussion
39
Estimating Stories

• What is the best way to know how long something
  will take?
• Do it and pay attention to how long it took.
• But thats not possible ...
• Or is it?

40
Estimating Stories

• Break stories down until you reach ...
• Programs you have already written
• Experiment where you have no experience
• Exploration must precede estimation!

41
Standard Algorithms

• Reports
• record layout
• selection
• headers
• footers
• summaries
• 1/2, 1, 2 days

42
Standard Algorithm

• GUI
• Sketch Screen
• Number of widgets
• Number of data sources
• Number of actions
• 1/2, 1, 2 days

43
Estimating Stories

• Assume Simplicity
• Trust your refactoring
• Split when more than two weeks
• Split when part seems difficult
• Easy cards
• Hard cards
• Unknown cards - Explore!!

44
Estimating Stories

• TRAP Should we do X, or Y?
• Doesnt change the estimate?
• Just estimate.
• Changes the estimate?
• Pick simpler and estimate

45
Estimating Stories

• What if one way of implementing offers some real
  benefit?
• Make it a story.
• Trust the customer
• Trust refactoring

46
Estimating Stories

• Estimating is a team process
• Deal with any story in 3 minutes or less
• estimate
• min/max estimate
• split
• schedule exploration
• Become an estimating machine!

47
Estimating - discussion
48
Release Plan

• Exploration
• Commitment
• Steering

49
Release Plan

• You MUST be prepared!
• Have the stories
• Be familiar with them
• Spikes and explorations
• Metaphor
• You MUST be ready to estimate!

50
Metaphor

• Common vision
• how the program works
• what it is like
• Lack of metaphor
• MUCH reduced communication
• weaker plan
• slower progress

51
Exploration

• Spike Solution
• Get to the essence
• Limit to 1/2 day where possible.
• Never more than two or three

52
Release Plan

• Commitment
• Purpose
• Choose what to do for release
• Choose what to defer

53
Commitment Principle

• Fill the bag
• You have one shopping bag and a trip through the
  store. Your mission is to plan how you will fill
  the bag with the stuff that will be best to take
  home.
• The good news you get to change your mind while
  youre in the store!

54
Release Plan Steps

• Everyone understands the stories
• Programmers estimate the stories
• Customers choose the stories

55
Estimating Stories

• Estimate based on experience
• Dont engineer.
• Dont OVER-engineer.
• You MUST be prepared!

56
Estimating Stories

• Programmers split into groups
• Estimate all stories
• Lower any estimate unilaterally
• Discuss estimates that seem too low
• Try not to raise them

57
Commitment

• Story estimates complete
• Estimate project velocity
• Calendarize stories

58
Project Velocity

• How many weeks stories can the team do per
  iteration?
• Use historical velocity where available
• Estimated project velocity
• 1/2 to 1/3 week per programmer week

59
Why is velocity so low?

• It isnt low
• based on history from many startup projects.
• Velocity is a fact
• This is just the initial estimated velocity
• Early estimates are often optimistic
• Other tasks, especially early in process
• Settling in
• Desire to win

60
Pair Programming and Velocity

• Experimental and anecdotal evidence
• higher quality
• about the same time
• improves learning
• Project will move faster overall
• If you stop pair programming
• you WILL slow down
• quality WILL decline

61
Pair Programming

• With pair programming, you get the maximum power
  of the pair, all the time.
• With single programming, you get the average.

62
Release Plan

• Calendarize the stories
• Mark out iterations on table
• Place cards in each iteration, up to limit of
  velocity
• Voila! Schedule!

63
Release Plan

• This is what COULD happen
• but its not what WILL happen
• Lets go back to the grocery store
• Only have giant hams
• Steak has gone up
• We forgot about pork chops
• We will learn
• learning, we will change our plan
• Its a GOOD thing

64
Release Plan - discussion
65
Iteration Plan

• Purpose
• Plan two or three weeks work
• Format
• Exploration
• Commitment
• Steering

66
Iteration Plan

• Exploration
• Customer explains stories
• Commitment
• Team brainstorms tasks
• Programmer
• signs up
• estimates
• Adjust

67
Whiteboard Approach

• Change GUI to show all homes within 1 mile of
  chosen neighborhood
• Add location data john 2 days
• Define distance algorithm mary 1 day
• Define selection SQL script john 1 day
• Add script to GUI john 1/2 day
• Provide ability for realtor to enter and save
  private estimated sale prices
• blah blah sue 2
  days

68
Customer explains story

• Change GUI to show all homes within 1 mile of
  chosen neighborhood
• Write story on board
• Discuss for understanding
• Value
• What does it mean
• How will it be tested?

69
Customer explains story

• Change GUI to show all homes within 1 mile of
  chosen neighborhood
• Customers like to choose neighborhoods.
• Theres an available location field on each home
  record. Latitude and Longitude.
• Well test on February data, in the Wildwood
  neighborhood. Were making a list of all the
  homes that should be found.
• Actual neighborhood boundaries? Another story

70
Team brainstorms tasks

• Change GUI to show all homes within 1 mile of
  chosen neighborhood
• Add location data
• Define distance algorithm
• Define selection SQL script
• Add script to GUI

71
Programmer signs up estimates

• Change GUI to show all homes within 1 mile of
  chosen neighborhood
• Add location data john 2 days
• Define distance algorithm mary 1 day
• Define selection SQL script john 1 day
• Add script to GUI john 1/2 day

72
Adjust

• Someone has too much or too little to do?
• Trade tasks until load is equal
• Team has too little to do?
• Customer adds stories
• Team has too much to do?
• Customer simplifies or removes stories

73
Adjustment

• Isnt adjustment painful?
• It can be, but its not as painful as not
  accomplishing what you set out to do.
• Like it or not, an iteration plan has a taste of
  promise ...
• Best way to keep that promise is not to
  over-estimate your capacity

74
Iteration Planning Tips

• No background or framework tasks
• No generic story cards

75
Background Tasks

• Setting up the database
• Setting up the production box
• Building the file-loading scripts
• Always associate with business value
• Always do incrementally

76
Why no background?

• XP works by allowing business value and cost
  estimates to balance and steer the project
• Background efforts take resources off the table
• Reducing business ability to steer
• Reducing confindence and teamwork

77
But we have to do background

• Lets get creative with some examples
• A team had a task to set up scripts to detect the
  presence of input files and FTP them to the
  production machine at 4 AM. They were planning to
  do this as a background task. How can we turn
  this task into a story?
• When we customers come in to work at 8 AM, the
  files are loaded and ready, so we can get to work
  right away.

78
But we have to do background

• Discussion

79
Generic Story Cards

• Common Generic story cards
• Work on the GUI - 2 days
• Work on Acceptance Tests - 3 days
• Work on the database - 2 days

80
What about generics

• Often necessary during release plan
• We dont know the details
• But we know there will be work to do
• Therefore we must have cards to estimate
• Out of control in iteration plan
• If not specific, no value!
• No value, no steering!

81
Make generics specific

• Customer converts generic story placeholders to
  real stories
• Enhance General Ledger GUI to include sums at
  department and location levels
• Add support for employee vacaton records to
  database
• Build functional test to check union dues
  according to attached spreadsheet.

82
Iteration Plan - discussion
83
Special Topics

• Specialized Efforts
• Specialized Workers
• Related XP Practices

84
Specialized Efforts

• Documents
• Slide Presentations
• Dog and Pony Shows
• Online Instant Project Status System
• Must be stories!!
• Account for them
• Pay for them
• Balance and Steering

85
Specialized Workers

• Testers
• good
• QA Department
• Feedback
• Empire
• Work expands to fill the workers available
• Small boy with a QA Department
• Specialists limit customer flexibility!

86
Related XP Practices

• Simple Design
• Enables rapid delivery of business value
• Refactoring
• Enables simple design
• Unit Testing
• Enables refactoring

87
Related XP Practices

• Pair Programming
• Empowers customer to put stories in any order
• Acceptance Testing
• Proves delivery business value

88
Discussion
89
User Stories Planning Game

• XP 2000
• Ron Jeffries
• http//www.Xprogramming.com
• ronjeffries_at_acm.org