Downloaded 63 times
Uploaded byRod Bray
When Will This Be Done?
The document provides guidance on how to effectively answer the question of project completion timelines within agile projects, contrasting agile and traditional waterfall methodologies. It emphasizes the importance of understanding estimation realities, adopting probabilistic approaches, and recognizing cognitive biases that affect planning. The document advocates for a shift in focus from specific completion dates to wiser resource management and continuous refinement of estimates based on evolving project knowledge.
![谷歌留痕技术教程[ 𝙩𝙤𝙥 𝟮𝟯𝟯. 𝙘 𝙤𝙢 ]](https://cdn.slidesharecdn.com/ss_thumbnails/top233-260130173900-2eb784f9-thumbnail.jpg?width=640&height=640&fit=bounds)
When Will This Be Done?
- 1. “When Will ThisBe Done?” A Practical Guide To Answering This Question In An Agile Project © 2015 Scott Ambler + Associates scottwambler 1
- 2. About Rod Bray ©Scott Ambler + Associates 2 • Senior Consultant, Scott Ambler + Associates • 35+ years in IT • CDAI, CDAP, PMI-ACP, CSP, CSM, ICP • Rod.Bray@scottambler.com • @johnrodbray • Helping to create Agile and Lean enterprises around the world
- 3. Before We Start •That question is really based upon a “Waterfall” mindset – Value is only delivered at the end; when all the activities are complete – Value is seen as binary; requirements (as specified) are complete • Agile projects deliver value in a different manner • Suggest a different question – Are we spending our time (and money) wisely? • What do we need to know to properly plan? © 2015 Scott Ambler + Associates johnrodbray 3
- 4. Value Curve fora “Traditional” Project Value Time © 2015 Scott Ambler + Associates johnrodbray 4
- 5. Learning Curve fora “Traditional” Project Learning Time © 2015 Scott Ambler + Associates johnrodbray 5
- 6. Learning Curve foran Agile Project © 2015 Scott Ambler + Associates johnrodbray 6 Learning Time
- 7. Value Curve foran Agile Project Value Time © 2015 Scott Ambler + Associates johnrodbray 7 Trim features to deliver on a date Delay release to get more features
- 8. Our Discussion Today •Reasons for the Question • Planning Fallacy • Realities of Estimation • Strategies for Estimating • Probabilistic Approaches • So How Do I Answer? © 2015 Scott Ambler + Associates johnrodbray 8
- 9. Reasons for theQuestion • Forecasts & estimates are used to choose between multiple options – Planning, hiring and training staff for the future – Portfolio Prioritization – Ruling out an option • Some contexts do NOT require an answer to this question – If there are no choices then there is no reason for estimates and forecasts – E.g. the project has been selected and the cost is fixed there is little reason to estimate, just start the work NOTE - Use the least precision that supports decision making i.e. We don’t measure distance between towns in feet © 2015 Scott Ambler + Associates johnrodbray 9
- 10. Really, It’s TwoQuestions The question asked before (or just as) the project is started The question asked after several Iterations (or weeks if using Lean/Kanban) Beware the Semmelweis Reflex; A professional (and general psychological) reflex to reject new evidence that threatens established norms or firmly held beliefs. – Named for a doctor preceding Louis Pasteur and his theories regarding germs An often established norm is the preference for wrong information rather than no information or delayed information. – “What do you mean that you can’t tell me when this will be finished?” © 2015 Scott Ambler + Associates johnrodbray 10
- 11. Why Plans Fail •We don’t live in a deterministic world - especially in regards to software projects. – Stochastic reality • We fall prey to a set of cognitive biases that make us believe that we can create a plan and use that to guide projects. – Wikipedia currently lists over 110 different cognitive biases • Hofstadter’s Law – It always takes longer than you thing; even when taking into account Hofstadter’s Law • Planning fallacy – We invite 3 of our friends to join us at a restaurant that is unfamiliar to all of us. We make plans to meet in front of the restaurant and get seated once everyone has arrived. – 16 possible outcomes, only 1 has everyone arriving at the same time. – 1 in 2 𝑛 © 2015 Scott Ambler + Associates johnrodbray 11
- 12. Realities of Estimation •Estimates are guesses – “guesstimate” is a more appropriate word than estimate”. • Scope on IT projects is a moving target. • Guesstimates are probability distributions. © 2015 Scott Ambler + Associates johnrodbray 12
- 13. Realities of Estimation •Guesstimates must reflect the quality of the inputs. – If scope is fuzzy, guesstimate based on that scope needs to be equally fuzzy. • Guesstimates anchor perception. – Tell them that it’s going to be between $750,000 and $1,750,000 and most people will fixate on the cost of $750,000. © 2015 Scott Ambler + Associates johnrodbray 13
- 14. Realities of Estimation •It’s easier to guesstimate small things. • It’s easier to guesstimate work you’re just about to do instead of work in the distant future – Temporal bias • The people doing the work will likely give a better guesstimate. – Motivated to get the guesstimate right when they must commit to it – Have a much better idea of their abilities. © 2015 Scott Ambler + Associates johnrodbray 14
- 15. Realities of Estimation •Someone who has done the work before will give a better guesstimate than someone who hasn’t. • Guesstimates reflect the situation that you face. – Geographic distribution, regulatory environment, etc. Context counts. • Multiple guesstimates are better than a single guesstimate – Insights from several points of view © 2015 Scott Ambler + Associates johnrodbray 15
- 16. Realities of Estimation •Guesstimates should be updated over time. – As understanding of what stakeholders want improves – As understanding of how well the team works together – As technical risks are addressed • It costs money to produce a guesstimate. – Greater precision requires greater cost. – Is the value of improved decision making capability from having the guesstimate greater than the cost of creating the guesstimate? – May consider even eliminating the guesstimation effort. © 2015 Scott Ambler + Associates johnrodbray 16
- 17. Realities of Estimation •Guesstimation is far more art than science. • Formal software guesstimation schemes are little more than a scientific façade. – Examples include function point counting, feature point counting, and COCOMO II – Expensive since they require detailed requirements and design work to be performed – Provide a false sense of security © 2015 Scott Ambler + Associates johnrodbray 17
- 18. Realities of Estimation •Past history isn’t as valuable as people hope. – False foundation since context is always different – people, technologies, teams change • Beware professional guesstimators. – Break many of the rules already described above. © 2015 Scott Ambler + Associates johnrodbray 18
- 19. Summary of theRealities of Estimation When you are required to provide estimates for your software development efforts, you should take a pragmatic, light-weight approach to doing so. Consider the cost and accuracy of such estimates to use the least precision that supports decision making. © 2015 Scott Ambler + Associates johnrodbray 19
- 20. Strategies for Estimating ©Disciplined Agile Consortium 20 ?? • Educated guess by an experienced individual • Educated guess by the team • Similar sized items • Relative mass (grid) valuation • Planning poker (Wideband Delphi) • None • Function points • Cost/schedule set by the stakeholders
- 21. Changing The Conversation ©2015 Scott Ambler + Associates johnrodbray 21
- 22. Estimates Are ProbabilityDistributions © 2015 Scott Ambler + Associates johnrodbray 22
- 23. That are refinedover time © 2015 Scott Ambler + Associates johnrodbray 23
- 24. To become moreaccurate as learning increases and timeline shortens © 2015 Scott Ambler + Associates johnrodbray 24
- 25. Simple (and typical)Forecasting © 2015 Scott Ambler + Associates johnrodbray 25
- 26. Net Velocity toDetermine Real Progress © Disciplined Agile Consortium 26 • Gross velocity does not account for added scope • Net velocity reduces the gross velocity by amount of added scope in an iteration
- 27. Estimating: Ranged ReleaseBurndowns • A ranged estimate of number of iterations required to complete work • Range of uncertainty decreases as project progresses © Disciplined Agile Consortium 27
- 28. A Different View ©2015 Scott Ambler + Associates johnrodbray 28
- 29. Probabilistic Approach • Thereis NO single forecast result • Uncertainty In = Uncertainty Out • There will always be many possible results, some more likely that others • Strive for a bounded forecast – something like: – 85% likely to be sufficiently complete by August, 2017 – Need at least 2 teams – Definitely need at least $1,000,000 • Striving for a forecast with 85% certainty or more – Do not use medians or means – chance of a coin toss © 2015 Scott Ambler + Associates johnrodbray 29
- 30. Monte Carlo Simulation •The technique was first used by scientists working on the atom bomb. • Monte Carlo simulation performs risk analysis by building models of possible results by substituting a range of values—a probability distribution—for any factor that has inherent uncertainty. It then calculates results over and over, each time using a different set of random values from the probability functions. • A Monte Carlo simulation could involve thousands or tens of thousands of recalculations before it is complete. Monte Carlo simulation produces distributions of possible outcome values. • The result is a probability distribution of possible outcomes. In this way, Monte Carlo simulation provides a much more comprehensive view of what may happen. It tells you not only what could happen, but how likely it is to happen. © 2015 Scott Ambler + Associates johnrodbray 30
- 31. Burn Up withProbability via Monte Carlo Simulation © 2015 Scott Ambler + Associates johnrodbray 31
- 32. Embrace Probabilistic Realities ©2015 Scott Ambler + Associates johnrodbray 32
- 33. Comparing Models • Expertguess • Ranged guess from multiple experts • Regression forecast • Probabilistic forecast • “All models are wrong. Some are useful.” – George E. P. Box • Just has to be better than what is currently used and intuition alone – that’s a very low bar. © 2015 Scott Ambler + Associates johnrodbray 33
- 34. Summary 1. Consider changingthe question – How will we spend money wisely? – What do we need to know to plan? 2. Context counts – Use the least precision to support decision making – What is known/unknown about scope and approach 3. Present the realities regarding estimates – We live in an uncertain world 4. Never give single values – Always use ranges 5. Present the probabilities – Not a normal distribution (Weibull most applicable) – Do not use means (or medians) © 2015 Scott Ambler + Associates johnrodbray 34
- 35. Thank You! rod.bray@scottambler.com Twitter: johnrodbray DisciplinedAgileDelivery.com ScottAmbler.com ©2015 Scott Ambler + Associates johnrodbray 35
Editor's Notes
- #13 Estimates are guesses. Look up the word in the dictionary – An estimate is a rough approximation or calculation, in other words a guess. Unfortunately, too many people think that estimates are promises, or worse yet guarantees. In our opinion “guesstimate” is a far more appropriate word than “estimate”. Scope on IT projects is a moving target. Our stakeholders struggle to tell us what they want and even when they do they change their minds anyway. Any guesstimate based on varying scope must also vary in kind. Guesstimates are probability distributions. More on this later.
- #14 Guesstimates must reflect the quality of the inputs. A guesstimate needs to reflect the quality of the information going into it – if your scope is fuzzy your guesstimate based on that scope needs to be equally fuzzy. Sometimes stakeholders want a guesstimate with a tight range, perhaps +/- 10%, early in a project. To provide a tight range such as this you need to have a very good understanding of the requirements and the design. Early in the software development process this can only be done through more detailed modeling, an expensive and risky proposition which often proves to be a wasted effort because the requirements will evolve over time anyway. Guesstimates anchor perception. The primary danger of providing guesstimates to people is that they believe them. Tell someone that it’s going to be $1,000,000 and they fixate on that cost even while they are changing their minds. Tell them that it’s going to be between $750,000 and $1,750,000 and most people will fixate on the cost of $750,000. Some people will focus on the average cost of $1,250,000 even though the median was $1,000,000 (guesstimates are in effect Weibull probability distributions).
- #15 It’s easier to guesstimate small things. That is obvious. It’s easier to guesstimate work you’re just about to do instead of work in the distant future. It is much easier to identify the details of work to be done right now, and thus turn a large piece of work into a collection of smaller pieces that are easier to guesstimate. In part this is because you have a much better understanding of the current situation you are working in and in part because you are more focused on the here and now. The people doing the work will likely give a better guesstimate. They are more motivated to get the guesstimate right, particularly when they must commit to it, and have a much better idea of their abilities. Granted, someone may need to coach people through the guesstimation effort. In Disciplined Agile this is a responsibility of the team lead.
- #16 Someone who has done the work before will give a better guesstimate than someone who hasn’t. Experience counts. Guesstimates reflect the situation that you face. Which organizational situation do you think will result in a short schedule and lower cost: Five people co-located in a single room or the same five people working from different locations in difficult time zones? Or how about a team working under regulatory constraints versus the same team without those constraints? Context counts. Multiple guesstimates are better than a single guesstimate. Getting guesstimates from several people provides insights from several points of view, hopefully prompting an intelligent conversation that enables you to develop a guesstimate with better confidence. Similarly, the same person producing guesstimates for the same piece of work using different guesstimation strategies will also provide a range of answers that you can combine.
- #17 Guesstimates should be updated over time. As your understanding of what stakeholders want improves, and your understanding of how well your team works together, you should update your guesstimates. As your understanding of the fundamental inputs into your estimate improves you are able to produce a better estimate, thus enabling the stakeholders of that guesstimate to make better decisions. It costs money to produce a guesstimate. The precision of an estimate is driven by the detail and stability of the information going into it. Want a tighter range on your estimate? Then you’re going to have to have a better handle on the requirements, design, and capabilities of the team doing the work. This greater precision requires greater cost. The fundamental question posed by the #NoEstimates community is effectively “Is the value of improved decision making capability from having the guesstimate greater than the cost of creating the guesstimate?” The implication is that you must ensure the cost is much less than the benefit, hence their focus on finding ways to streamline and even eliminate the guesstimation effort.
- #18 Guesstimation is far more art than science. See point #1 about estimates being guesses. The best guesstimates are done by the people doing the work, just before they need to do the work, for small pieces of work. Formal software guesstimation schemes are little more than a scientific façade. Function point counting, feature point counting, and COCOMO II are all examples of formal strategies. They boil down to generating numeric guesses from your detailed requirements and design, plugging these guesses into an algorithm which then produces a guesstimate. These are all expensive strategies (they require detailed requirements and design work to be performed) that prove to be risky (because they often force you into a waterfall approach) in practice. Yes, they do in fact work to some extent, but in practice there are much less expensive and less risky strategies to choose from. People like these type of guesstimation strategies because they provide a false sense of security due to their complexity and cost.
- #19 Past history isn’t as valuable as people hope. Some formal guesstimation strategies are based on past history, but this proves to be a false foundation from which to build upon for several reasons. First, people have different levels of capability which change over time as they learn. Capers Jones has shown that developers have productivity ranges of 1 to 25, the implication being that if you don’t know exactly who is on a team and how well they work together your corporate history will be questionable. Second, technologies evolve quickly so past history from working with older versions of technologies or completely different technologies becomes questionable at best. Third, people and teams change (hopefully for the better) over time, implying that an input into your guesstimate is fuzzy at best. Fourth, because every team is unique and faces a unique situation basing estimates on past history from other teams in different situations proves questionable. Beware professional guesstimators. They tend to break many of the rules we’ve described above.
- #21 Big Ideas: Best option is an educated guess Worst option is cost/schedule being set by stakeholders Timing – 3 min
- #27 Timing – 1 min
- #28 Timing – 1 min