The art of estimation
0 likes•206 views
Estimating the size and effort required for projects and tasks is important for planning purposes but difficult to do with precision. Estimates are informed guesses that can vary due to factors like unclear requirements, lack of historical data, and scope changes. While estimates are not perfect, they provide value by enabling prioritization, collaboration, and iterative planning. Effective estimation techniques include using ranges rather than single points, factoring in assumptions, combining expert judgement with data-driven methods, and refining estimates over time as understanding improves.
The art of estimation
- 1. 1 The Art of Estimation
- 2. 2 ➢ How long will it take to read 500 page thick book? ➢ How long will it take to drive to a particular city or state? ➢ How much money it will take to organize a b’day party? What is estimate? ➢ How long will it take for you to build a sand castle like this: “As the size and complexity increases, it becomes almost impossible to give a precise estimate” “There is no such thing as accurate estimate. Estimate is an informed guess (a probability) which can be different from actual. Variance is a reality which we need to accept.”
- 3. 3 Estimation – Reason of Variance No Historic Data Unclear Requirements Lack of Domain or technical knowledge Scope Creep Non-developer Estimating Variance ➢ Just for an illustration, imagine each of the variance source causes 30% variance then cumulative range of variance could be: - “1 – 1.3*1.3*1.3*1.3*1.3” = “1 – 3.7” => 270% variance ➢ If can’t estimate accurately then why estimate? Some Lean/Kanban experts believe “Estimate is overhead. It’s waste.”. There is “#Noestimate” movement.
- 4. 4 Estimation Advantages ➢ Sponsor and end customers expect early information about cost and timelines. ➢ Estimation help in managing projects interdependencies and organizational dependencies. ➢ Estimation helps in understanding the viability. It helps to identify early on, anything not worth pursuing. ➢ Estimation helps in prioritization as prioritization is not just function of value but value & cost (ROI) ratio. ➢ Estimation helps in better planning and execution. ➢ Estimation provides another opportunity to collaborate and get better understanding of ‘What’ and ‘How’ (requirements and implementation).
- 5. 5 Estimation Basics / Tips ➢ Estimate in range rather than giving a single figure. Example: It would take 15-30 minutes to reach office depending on traffic conditions. “It’s better to be roughly right than precisely wrong” – John Maynard Keynes. ➢ Any estimate is as good as its underlying reasoning and assumptions. Example: While giving this estimate for time to reach office, I am assuming private vehicle rather than public transport and travel during non-peak traffic hours. ➢ Historic data (past projects) is good for estimation. ➢ Current data (current project) is even better and that’s where agile focuses. ➢ Estimation is not a one time activity. It is done iteratively as we progressively elaborate the project’s ‘what’ and ‘how’ so modify it when you learn anything new.
- 6. 6 Estimation cone of uncertainty The cone doesn’t narrow itself. We have to force it to narrow by reducing variability.
- 7. 7 Estimation Techniques ➢ Expert Judgement ➢ Analogous / Top Down Estimate – Estimating based on analogy with other similar projects done in past. ➢ Used when very little information is available. Estimates are known as Rough Order of Magnitude or ballpark estimates. ➢ Parametric Estimate – Uses statistical relationship between historical data and other variables to calculate and estimate. ➢ Micro / Bottom-up estimate – Require a detailed WBS (Work breakdown structure), activity list and resources. Estimate is summation of individual estimates of small parts. We combine techniques. Expert Judgement or analogous estimate in the beginning when less information is available. Use bottom-up or other detailed estimation techniques later on.
- 8. 8 Wide Band Delphi Delphi is structured way to create forecast based on inputs from panel of experts. Wideband Delphi is a variation of that with following steps: 1) Choose the team – Select moderator and estimation team considering representation from all areas (eg development, testing, devops, product etc) 2) Kick Off Meeting – Moderator leads a discussion to brainstorm assumptions, WBS, units of estimation etc 3) Individual Preparation – Estimators individually prepare tasks list, estimate and assumptions 4) Estimation Session – Discussion on estimation range and outliers. Attempt is to gain consensus on estimate, tasks list and assumptions. 5) Assemble Tasks – Compilation of final tasks list, estimate and assumptions. 6) Review Results
- 10. 10 PERT – 3 Point estimation ➢ Scope is broken down into components / activities / work packages. Each component is given 3 estimates – Optimistic (O), Pessimistic (P), Most Likely (M) ➢ Estimate used for planning = (O+4M+P) / 6 ➢ Standard Error for each component σte = (p - o) ÷ 6 ➢ Risk Spread Example: Say we have only two tasks: 1) Task 1 – Optimistic estimate 5; Most likely 8; Pessimistic 11 2) Task 2 – Optimistic estimate 3; Most likely 6; Pessimistic 12 Estimate = (5+4*8+11)/6 + (3+4*6+12)/6 = 13.5 Risk Spread = SQRT (SQR((11-5)/6) + SQR((12-3)/6)) = 1.8 This gives estimate range of 11.8 to 15.3 instead of 8 to 23. Adding 2*risk spread givens 95% confidence estimate which is 17.1 in this case.
- 11. 11 Affinity Estimation ➢ Done as first round of estimation for: ➢ Providing initial view of size to PO for prioritization. ➢ Team to identify items too big or too complex for possible split / spikes. ➢ It has five steps: 1. Silent Relative Sizing 2. Discussion to edit the wall 3. Place items into relative size buckets 4. Product owner challenge 5. Store the data in electronic tool
- 12. 12 Ideal days / hours estimation ➢ Ideal Time is - How long something would take if a) It’s all you work on b) You have no interruptions c) You have all you need ➢ Elapsed time is total time taken to finish the work ➢ Ideal time for a American footwall game is 60 minutes – Four 15 minutes quarters. The elapsed time is much longer and hard to accurately predict. ➢ Ideal Days estimate is easy to estimate (at least initially) and explain but hard to convert into elapsed time. ➢ Trainings, meetings, phone calls and task switching etc affect difference between ideal time and elapsed time.
- 13. 13 Relative Estimation ➢ Giving measurement baselines will not help because: a) It’s very difficult and time consuming to measure. b) Given dimensions may not be accurate and result in most going to a single box. ➢ Triangulation will help. Triangulation means comparing each sample with multiple other samples. ➢ Relative estimation is slow and difficult in the beginning but once you have estimated few, it will be fast and easy. Small Medium Large Can you divide mangoes from this huge pile into three boxes based on size? Do you need to be told the exact dimension, length, width etc to identify different sizes?
- 14. 14 Story Point Estimation ➢ Story Points is unit-less, relative size estimate which factor in both size (how much there is?) and complexity (how hard it is?). ➢ Relative size is what is important. ➢ Example: Login Feature is 2; Search is 8 (as it’s approx 4 times bigger and harder than Login Feature). ➢ Smallest story point could be of 1 story point ➢ Don’t use a single gold standard, rather triangulate i.e. compare with multiple reference stories ➢ Basic math function (addition / subtraction still hold good). ➢ Each team defines these unit less points as they see fit. Can’t compare story point estimates of two teams. ➢ Teams often defines handful of stories as reference stories to help with estimation process.
- 15. 15 Benefits of story point estimation ➢ Faster & Easier - Once team get a hang of it, story point estimation is much faster and easier than day/hours estimate. ➢ Drive cross-functional behavior – It helps drive cross functional behavior as whole team needs to provide single story point estimate for given user story. ➢ Don’t change with time – With time as team becomes more efficient or gets inefficiencies, effort estimate in days/hours for same work changes which make it difficult to separate efficiency change from estimate change. No such issue with story point estimation as it’s relative. ➢ Avoids elapsed time vs effort confusion - Invariably ‘x’ days estimated work is supposed to be finished in ‘x’ days which is often not true. ➢ Story point estimation is difficult for new agile teams so one mid-way approach could be: a) Define “1 story point = 1 ideal day” b) Gradually convert team to thinking in unit-less story points and unlearn a)
- 16. 16 Agile Estimation – Just in time Each of the priority items has a size estimate in story point or ideal days Very large item at the bottom(which may not be for current release) may not have estimate or may have estimate in large units As items move up in the priority list of unfinished items, these are refined further for better estimate Accuracy 2 3 1 3 5 8 3 13 20 40 100 L XL
- 17. 17 Story point estimationAccuracy Effort ➢ A little effort helps a lot but then lot of effort only helps a little more. ➢ Agile doesn’t believe in too much precision and want just enough precision to allow planning. That’s the key reason for using non-linear scale.
- 18. 18 Using the right scale ➢ Can you decide whether given story is a one point story OR a two points story? ➢ How about deciding whether given story is a 14 points story OR a 15 points story? ➢ Use a non-linear scale. Two commonly used scales are: a) Fibonacci Series – 1,2, 3, 5, 8, 13, 20, 40, 100… b) Power of two – 1, 2, 4, 8, 16… ➢ For work to be done in near future, stay within single order of magnitude i.e. range 1 – 10 ➢ Include 0 or ½ if required. ➢ Zero helps in considering trivial efforts. ➢ Remember 15x0 != 0. Multiple zero point stories can be combined to make 1- 2 points stories.
- 19. 19 Planning Poker ➢ A gamified variation of Delphi estimation where estimators are those who will do the work. ➢ Improves buy-in and team collaboration. ➢ Each estimator is given a deck of cards, each card has a valid estimate written on it (based on non-linear scale chosen) ➢ Customer/Product owner reads a story and it’s discussed briefly ➢ Each estimator selects a card that’s his or her estimate. Cards are turned over so all can see them ➢ Discuss differences (especially outliers) and re-estimate until estimates converge
- 20. 20 Planning Poker ➢ Team can also use question mark or infinity to denote high size and complexity preventing them to estimate properly i.e. need for split, spike or scope clarity. ➢ Lack of convergence after 2-3 rounds require scrum master to understand the reasoning and deal case on case basis. Often these items are parked aside. ➢ Product owner doesn’t estimate but is present to answer any queries around scope. ➢ Engineering managers also don’t estimate but support the process and sometimes provide inputs. Estimators Round 1 Round 2 Tara 3 5 Bala 8 5 Joju 2 5 Chris 5 8
- 21. 21 ➢ Velocity is sum of total estimate (in story points or ideal days) of stories which qualifies “Definition of Done” in a given sprint. ➢ Example: Team signed up 5 stories of 3 points each (15 USP); 4 stories got DONE and 1 is incomplete then velocity is 12 USP). ➢ This helps in creating forecasts and planning for next sprints. ➢ Schedule = (Total number of story points / velocity)*Iteration length ➢ Velocity gets stabilized after running few iterations and we often take average of last 3 sprints. ➢ It corrects estimation errors and automatically factors in non-productive activities, unplanned distractions. Backlog Size Velocity Duration 200 Points Velocity = 25 200/25 = 8 Iterations Velocity
- 22. 22 Burndown and Burnup charts
- 23. 23 Appendix
- 24. 24 Estimation
- 25. 25 Determining Velocity Good to have historic values but as every project & team is unique, these have limited value Use Historic Values Ideal way if feasible. After each iteration the range of possible velocity figures will converge Run an Iteration Estimate based on team’s capacity Make Forecast Velocity is not just a number but a range of optimistic and pessimistic scenarios.
- 26. 26 Velocity Forecast – Determine Team capacity Person Hours Available per iteration Tom 32 – 40 Harry 36 – 40 Rita 20 – 28 Han 16 – 22 Total Hours 104 – 130 Calculate Team’s capacity – An example 104 – 130 hrs effort available
- 27. 27 Velocity Forecast – Raw velocity exercise Story Story Points As user.. Search 2 As admin... Add 5 As visitor .. Inquire 3 As admin .. clone 5 104 – 130 hrs effort available Task Hrs Design 6 Code 12 Test 8 Total 26 Task Hrs Design 10 Code 12 Test 12 Document 10 Automate 8 Total 52 Task Hrs Design 10 Code 14 Test 12 Total 36 Task Hrs … … Total 54 Backlog Effort = 26+52+36 = 114 Velocity= 2+5+3=10
- 28. 28