Presentation is loading. Please wait.

Presentation is loading. Please wait.

Agile Planning, Estimation, and Tracking Syed Rayhan Co-founder, Code71, Inc. Contact: Blog: Company:

Similar presentations

Presentation on theme: "Agile Planning, Estimation, and Tracking Syed Rayhan Co-founder, Code71, Inc. Contact: Blog: Company:"— Presentation transcript:

1 Agile Planning, Estimation, and Tracking Syed Rayhan Co-founder, Code71, Inc. Contact: Blog: Company: Product:

2 Copyright 2009 Code71, Inc. 2 Agenda Recap Estimation Section 2 Section 4 Section 3 Tracking Planning Section 5 IntroductionSection 1 Q&A Section 6

3 Copyright 2009 Code71, Inc. 3 My Background Expertise Career  Iterative incremental development  Technology planning and architecture  On-shore/Off-shore software development using Agile/Scrum Interests  Co-founder, Code71, Inc., CSP, Agile Coach and Trainer  14+ years of total experience  Co-author of “Enterprise Java with UML”  Cultural aspect of self-organizing team  Scrum for projects delivered remotely  Agile engineering practices

4 Copyright 2009 Code71, Inc. 4 What to Expect Focus Context  Build a base for Agile planning  Contrast Agile planning with Traditional Planning  Address typical questions asked Key Takeaways  How to perform sprint planning and estimation  How to perform release planning an estimation  How to track progress against plan  How to adjust plan as project evolves  Teams and organizations are adopting Agile/Scrum  Teams struggle with making the transition from waterfall to Agile/Scrum

5 Copyright 2009 Code71, Inc. 5 Agenda Recap Estimation Section 2 Section 4 Section 3 Tracking Planning Section 5 IntroductionSection 1 Q&A Section 6

6 Copyright 2009 Code71, Inc. 6 Waterfall Project Planning “.” Project can be accurately planned in details

7 Copyright 2009 Code71, Inc. 7 In reality, software projects are like… forecasting weather- rain or shine?

8 Copyright 2009 Code71, Inc. 8 Planning WaterfallAgile All or noneIterative, incremental Prioritization is not importantPrioritization is key activity of planning Planning becomes a prioritization exercise Critical path is eliminated through time boxing Critical path is important PredictiveEmpirical

9 Copyright 2009 Code71, Inc. 9 How to do prioritization? Informal MoSCoW Ad-hoc and intuitive Must have, Should have, Could have, Would not have Formal Priority = Business Value/Complexity ROI (= Business value – Cost) based prioritization Kano Mandatory, Linear, Exciter Threshold, Performance, Excitement

10 Copyright 2009 Code71, Inc. 10 MoSCoW Must haves Should haves M inimum U sable S ubse T for production (a.k.a. Minimum Viable Product) Important, but absence of it would not make the product useless Could haves Optional, if fund and time are available Would not haves Out of scope, defines the boundary of the product Pros and Cons?

11 Copyright 2009 Code71, Inc. 11 Minimum Viable Product (MVP) Release#1 R#2 R#3 Expanding scope of MVP Release every sprint ideal

12 Copyright 2009 Code71, Inc. 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?

13 Copyright 2009 Code71, Inc. 13 Kano Analysis Like - Neutral Dislike ? EI L T L ? - Q#2 (Absence of a feature) Like Neutral Dislike Q#1 (Presence of a feature) - disregard, ? probe further, I indifferent E exciter, L linier, T threshold

14 Copyright 2009 Code71, Inc. 14 Formal BV High Complexity Priority Low Medium Low Medium High LowMedium 1 4? 8 7 5? 6? Pros and Cons? LowHigh9 Medium High 2 3?

15 Copyright 2009 Code71, Inc. 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

16 Copyright 2009 Code71, Inc. 16 Sprint Planning Capacity Scope Estimation Load factor Availability factor Holidays Vacations Set a sprint goal Take stories from the top of the product backlog Total points = Velocity Task breakdown Estimate tasks in actual hours or days Assign task owners Assign a story owner Verify estimate against capacity

17 Copyright 2009 Code71, Inc. 17 Sprint 0 Project initiation sprint Business case Environment setup Architecture Team setup Team norms Training

18 Copyright 2009 Code71, Inc. 18 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

19 Copyright 2009 Code71, Inc. 19 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

20 Copyright 2009 Code71, Inc. 20 Agenda Recap Estimation Section 2 Section 4 Section 3 Tracking Planning Section 5 IntroductionSection 1 Q&A Section 6

21 Copyright 2009 Code71, Inc. 21 Estimation Relative Story points Absolute Hours/Days Used for Release planning Used for Sprint planning Why relative estimation? Velocity, suitable for longer horizon Accuracy is not importantAccuracy is important to some extant Eliminates biasDoes not eliminate bias Cannot be compared with another team’s Supports comparison

22 Copyright 2009 Code71, Inc. 22 Relative estimation using “Planning Poker” Decide on scaleFibonacci scale Identify a reference story setUse most understood story as a reference story for each level on the scale Estimate the rest Everybody estimates individually, then reveals as a team, hence the term “Planning Poker” Challenges?

23 Copyright 2009 Code71, Inc. 23 Definition of “Done” design+code+unit test functional test architecture load test code review design review regression test

24 Copyright 2009 Code71, Inc. 24 How to resolve disagreement in estimation? Consensus Majority Ask the outliers and discuss as a team to agree on an estimate Pick the one that was chosen by the majority Choose the highest To err on the side of caution Pros and Cons?

25 Copyright 2009 Code71, Inc. 25 Rules of thumb Tasks should be 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

26 Copyright 2009 Code71, Inc. 26 Velocity Velocity without a quality metric is not useful Velocity of two teams are not comparable Velocity changes with team composition Velocity increases with team’s tenure Velocity is not productivity Do not include bugs and rejected stories Points delivered by a team per sprintDefinition Keep in mind Used to determine sprint scope Used to calculate approximate costs of a release Used to track release progress How to use? How to calculate?Rolling average of 4 weeks, Max, Min, Lifetime average

27 Copyright 2009 Code71, Inc. 27 Agenda Recap Estimation Section 2 Section 4 Section 3 Tracking Planning Section 5 IntroductionSection 1 Q&A Section 6

28 Copyright 2009 Code71, Inc. 28 How do you track progress? 50% done 3 stories done, 5 stories remaining Vs. You don’t get credit for partial work Waterfall MS Project ScrumPad Agile

29 Copyright 2009 Code71, Inc. 29 Tracking progress Track remaining hours, track done/remaining points by day Sprint Burndown Sprint Burnup Metrics Release BurndownTrack remaining points by sprint Track time spent by day Velocity, Bug find rate per sprint, Bug fix rate per sprint, Test coverage

30 Copyright 2009 Code71, Inc. 30 Tracking progress A 15-minute standup meeting where team answers the following; 1)What did I do yesterday? 2)What am I going to work on today? 3)What is impeding my work, if any? Daily Scrum Retrospective Sprint ReviewTeam meets with the product owner and stakeholders to show the work done in the current sprint and solicit feedback. Team meets at the end of each sprint to discuss- 1)What is working well? 2)What needs improvement? and 3)How to improve/fix the process? tracking impediments

31 Copyright 2009 Code71, Inc. 31 Burndowns Time spent Time remaining Track Remaining hours Track done Daily time entry

32 Copyright 2009 Code71, Inc. 32 Other charts Tracking actual time spent Tracking release

33 Copyright 2009 Code71, Inc. 33 Let’s test our understanding  Difference between relative vs. absolute estimation?  How to do resource allocation?  Do you still need a Gantt chart?  How to handle shared resources?  How to plan for production support work?  How to plan for fixed bid contract?  What is velocity?  Who does planning?  How to improve estimation?  How do you ensure team delivers what they plan to deliver in a sprint?

34 Copyright 2009 Code71, Inc. 34 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

35 Copyright 2009 Code71, Inc. 35 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

36 Copyright 2009 Code71, Inc. 36 Q&A Contact: Blog: Company: http://www.code71.com Product:

Download ppt "Agile Planning, Estimation, and Tracking Syed Rayhan Co-founder, Code71, Inc. Contact: Blog: Company:"

Similar presentations

Ads by Google