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
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
Copyright 2009 Code71, Inc. 6 Waterfall Project Planning “.” Project can be accurately planned in details
Copyright 2009 Code71, Inc. 7 In reality, software projects are like… forecasting weather- rain or shine?
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
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
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?
Copyright 2009 Code71, Inc. 11 Minimum Viable Product (MVP) Release#1 R#2 R#3 Expanding scope of MVP Release every sprint ideal
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?
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
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?
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
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
Copyright 2009 Code71, Inc. 17 Sprint 0 Project initiation sprint Business case Environment setup Architecture Team setup Team norms Training
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
Copyright 2009 Code71, Inc. 19 Rules of thumb A team size of 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
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
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?
Copyright 2009 Code71, Inc. 23 Definition of “Done” design+code+unit test functional test architecture load test code review design review regression test
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?
Copyright 2009 Code71, Inc. 25 Rules of thumb Tasks should be 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
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
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
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
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
Copyright 2009 Code71, Inc. 31 Burndowns Time spent Time remaining Track Remaining hours Track done Daily time entry
Copyright 2009 Code71, Inc. 32 Other charts Tracking actual time spent Tracking release
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?
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
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