Agile planning and Estimating     www.q1systems.com
Contents•   3 levels of planning•   Release planning•   Iteration Planning•   Velocity determination•   Velocity-based rel...
3 Levels of Agile Planning                          Release 1.0                           Backlog     Product Backlog     ...
Agile Planning – Product Roadmap                                                          A product/release roadmap       ...
Release Planning (1): Epics Stories• Epic_1234: User Administration  –   UserStory_0100: Users can self-register  –   Use...
Release Planning (2): Stories Story PointsEpic/Story                                                                     ...
Story Point Estimating (1)Don’t estimate time:   –   Estimate relative size (story points) of stories   –   Use Fibonacci ...
Story Point Estimating (2)• Estimates are done by the people doing the work• Estimate continuously during the project, not...
Story Point Planning BoardEpic/User Story                                                                                 ...
Iteration Planning: Stories  Tasks• Epic_1234: User Administration                                                    Mak...
Team Velocity Determination•   Execute the 1st sprint, and stick to your defined time-box (e.g. 2-weeks)•   At the end of ...
Velocity-Based Release PlanningAssume team velocity = 20• Project start: January 1• Project finish: June 30• Sprint length...
Thank-you!http://www.q1systems.com       Copyright (c) Q1 Systems LLC   13
Upcoming SlideShare
Loading in …5
×

Agile planing slide_share

1,003 views

Published on

Agile planning and estimating

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,003
On SlideShare
0
From Embeds
0
Number of Embeds
199
Actions
Shares
0
Downloads
30
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Agile planing slide_share

  1. 1. Agile planning and Estimating www.q1systems.com
  2. 2. Contents• 3 levels of planning• Release planning• Iteration Planning• Velocity determination• Velocity-based release planning Copyright (c) Q1 Systems LLC 2
  3. 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. 4. Agile Planning – Product Roadmap A product/release roadmap can be constructed from the product backlog once the velocity has been established Product RoadmapRelease: 1.0 Release: 2.0 Release: 3.0 Release: 3.1Target: Q1 2012 Target: Q2 2012 Target: Q3 2012 Target: Q4 2012Goal: Initial Market Goal: Support Goal: High-Availablity Goal: Non-LinuxEntry European Market Version platform variantsFeatures: 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. 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. 6. Release Planning (2): Stories Story PointsEpic/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. 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. 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. 9. Story Point Planning BoardEpic/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. 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. 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. 12. Velocity-Based Release PlanningAssume 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. 13. Thank-you!http://www.q1systems.com Copyright (c) Q1 Systems LLC 13

×