XP Immersion - PowerPoint PPT Presentation

1 / 98
About This Presentation
Title:

XP Immersion

Description:

User Stories & Planning Game. XP Immersion. Vernon Hills, IL. Ron Jeffries ... Too many stories, not enough time. Pay attention to what you feel as you go. 6/19/09 ... – PowerPoint PPT presentation

Number of Views:65
Avg rating:3.0/5.0
Slides: 99
Provided by: ronaldej
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com