XP Immersion

1
User Stories Planning Game

• XP Immersion
• Vernon Hills, IL
• Ron Jeffries
• Ann Anderson (in spirit)
• Chet Hendrickson (in spirit)

2
User Stories Planning Game

• Learn by Doing
• Release Planning 3 hr
• Acceptance Tests 45 min
• Estimating 45min
• Writing Stories 45 min
• Release Plan 45 min (???)
• Iteration Plan 45 min

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
Exercise Release Planning

• Simulate a project several times
• There will be a score for each team
• But there will be no prizes ?

9
Exercise Release Planning

• Important new project
• Executive Visibility
• 45 Features
• Six Months
• Plan the Project month by month
• Do the Project

10
What you may experience

• Confusion or Fear
• This is something new
• Frustration
• This isnt my job!
• But it is
• Too many stories, not enough time
• Pay attention to what you feel as you go.

11
Release Plan Discussion

• What have we learned?
• Stories have varying costs
• Team can only do so much per month
• Stories have varying value
• Value lost if you never release
• Value maximized if you release often
• Highest value is not always highest priority
• What else?

12
Exercise Acceptance Tests

• You have been picked by the executives (us) to
  build our new ATM software.
• Elect a Customer
• Read and understand stories
• Define acceptance tests
• Make decisions within your team, but we have
  important needs. Check with us wisely.

13
What you may experience

• Confusion or Fear
• This is something new
• Frustration
• This isnt my job!
• But it is
• Too many stories, not enough time
• Pay attention to what you feel as you go.

14
Acceptance Test Discussion
15
Exercise - Estimation

• Now we senior executives need to know how long
  the ATM will take to complete.
• System Design (as a group?)
• Estimate each story
• Read and discuss tasks
• Estimate time to complete
• Write on card with Pencil

16
What you may experience

• Confusion, fear
• Too many stories, not enough time
• Pay attention to what you experience

17
Estimation Discussion
18
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?

19
Estimating Stories

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

20
Standard Algorithms

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

21
Standard Algorithm

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

22
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!!

23
Estimating Stories

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

24
Estimating Stories

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

25
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!

26
Estimating Stories

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

27
Estimating Stories

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

28
Exercise Writing Stories

• You are to define our new course registration
  system.
• Split into two groups of about 4
• Write all the stories for this application
• Take turns one story per person
• Non-writing members help
• ask questions
• estimatable
• acceptance test

29
What you may experience

• Its too easy
• Its too hard
• Its too phony
• Tendency to over-specify
• Tendency to specify implementation
• Pay attention to what happens and what you
  experience

30
Writing Stories Discussion
31
Getting Stories

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

32
Story Parts

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

33
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.

34
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.

35
Employee GUI Story

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

36
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.

37
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!!

38
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 ...

39
Getting Stories

• Offer flexibility when easier
• Withhold flexibility when harder

40
Getting Stories

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

41
Getting Stories

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

42
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.

43
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?

44
Exercise Release Plan

• Produce a release plan for your course system
• Two customers move to next table
• Explain stories to programmers. Use acceptance
  test as necessary.
• Programmers estimate stories
• Plan against calendar. Ask instructors for
  velocity.

45
What you may experience

• Time pressure
• Not enough to do
• Pay attention to what you experience

46
Exercise Release Plan Again
47
Release Plan 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
Commitment

• Story estimates complete
• Estimate project velocity
• Calendarize stories

56
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

57
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

58
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

59
Pair Programming

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

60
Release Plan

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

61
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

62
Exercise Iteration Plan

• Do an iteration plan for the first iteration of
  the release plan
• Customer Explains Story
• Team Brainstorms Tasks
• Programmers
• Sign up
• Estimate

63
Iteration Plan Discussion
64
Iteration Plan

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

65
Iteration Plan

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

66
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

67
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?

68
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

69
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

70
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

71
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

72
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

73
Iteration Planning Tips

• No background or framework tasks
• No generic story cards

74
Background Tasks

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

75
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 confidence and teamwork

76
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.

77
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

78
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!

79
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 vacation records to
  database
• Build functional test to check union dues
  according to attached spreadsheet.

80
Special Topics

• Specialized Efforts
• Specialized Workers
• Related XP Practices

81
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

82
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!

83
Related XP Practices

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

84
Related XP Practices

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

85
Story Issues

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

86
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

87
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

88
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.

89
Non-functional Stories

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

90
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

91
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

92
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

93
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!

94
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

95
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

96
Big Stories

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

97
Generic Stories

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

98
User Stories Planning Game

• XP Immersion
• Vernon Hills, IL
• Ron Jeffries