Product Backlog Workshop

 

Glenn Waters

LinkedIn

Github

Details about These Slides

The Content

This slide deck is both a workshop and training material. The material is meant to progress through an exercise of creating a groomed (refined) Product Backlog. Slides with a blue background are information for the workshop. Slides with a black background are training material that support the exercise.

Ideas and material come from many places, perhaps hundreds of places. The bookmeeting.com exercise comes from Henrik Kniberg and a couple of the pictures are from his material. Thank you Henrik!

A couple of the ideas for the flow of the exercise come from Joe Little and how he runs a “Agile Product Refactoring” workshop. Please check out his workshops!

Feedback

Comments and improvements gratefully accepted! Find me on LinkedIn.

Usage

Feel free to use the material, as long as you follow the Creative Commons license.

Help Navigating

Press “?” to see list of keyboard shortcuts.

Other

The deck is built using the reveal.js framework and Jekyll.

bookmeeting.com Workshop

  • Background on exercise, requirements
  • Product Backlog, User Stories
  • Splitting stories
  • Estimating and tracking
  • Building a Product Backlog

Background

  • We are greatsoftware.com
  • General situation
    • Today is January 1st
    • Outlook/Exchange will be outlawed on April 1!
  • Our goal:
    • Create bookmeeting.com an online resource booking service targeted primarily towards those that use Outlook for booking meeting rooms.
    • March 1: Pilot customer will start using it.
    • April 1: Commercial rollout.
  • Our context:
    • We have access to a pilot customer – a conference center!
    • We have built similar services before, so we have a functioning team, development environment, and operational environment.
    • This project is top priority, we have a 5-person Scrum team ready to start today.

Agile Planning Principles

  • Release early and often
  • Plan at the last responsible moment
    • Defer planning until as much as responsibly possible is learnt
    • Keep your options open
    • Decide ahead of time when that moment is
  • Use the YAGNI principle
  • Adapt your plans — regularly
  • Work on one project at a time

Agile Planning

  • Occurs frequently
    • Release planning
    • Sprint planning
    • Product Backlog Refinement
    • Daily Scrum
  • Focus on delivering highest value features first
  • Plan changes frequently

Product Backlog Item (PBI)

  • An item describes a small piece of business functionality
  • Owned by the Product Owner but developed by the many
  • Modifiable as we learn more about the product, customers, and needs

Don’t Give the Team a Solution

Give the Team a Problem to Solve

Product Backlog Items

  • Items are reminders to have a conversation
    • Emphasize verbal rather than written communication
  • Encourage added detail at the last responsible moment
    • When the team has a better understanding of what is to be built
  • Used for planning
  • Capture a user’s need

Conversation Reminders??

What does the following sentence mean?

I handed in a script last year and they didn’t change a single word.

The word they didn’t change was on page 87. — Steve Martin

PBI Scope

  • PBIs should cover system from top to bottom
    • Avoid creating stories with implementation details
    • Focus customer value and not on technical details
    • Why cover all the layers?

PBI Size

  • PBIs should not be too large
    • You should be able to complete multiple Items in a Sprint
    • With all members of The Team working on the item
    • Complete means done according to Definition of Done

A Format for PBIs: User Stories

  • Start with a Title
    • Active verb
    • About 5 words or less
  • Create a short description often using template shown here
  • Add relevant information over time
    • Sketches, notes, acceptance criteria, etc.

Example User Story

Product Backlog

  • A collection of PBIs for a product is called the Product Backlog
  • It’s the master list of all functionality desired in the product
  • The Product Backlog is:
    • Owned and ordered by the Product Owner
    • However, anyone can contribute
    • Constantly changing and reordered as more is learned

Shape of the Backlog

  • Which shape is best?
  • What characteristics make it best?

Why Split PBIs into Small Pieces

  • Create core business value faster
  • Understand domain quicker
  • Understand technology quicker
  • Allow feedback based on real implementation
  • Understand capacity of the team
  • Enable ability to ship product sooner (allows for options)
  • Easier to estimate small things
  • Allows for backlog changes (new/change/delete/reprioritize)
  • Allows for better flow
  • Expose risk
  • Pride in progress (The Progress Principle)

Some Patterns for Splitting

  • Simplest thing that could possibly work
    • What is the minimum thing that could be implemented?
  • Along Create, Read, Update, Delete (CRUD) boundaries
  • Along data boundaries
    • e. g.: For a user, handle personal info in one item, then address info, then preferences
  • By quality
    • e.g.: Simple UI versus “Bells & whistles” UI
  • By major effort
    • e.g.: First report then other reports
  • 0, 1, many
  • Defer performance
  • Break out a spike
    • e.g.: Investigate as first item, implement as other item(s)
  • Happy path
    • Defer data validation
    • Defer error handling
  • Hard code
  • Focus on an acceptance criteria
  • By Persona

Imperfect Requirements

Product Vision

  • Welcome to bookmeeting.com! It doesn’t get any simpler than this.
  • Getting started guide:
    • Create an account at bookmeeting.com
    • Set up rooms
    • Your company can now surf to bookmeeting.com and book meetings!
  • Payment
    • Pay per month (rate may vary depending on number of rooms)

Roles

  • Booker
    • Creates & administrates meeting bookings, invites participants
  • Participant
    • Attends meetings. Receives invitations & updates
  • Admin
    • Sets up rooms & users
  • Buyer
    • Buys the service & pays for its use
  • Seller
    • Hosts service & charges for use. Initially greatsoftware.com

Exercise Step One

  • Teams of 4-5 people
    • One person on team plays the PO role
    • Can make (arbitrary) decisions about content
  • Create at least 33 Product Backlog Items
    • One PBI per index card
    • Use Sharpie
    • User Story format may be useful
  • Consider silent writing, working in pairs, or other techniques
  • You have 16.5 minutes

Business Value

In teams discuss what business value is and ways it could be determined.

What is Business Value?

Anything that is valuable to the business

  • Revenue generators
  • Cost reduction
  • Risk reduction
  • Customer satisfaction
  • Knowledge generation

How to Calculate Business Value

  • Should we? Maybe the question is “How do we find the stories that provide the most value?”
  • Value is relative
    • i.e.: Is this story more valuable than that story?
  • “Planning” Poker technique might be useful to evoke conversations
  • Innovation Games: Buy a Feature

Exercise Step Two

  • Order your Product Backlog by Business Value
  • Strict ordering; can’t have “these 5 are priority 1”
  • 15 minutes

Agile Estimating

Option 1 — Count Features

  • Features have different sizes
  • Ignore size difference
    • It evens out over time

Agile Estimating

Option 2 — #noestimates

Some reading

Agile Estimating

Option 3 — Relative Sizing

  • Estimate relative size of features
    • Don’t estimate time
  • Estimates done by the team doing the work
  • Favour face-to-face over written specs
  • Re-estimate regularly
  • Use relative sizes to plan Sprints/Releases

Story Points

  • Pick a smaller story and assign it 2 story points
    • “Smaller” is very roughly a team-day of work
    • The remaining stories will be estimated relative to the baseline story
  • For each of the remaining stories:
    • Briefly discuss the story
    • Each person silently picks an estimate
    • At the same time all estimators show their estimate
    • Differences in the votes, especially outliers, will generate discussion
    • Re-estimate until estimates (roughly) converge
  • This should be fast — 1-2 stories/minute

Story Points Values

  • Modified Fibonacci sequence
    • 0, ½, 1, 2, 3, 5, 8, [13, 20, 40, 100]
  • Small manageable numbers
    • 0, 1, 2, 3
  • T-Shirt sizes
    • XS = 0, S = 1, M = 2, L = 4, XL = 8, XXL = 20
  • Note that 0 + 0 + 0 ≠ 0
    • At some point too many “free” items cost real points

Planning Poker Cards

Why Planning Poker Works

  • Those doing the work do the estimates
  • Group discussion/justification of differences leads to better understanding and hence better estimates
  • People are much better at relative sizing than absolute sizing
  • Estimates are constrained to a small set of numbers
    • Limited choice constrains discussion
  • It’s fun

Exercise Step Three

  • Estimate your Product Backlog
  • Use limited set of Story points
    • 1, 2, 3, 5, 8
  • 15 minutes

Velocity

  • Velocity is the number of Story Points completed by a team in a Sprint
    • Story must be completed and accepted by PO to claim points
  • Used by the team as an indicator of how many stories to bring into a Sprint
    • Yesterday’s Weather metaphor
  • Can’t compare one team’s Velocity to another’s

Trends & Yesterday’s Weather

Release Burnup

Fixed Scope

Fixed Date

Fixed Scope and Date

Fixed Scope and Date

Exercise Step Four

Estimate Velocity (without prior history)

  • 5 person team
  • 10 day Sprint
  • 2 Story Points = ~1 ideal team day
  • Ability to focus on project: 50%
  • Sprint 1 “team startup cost”: 40%
  • Sprint 2 “team startup cost”: 20%
  • Compute estimated Story Points for 6 Sprints
  • On a sheet of paper create a Burnup Chart
  • Mark the two key milestones on the chart:
    • March 1 and April 1
  • 10 minutes

Why oh why?

Group Discussion

What is the value in having the entire team, plus Product Owner, plus stakeholders invovled in the Product Backlog creation?

Westboro Systems Creative Commons License
Agile Training by Glenn Waters is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.