User Stories - PowerPoint PPT Presentation

1 / 89
About This Presentation
Title:

User Stories

Description:

How about if we break them out? 6/16/09. XP 2000. 25. Story ... Break it down into one-week stories relating to product features: Make report 100 work on DB2 ... – PowerPoint PPT presentation

Number of Views:389
Avg rating:3.0/5.0
Slides: 90
Provided by: ronaldej
Category:
Tags: breaking | stories | user

less

Transcript and Presenter's Notes

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