Agile Planning Estimation

  • 5,077 views
Uploaded on

This presentation gives an overview of how Agile planning and estimation is different from traditional approaches. Then it shows step by step how to do planning and estimation on an Agile project.

This presentation gives an overview of how Agile planning and estimation is different from traditional approaches. Then it shows step by step how to do planning and estimation on an Agile project.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Excellent agile overview presentation
    Are you sure you want to
    Your message goes here
  • James,
    Yes, I agree with you. I mention that in my slides (release every sprint). That is an advanced stage of agile maturity. However, in real life, especially for large enterprise systems, and or organization with different infrastructure and support team, you end up doing a sprint before release taking care of miscellaneous stuff (necessary evil). You need to exclude those steps from your definition of 'Done.' Don't you think?
    Are you sure you want to
    Your message goes here
  • HRM. 'Stabilization sprint' is a sign that the team is having problems getting a good definition of done or achieving it. I would highly recommend against a stabilization sprint and spend more time achieving a level of done that includes whatever you would do in said sprint. :P
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,077
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
216
Comments
3
Likes
9

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Teams either skip QA, or Teams continue to do QA as they did on waterfall projects. Impedance mismatch results. We end up being not so Agile and QA becomes a sore point in the whole process.
  • Copyright 2005 Syed Humayun Rayhan. All rights reserved Entrée comes with soup or salad and bread
  • Copyright 2005 Syed Humayun Rayhan. All rights reserved
  • Activities are broken down into independent elements
  • Expected features- Indifferent  Mandatory Bugs- Dissatisfier-> Mandatory
  • Must- 50% Should- 20% Could- 20% If software can be released without a feature, then it is not a “Must Have.” Is there a workaround? If yes, then it may not be a “Must Have.” Is the software useless without it? If yes, then it is probably a “Must Have.”
  • Agile training if new
  • Definition of a medium story will fit to the length of the sprint and will vary from team to team Choose shorter sprint if high volatility/experimental product or quickly changing domain or very involved product owner
  • A user story
  • Need a definition of “done” Need a set of acceptance criteria => acceptance tests
  • Good for long term planning Biases cancel each other out Adjust to the length of the sprint
  • How does estimate change with the length of the sprint?
  • Copyright 2005 Syed Humayun Rayhan. All rights reserved
  • What kind of impediments? Who removes the impediments? Make sure feedback is received. Feedback impacts the backlog- modify existing stories, reprioritize, add new stories.
  • Focus on one thing at a time. Come up with some action items. Assign a owner. Track progress.
  • Copyright 2005 Syed Humayun Rayhan. All rights reserved
  • Copyright 2005 Syed Humayun Rayhan. All rights reserved
  • Too many changes, not enough time

Transcript

  • 1. Agile Planning, Estimation, and Tracking Syed Rayhan Co-founder, Code71, Inc. Contact: srayhan@code71.com Blog: http://blog.syedrayhan.com Company: http://www.code71.com Product: http://www.scrumpad.com http://www.scrumpad.com http://www.code71.com Copyright 2010 Code71 Inc. All rights reserved .
  • 2. Agenda Section 1 Introduction Section 2 Planning Section 3 Estimation Section 4 Tracking Section 5 Recap Section 6 Q&A www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 2
  • 3. My Background  Co-founder, Code71, Inc., CSP, Agile Coach and Trainer Career  14+ years of total experience  Co-author of “Enterprise Java with UML”  Iterative incremental development Ex pertise  Technology planning and architecture  On-shore/Off-shore software development using Agile/Scrum  Cultural aspect of self-organizing team  Scrum for projects delivered remotely Int erest s  Agile engineering practices  Lean Startup www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 3
  • 4. What to Expect  Teams and organizations are adopting Agile/Scrum Contex t  Teams struggle with making the transition from waterfall to Agile/Scrum  Build a base for Agile planning Focus  Contrast Agile planning with Traditional Planning  Address typical questions asked  How to perform sprint planning and estimation  How to perform release planning an estimation K ey  How to track progress against plan T akeaways  How to adjust plan as project evolves www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 4
  • 5. Agenda Section 1 Introduction Section 2 Planning Section 3 Estimation Section 4 Tracking Section 5 Recap Section 6 Q&A www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 5
  • 6. Waterfall Project Planning Project can be accurately planned in details www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 6
  • 7. In reality, software projects are like… forecast ing weat her- rain or shine? www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 7
  • 8. Planning A gile Wat erfall Empirical Predict ive It erat ive, incremental A ll or none Priorit izat ion is key act ivit y of Priorit izat ion is not import ant planning Crit ical path is eliminat ed through Crit ical pat h is import ant t ime box ing Planning becomes a prioritization exercise www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 8
  • 9. How to do prioritization? Informal A d-hoc and int uit ive MoSCoW Must have, Should have, Could have, Would not have Calculated Priorit y = Business V alue/Complex ity Formal ROI (= Business value – Cost ) based priorit izat ion K ano Mandat ory, Linear, Ex cit er www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 9
  • 10. MoSCoW Must Minimum U sable S ubse T for haves product ion (a.k .a. Minimum V iable Product ) Should haves Import ant , but absence of it would not mak e t he product useless Could Opt ional, if fund and t ime are available haves Would not Out of scope, defines t he boundary of t he haves product Pros and Cons? www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 10
  • 11. Minimum Viable Product (MVP) Release#1 R#2 R#3 ideal Release every sprint Expanding scope of MVP www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 11
  • 12. Kano Analysis Survey Q#1 Rate your satisfaction if the product has “this” feature? Q#2 Rate your satisfaction if the product does not have “this” feature? Answers: A) Like it, B) Neutral, C) Dislike it Additional Question for trade-off analysis How much extra would you pay for “this” or more of “this” feature? www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 12
  • 13. Kano Analysis Q#1 (Presence of a feat ure) Like Neutral Dislike - ? Q#2 (A bsence of a feat ure) L Like Neut ra E I ? l Dislike L T - - disregard, ? probe further, I indifferent E exciter, L linier, T threshold www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 13
  • 14. Formal BV Complexity Priority High Low 1 High Medium 2 High High 3? Medium Low 4? Low Low 5? Medium Medium 6? Medium High 7 Low Medium 8 Low High 9 Pros and Cons? www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 14
  • 15. Release Planning • Set a release goal • Determine scope through prioritization • Determine a release date • Define sprints • Allocate stories to sprints • Product backlog grooming • Ideally release every sprint www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 15
  • 16. Sprint Planning Capacity Scope Estimation • Load factor • Set a sprint goal • Task breakdown • Availability factor • Take stories from • Estimate tasks in the top of the actual hours or days • Holidays product backlog • Assign task owners • Vacations • Total points = • Assign a story owner Velocity • Verify estimate against capacity www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 16
  • 17. Rules of thumb for Sprint Planning • Tasks should be between 4 -16 hours • For a two-week sprint (most popular sprint length) • 2-4 hours planning • 1-2 hours of sprint review • 1-2 hours of sprint retrospective • Allocate a fixed hours for production support or other unavoidable routine work (10-15%) • 10% for product backlog grooming www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 17
  • 18. Sprint 0 • Project initiation sprint • Business case • Environment setup • Architecture • Team setup • Team norms • Training www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 18
  • 19. Integration / Stabilization Sprint • One or more sprints needed to stabilize a release before final rollout • Ideally a product is always ready for rollout • Final integration and regression tests • Load test • Any last minute bug fixes • Production environment setup • Any other steps (organization specific) needed before production rollout www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 19
  • 20. Rules of thumb • A team size of 7-9 • 1 and half medium stories per developer • 1 Tester for every two developers • Do not change sprint length • Prefer 100% allocation over partial allocation of people www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 20
  • 21. Agenda Section 1 Introduction Section 2 Planning Section 3 Estimation Section 4 Tracking Section 5 Recap Section 6 Q&A www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 21
  • 22. Unit of Planning www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 22
  • 23. How do we know when we are done? design review code review architecture load test design+code+unit test functional test regression test www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 23
  • 24. Estimation Absolute 12 oz 16 oz 20 oz small medium large Relative 3 5 8 www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 24
  • 25. Estimation Relative Absolute Story points Hours/Days Used for Release planning Used for Sprint planning Accuracy is not important Accuracy is important to some extant Eliminates bias Does not eliminate bias Cannot be compared with Supports comparison another team’s Why relative est imation? V elocit y, suit able for longer horizon www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 25
  • 26. Relative estimation using “Planning Poker” Decide on scale Fibonacci scale (1, 2, 3, 5, 8, 13, 21…) Identify a reference story set Use most understood story as a reference story for each level on the scale Everybody estimates individually, then Estimate the rest reveals as a team, hence the term “Planning Poker” Challenges? www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 26
  • 27. How to resolve disagreement in estimation? Consensus A sk the out liers and discuss as a t eam t o agree on an est imat e Majorit y Pick t he one t hat was chosen by t he majority Choose t he T o err on the side of caution highest Pros and Cons? www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 27
  • 28. Velocity Definition Points delivered by a team per sprint How to calculate? Rolling average of 4 weeks, Max, Min, Lifetime average • Velocity without a quality metric is not useful • Velocity of two teams are not comparable • Velocity changes with team composition Keep in mind • Velocity increases with team’s tenure • Velocity is not productivity • Do not include bugs and rejected stories • Used to determine sprint scope How to use? • Used to calculate approximate costs of a release • Used to track release progress www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 28
  • 29. Agenda Section 1 Introduction Section 2 Planning Section 3 Estimation Section 4 Tracking Section 5 Recap Section 6 Q&A www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 29
  • 30. How do you track progress? MS Project 50% done Wat erfall V s. ScrumPad 3 st ories done, 5 st ories remaining A gile Y ou don’t get credit for part ial work www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 30
  • 31. Tracking progress Sprint Burndown Track remaining hours, track done/remaining points by day Release Burndown Track remaining points by sprint Sprint Burnup Track time spent by day Metrics Velocity, Bug find rate per sprint, Bug fix rate per sprint, Test coverage www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 31
  • 32. Tracking progress Daily Scrum A 15-minute standup meeting where team answers the following; tracking 1) What did I do yesterday? impediments 2) What am I going to work on today? 3) What is impeding my work, if any? Sprint Review Team meets with the product owner and stakeholders to show the work done in the current sprint and solicit feedback. www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 32
  • 33. Continuous Improvement (Inspect and Adapt) Retrospective Team meets at the end of each sprint to discuss-  What is working well?  What needs improvement? And  How to improve/fix it? www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 33
  • 34. Burndowns Track Remaining hours Track done Daily time entry • Time spent • Time remaining www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 34
  • 35. Other charts Tracking actual time spent Tracking release progress www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 35
  • 36. Let’s test our understanding  Difference between relative vs. absolute estimation?  How to do resource allocation?  How to handle shared resources?  How to plan for production support work?  Do you still need a Gantt chart?  How to plan for fixed bid contract?  Who does planning?  What is velocity?  How to improve estimation?  How do you ensure team delivers what they plan to deliver in a sprint? www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 36
  • 37. Recap  Prioritize product backlog on an on-going basis  Estimate backlog in story points for release planning  Estimate backlog in actual hours or days for sprint planning  Pick a suitable sprint length and stick with it  Allocate people to a single project in a single sprint  Staff the team in the beginning and keep the team in place through out the life of the project www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 37
  • 38. Recap contd.  The team should be cross-functional- include testers, Sys admins, DBA, SMEs  Team should be physically or virtually collocated  Know your team “velocity”  Use open space  Use appropriate information radiators www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 38
  • 39. Q&A Please contact for on-site training or Webinar: Contact: srayhan@code71.com Blog: http://blog.syedrayhan.com Company: http://www.code71.com Product: http://www.scrumpad.com www.Code71.com Copyright 2010 Code71 Inc. All rights reserved . www.ScrumPad.com 39