Joel Semeniuk CEO, Imaginet Resources Microsoft Regional Director Microsoft MVP – Team System DPR205
Download ReportTranscript Joel Semeniuk CEO, Imaginet Resources Microsoft Regional Director Microsoft MVP – Team System DPR205
Joel Semeniuk CEO, Imaginet Resources Microsoft Regional Director Microsoft MVP – Team System DPR205 What Is an Estimate? Estimate <> Target or Commitment Estimate • Prediction Target • Desire Commitment • Promise Estimate <> Planning Estimation • Analytical Unbiased Process • Goal = Accuracy Planning • Biased Goal-Seeking Process • Goal = Seek Result Plans Need Good Estimates Scheduling Defining Iterations Identifying Critical Path Estimation Prioritization Breaking Down Work Common Scenario How long do you think this project should take? We need to have it ready in 3 months with these features…. My estimates say we can do this in 5 months 5 Months? Didn’t you hear me? I need to have this in 3 months for the trade show! The manager wasn’t asking for an estimate but a plan to solve a problem… Tip: When asked for an estimate – determine if it should be an estimate or a plan to hit a target Single Point Estimates Rarely is a single point estimate an estimate Estimates should include some level of probability Tip: When you see a single point estimate – question to see if this is really a target Tip: When you see a single point estimate – you should question the probability Tip: Don’t use a planning tool to make estimates (e.g., MS Project) Using MS Project and Single Point Estimates ID Task Name 0 1 2 3 4 5 6 7 New Product Work 14,272 hrs Baseline Really? Variance 0 hrs 14,272 hrs Actual Remaining 0 hrs 14,272 hrs New Product Development 14,272 Template hrs 0 hrs 14,272 hrs 0 hrs Initial NewProduct Screening 72 hrs Stage 0 hrs 72 hrs 0 hrs New product opportunity identified 0 hrs 0 hrs 0 hrs 0 hrs Describe new product idea 16(1-page hrs written0 disclosure) hrs 16 hrs 0 hrs Gather information required 48 hrs for go/no-go decision 0 hrs 48 hrs 0 hrs Convene opportunity of screening 8 hrs committee 0 hrs (decision to pursue 8 hrs idea or not) 0 hrs Decision point - go/no-go to 0 hrs preliminary investigation 0 hrs 0 hrs 0 hrs 14,272 hrs 72 hrs 0 hrs 16 hrs 48 hrs 8 hrs 0 hrs % W. Comp. 0% 0% 0% 0% 0% 0% 0% 0% Estimation Challenges Provide a 90% Confident Estimate for the following: How many people are at this conference? What is the size of the largest whale ever discovered? How many bugs will you have in your next software project? What is the distance between Mars and the Sun? What is the surface temperature of the sun? What is the total volume of the Great Lakes? Question: What makes you think you are 90% confident? Question: Did you use an artificially narrow range? Question: Where does the pressure to use a narrow range come from? Two Important Laws of Nature Parkinson’s Law If you give a person 5 days to deliver a task that could be delivered in 4, the person will find something to do with that extra day The Student Syndrome If given too much time, people procrastinate until late in the project, at which point they rush to complete the work, and likely won’t finish on time These are two common arguments against Overestimation Uncertainty and Software Estimation Not all requirements are known until development time in most cases Narrowing the Cone Tip: The cone does not narrow itself; it narrows when you continually make decisions that narrow variability Sources of Error 1. Chaotic Development Process 2. Unstable Requirements 3. Omitted Activities 4. Unfounded Optimism 5. Subjectivity 6. Off-the-Cuff Estimates Things that Influence Estimates Project Size Type of Software Being Developed Personnel Factors Programming Languages and LOTS of others such as: • • • • • • Complexity Constraints Turnover Experience Tools Ego • • • • • Team Cohesion Process maturity Architecture Risk Technology Maturity I’m sure you can name 10 more… Estimation Practices Count, Compute, Judge Calibration and Historical Data Expert Judgment Decomposition and Recomposition Estimation by Analogy Proxy-Based Estimates Expert Judgment in Groups Use of Multiple Approaches Count, Compute, Judge Count, Compute, Judge If you can count something – count it Use “expert” judgment when there’s nothing to count What to count? Something correlated with size of software Something we can count sooner rather than later Something that will produce a statistically meaningful average Something that you understand Something you can count with minimal effort Count, Compute, Judge Examples of things you can count… List of things More things Requirements Web Pages Features Bugs Use cases Reports Stories Dialog boxes Function Points Database Tables Change Requests Classes Tests Cucumbers Calibration and Historical Data Helps to transform Count into Estimate Best way to predict today’s weather is to look at yesterday’s Ways to calibrate: Industry Data Historical Data Project Data Industry Data Historic Project Data Example Team Size Average Stories Delivered per Sprint 1 5 2–3 12 4–5 22 6–7 31 8 No Data Tip: Using Time and “Actual Effort” as historical data is difficult Current Project Data Use Data from the Current Project to Predict the Rest of the Project Data for Sprint 1 Remainder of Project 27 story points (sp) delivered Effort = 2.25 sp per staff week (spsw) 12 staff weeks (sw) Schedule = 9 sp per calendar week (spcw) 3 calendar weeks (cw) Project size = 180 sp Preliminary Calibration Preliminary Whole-Project Estimate Effort = 27sp / 12sw = 2.25 sp per sw Effort = 180sp/2.25 spsw = 80 staff weeks Schedule = 27sp / 3w = 9 sp per cw Schedule = 180sp / 9 spcw = 20 calendar weeks Individual Expert Judgment Two Types Intuitive Expert Judgment (Spidey Senses) – not very accurate Structured Expert Judgment – almost as accurate as model-based estimates Who Estimates? People who are doing the work – most accurate Granularity End up with estimates that are around ¼–1 day large Use Ranges Best Case, Most Likely Case, Worst Case Use Formulas Optimistic PERT = [BestCase+(4XMostLikely)+WorstCase]/6 Pessimistic PERT = [BestCase+(3xMostLikely)+(2xWorstCase)]/6 Decomposition and Recomposition AKA – Bottom Up The Law of Large Numbers Single Large Estimates are usually Largely wrong in a single direction (+/-) Breaking into smaller pieces – some are above, some are lower The error at the detail level balances out the error on the whole How Small to Break Things Down? You need 5–10 smaller things to start seeing benefits Use Common Work Breakdown to Avoid Missing Activities Category Create/Do Plan Integration X X Documentation X X Etc X Manage Review X X X Rework Defect X X X X Big Problem with Bottom UP Aggregating Estimates Doesn’t Work Well Use complex standard deviation formulas to aggregate when you have more than 10 tasks This can get VERY complicated if you want to be accurate Take a statistics course for more information Estimation by Analogy Get details of previous project decomposed by feature area, work breakdown or some other scheme Compare size of new project piece by piece Build up estimate of new project as a % of the old project size Create an effort based on the size of the new project compared to old Check for congruent assumptions Proxy-based Estimates Find a Proxy that correlates to what you are estimating that is easier to estimate/count E.g., Estimation of # of Test Cases is correlated to # of Requirements Some use Proxies to estimate lines of code What do lines of code really give you? Some great techniques Story Points T-Shirt Sizing Good for estimating test cases, defects, documentation, etc. Story Points Assign a size to each story you are building Story Point Scale Specific Points to the Scale Powers of 2 1, 2, 4, 8, 16, 32 Fibonacci 1, 2, 3, 5, 8, 13, 21 Story Points Example Story Points Story 1 2 Story 2 1 Story 3 4 Story 4 8 … Story 60 2 Total 180 Need to Calibrate an Iteration Data for Iteration 1 27 Story Points Delivered 12 Staff weeks 3 Calendar Weeks Calibration: Effort = 27 story points / 12 staff weeks = 2.25 story points/staff week Schedule = 27 story points / 3 calendar weeks = 9 story points/calendar week Projecting Further Assumptions from Calibration Effort = 2.25 story points/staff week Schedule = 9 story points/calendar week Project size = 180 story points Preliminary Whole-Project Estimate Effort = 180 story points / 2.25 story points/staff week = 80 staff weeks Schedule = 180 story points / 9 story points/calendar week = 20 calendar weeks T-Shirt Sizing How do Sales people and Delivery people work together? Sales people need to know relative size to help determine priority Estimator won’t estimate until further decomposed Early in the Cone of Uncertainty Remember – goal isn’t accuracy, but accurate enough to support control and decisions Can use T-shirt sizing to help T-Shirt Sizing Feature Business Value Dev Cost Feature A Large Small Feature B Small Large Feature C Large Large Feature D Medium Medium Using for Prioritization Business Value Extra Large Large Medium Small Extra Large 0 4 6 7 Large -4 0 2 3 Medium -6 -2 0 1 Small -7 -3 -1 - Feature Bus. Value Dev Cost Net Value Feature A L S 3 Feature B L M 2 Feature C L L 0 Feature D M M 0 Expert Judgment in Groups Group reviews can be fun Have each team estimate pieces individually, compare results Don’t average estimates Arrive at consensus Techniques Wideband Delphi Technique (quite formal) Estimation Poker (quite fun) Mixing Things Up E.g., Expert Proxy Judgment in Groups Quick Demos Feature Prioritization Worksheet – T-Shirt Sizing (kinda) Feature Point Worksheet Multi-Point Worksheet Estimation Poker Some Parting Thoughts Keep Estimation Simple Time Boxing is your friend Do things that minimize uncertainty Don’t be afraid to re-estimate and thus, re-plan Estimation via consensus is harder than you think Sometimes you have to commit; I’m sorry Be careful when recording historic data – time-based data is all a lie and lines of code are meaningless when technology changes Find a method that works for you – then continually improve Reference [email protected] Resources www.microsoft.com/teched www.microsoft.com/learning Sessions On-Demand & Community Microsoft Certification & Training Resources http://microsoft.com/technet http://microsoft.com/msdn Resources for IT Professionals Resources for Developers www.microsoft.com/learning Microsoft Certification and Training Resources Complete an evaluation on CommNet and enter to win! © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.