This document discusses agile planning at three levels: release, iteration, and product backlog. It describes how epics in the product backlog are broken into user stories for release planning and then tasks for iteration planning. It also covers determining a team's velocity through tracking story points completed over iterations and using that velocity for release planning to estimate release dates.

1. Agile planning and Estimating
www.q1systems.com

2. Contents
• 3 levels of planning
• Release planning
• Iteration Planning
• Velocity determination
• Velocity-based release planning
Copyright (c) Q1 Systems LLC 2

3. 3 Levels of Agile Planning
Release 1.0
Backlog
Product Backlog
Iteration
Backlog
Release 2.0
Backlog
Iteration
Backlog
Release 3.0
Backlog
Iteration
Backlog
• Product Backlog: “Epic-Level” granularity (customer-facing functionality)
• Release Planning: Epics  User Stories (implementable ‘chunks’ of functionality)
• Iteration Planning: User Stories  Tasks (work required to deliver stories)
Copyright (c) Q1 Systems LLC 3

4. Agile Planning – Product Roadmap
A product/release roadmap
can be constructed from the
product backlog once the velocity
has been established
Product Roadmap
Release: 1.0 Release: 2.0 Release: 3.0 Release: 3.1
Target: Q1 2012 Target: Q2 2012 Target: Q3 2012 Target: Q4 2012
Goal: Initial Market Goal: Support Goal: High-Availablity Goal: Non-Linux
Entry European Market Version platform variants
Features: Features: Features: Features:
• Feature 1 • Feature 6 • Feature 11 • Feature 16
• Feature 2 • Feature 7 • Feature 12 • Feature 17
• Feature 3 • Feature 8 • Feature 13 • Feature 18
• Feature 4 • Feature 9 • Feature 14 • Feature 19
• Feature 5 • Feature 10 • Feature 15 • Feature 20
4
Copyright (c) Q1 Systems LLC

5. Release Planning (1): Epics Stories
• Epic_1234: User Administration
– UserStory_0100: Users can self-register
– UserStory_0101: Users can login using credentials supplied at reg.
– UserStory_0102: Administrators can browse registered users
– UserStory_0103: Administrators can search for registered users
– UserStory_0104: Administrators can disable user accounts
• Epic_1235: Lorem ipsum dolor sit amet
– UserStory_0105: consectetur adipisicing elit
– UserStory_0106: sed do eiusmod tempor incididunt.
– UserStory_0107: ut labore et dolore magna aliqua
– UserStory_0108: Ut enim ad minim veniam
– UserStory_0109: quis nostrud exercitation ullamco
Copyright (c) Q1 Systems LLC 5

6. Release Planning (2): Stories Story Points
Epic/Story Story Points
1 2 3 5 8 13
•Epic_1234: User Administration
•UserStory_0100: Users can self-register 3
•UserStory_0101: Users can login using registration credentials 2
•UserStory_0102: Administrators can browse registered users 3
•UserStory_0103: Administrators can search for registered users 5
•UserStory_0104: Administrators can disable user accounts 1
•Epic_1235: Lorem ipsum dolor sit amet
•UserStory_0105: consectetur adipisicing elit 1
•UserStory_0106: sed do eiusmod tempor incididunt. 2
•UserStory_0107: ut labore et dolore magna aliqua 3
•UserStory_0108: Ut enim ad minim veniam 5
•UserStory_0109: quis nostrud exercitation ullamco 8
Total: 33 2 4 9 10 8
Copyright (c) Q1 Systems LLC 6

7. Story Point Estimating (1)
Don’t estimate time:
– Estimate relative size (story points) of stories
– Use Fibonacci scale: 0, 1, 2, 3, 5, 8, 13…
– Compare with reference stories if available
– Measure velocity (story points delivered per sprint)
– Determine velocity with 2 initial Sprints
– Derive release plan
We want a story’s size so we can do velocity-based release planning
Copyright (c) Q1 Systems LLC 7

8. Story Point Estimating (2)
• Estimates are done by the people doing the work
• Estimate continuously during the project, not all up front
• How to Estimate Stories:
– Pick smallest relevant story and give it 1 point
– Estimate relative size of other stories
• A 2-point story is twice the size of a 1-point story
• A 3-point story is as big as a 1- and 2-point story combined
– Discuss outliers and adjust until numbers are within 3 points, then average
– Break down big stories into smaller stories
– Use reference stories if available
• Why it works: estimation errors tend to cancel each other
• Team’s first sprint will include a 40% overhead (formin’, stormin’, normin’
etc)
Copyright (c) Q1 Systems LLC 8

9. Story Point Planning Board
Epic/User Story Story Points
1 2 3 5 8 13
•Epic_1234: User Administration
•UserStory_0100: Users can self-register 3
•UserStory_0101: Users can login using registration credentials 2
•UserStory_0102: Administrators can browse registered users 3
•UserStory_0103: Administrators can search for registered users 5
•UserStory_0104: Administrators can disable user accounts 1
•Epic_1235: Lorem ipsum dolor sit amet
•UserStory_0105: consectetur adipisicing elit 1
•UserStory_0106: sed do eiusmod tempor incididunt. 2
•UserStory_0107: ut labore et dolore magna aliqua 3
•UserStory_0108: Ut enim ad minim veniam 5
•UserStory_0109: quis nostrud exercitation ullamco 8
Total: 33 2 4 9 10 8
Tools:
• Whiteboard + Post-its
• Spreadsheet + Projector
• Agile tool of choice
• Webex/GoToMeeting/Skype for distributed teams
9
Copyright (c) Q1 Systems LLC

10. Iteration Planning: Stories  Tasks
• Epic_1234: User Administration Make sure task list
– User_Story_0100: Users can self-register meets definition of
• Task_8001: Create new page with registration form ‘Done’ for user story
• Task_8002: Create user class to support all required data
• Task_8003: Create methods to collect user data and insert into database
• Task_8004: Create database schema to support user details
• Task_8005: Code review of all new and modified code
• Task_8006: Create and execute unit tests for the story
• Task_8007: Add unit tests to the unit test automation library
• Task_8008: Create acceptance tests for the story
• Task_8009: Execute acceptance tests
• Task_8010: Acceptance test automation
– User_Story_0101: Users can login using the credentials supplied
at registration
– User_Story_0102: Administrators can browse registered users
– User_Story_0103: Administrators can search for registered users
– User_Story_0104: Administrators can disable user accounts
Copyright (c) Q1 Systems LLC 10

11. Team Velocity Determination
• Execute the 1st sprint, and stick to your defined time-box (e.g. 2-weeks)
• At the end of the sprint only count points for stories that get completely finished
per your definition of done. At this point you should also revise any estimates that
turned out different from the original.
• Team velocity = total story points delivered
• Calibrate with 2 initial Sprints
• Team’s first sprint likely to include up to a 40% overhead
• Velocity should be measured for every sprint and the trend should be closely
monitored.
• Use retrospectives to identify opportunities for continually improving the team’s
velocity.
Velocity
25
20
15
10
5
0
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Copyright (c) Q1 Systems LLC 11

12. Velocity-Based Release Planning
Assume team velocity = 20
• Project start: January 1
• Project finish: June 30
• Sprint length: 2 weeks
• Sprints required: 13 (26/2)
• Total story point capacity = 260 (13 * 20)
Let’s say the release planning estimates a total of 300 points to be delivered:
• In this example, the team is required to trim approximately 40 (low-priority)
story points from the release backlog to meet the June 30 release date.
• Alternatively, need to plan 2 more sprints to deliver the entire 300 points
Copyright (c) Q1 Systems LLC 12

13. Thank-you!
http://www.q1systems.com
Copyright (c) Q1 Systems LLC 13