Estimates or #NoEstimates by Enes Pelko
1 like693 views
The document discusses the challenges and methodologies related to project estimation in software development, highlighting the issues of relying on estimates that often become commitments despite changing requirements. It introduces the #noestimates approach as a viable alternative to traditional estimation practices, advocating for agile principles that focus on delivering value and responding to real constraints rather than on estimating time and costs. Key topics include various estimation methods, common pitfalls, and advice for better estimating practices, ultimately calling for a shift in how teams approach project management.
![#NOESTIMATES
• #NoEstimates is a hashtag for the topic of exploring alternatives to
estimates [of time, effort, cost] for making decisions in software
development. That is, ways to make decisions with “No Estimates”.
• It is not a complete methodology in traditional sense but rather set of
ideas given by different people.](https://image.slidesharecdn.com/noestimates-enespelko-151020023718-lva1-app6891/85/Estimates-or-NoEstimates-by-Enes-Pelko-22-320.jpg)
Estimates or #NoEstimates by Enes Pelko
- 3. ENES PELKO • At Authority Partners since 2006 • Currently in the role of Solutions Architect • Primarily backend developer working on SOA platforms • Worked on products and custom software solutions projects • Besides building software I enjoy building productive teams • Enes.Pelko@AuthorityPartners.com • @EnesPelko
- 4. MOTIVATION FOR THIS TOPIC • Engineering teams give estimates at the beginning of the project, when we now least • Those estimates are then used to build a plan and they become commitments • Engineering teams are then held accountable to stand up to those estimates even though requirements change • End result is overtime, poor quality and general dissatisfaction
- 5. MOTIVATION FOR THIS TOPIC • #NoEstimates seemed as a viable alternative • Even if I can’t take it as is maybe some practices are worth using
- 6. WHAT IS AN ESTIMATE • An approximate calculation or judgment of the value, number, quantity, or extent of something • In software development estimates are often used to attempt to predict the future • WAG – Wild assed guess
- 7. WHY DO WE NEED AN ESTIMATE? • “I don't buy a product unless I know what the purchase will cost.“ • Making decisions about the project/product • Should we even start a project? • Is this feature worth doing? • Prioritization of backlog. • Other business decisions • Budgeting • Project portfolio planning • Staffing and recruiting
- 8. ESTIMATION METHODS • Expert Judgment Method • Estimating by Analogy • Top-Down and Bottom-Up Methods • Algorithmic Method
- 9. EXPERT JUDGMENT METHOD • Pros • The experts can factor in differences between past project experience and requirements of the proposed project. • The experts can factor in project impacts caused by new technologies, architectures, applications and languages involved in the future project and can also factor in exceptional personnel characteristics and interactions, etc. • Cons • Expert may be some biased, optimistic, and pessimistic, even though they have been decreased by the group consensus. • The expert judgment method always compliments the other cost estimating methods such as algorithmic method. • Depends on expertise of expert • It is hard to document the factors used by the experts or experts-group.
- 10. ESTIMATING BY ANALOGY • Pros • The estimation are based on actual project characteristic data. • The estimator's past experience and knowledge can be used which is not easy to be quantified. • The differences between the completed and the proposed project can be identified and impacts estimated. • Cons • Depends on how good we did we described projects. • Even once we have characterized the project, we have to determine the similarity and how much confidence can we place in the analogies. • We have to derive an estimate for the new project by using known effort values from the analogous projects
- 11. TOP-DOWN ESTIMATING METHOD • Pros • It focuses on system-level activities such as integration, documentation, configuration management, etc., many of which may be ignored in other estimating methods and it will not miss the cost of system-level functions. • It requires minimal project detail, and it is usually faster, easier to implement. • Cons • It often does not identify difficult low-level problems that are likely to escalate costs and sometime tends to overlook low-level components. • It provides no detailed basis for justifying decisions or estimates.
- 12. BOTTOM-UP ESTIMATING METHOD • Pros • It permits the software group to handle an estimate in an almost traditional fashion and to handle estimate components for which the group has a feel. • It is more stable because the estimation errors in the various components have a chance to balance out. • Cons • It may overlook many of the system-level costs (integration, configuration management, quality assurance, etc.) associated with software development. • It may be inaccurate because the necessary information may not available in the early phase. • It tends to be more time-consuming. • It may not be feasible when either time and personnel are limited.
- 13. ALGORITHMIC METHOD • Pros • It is able to generate repeatable estimations. • It is easy to modify input data, refine and customize formulas. • It is efficient and able to support a family of estimations or a sensitivity analysis. • It is objectively calibrated to previous experience. • Cons • It is unable to deal with exceptional conditions, such as exceptional personnel in any software cost estimating exercises, exceptional teamwork, and an exceptional match between skill-levels and tasks. • Poor sizing inputs and inaccurate cost driver rating will result in inaccurate estimation. • Some experience and factors can not be easily quantified.
- 14. COST ESTIMATING IN CONSTRUCTION INDUSTRY • Similar Projects • Material Costs • Wage Rates • Site Conditions • Inflation Factor • Bid Timing • Project Schedule • Quality of Plans & Specifications • Reputation of Engineer • Granting Agency • Regulatory Requirements • Insurance Requirements • Size of Project • Location of Work Site • Value Engineering • Contingency • Supplemental Studies & Investigations • Judgement
- 15. MY ISSUES WITH ESTIMATION • Relies on gut feeling/expertise. • Peopleware • There are no norms in writing code • Value of Line of Code • What is the cost of Line of Code
- 16. PSYCHOLOGICAL ISSUES • Factors that have been demonstrated to be important are: • Wishful thinking • Anchoring • Planning fallacy • Cognitive dissonance. • It's easy to estimate what you know. • It's hard to estimate what you know you don't know. (known unknowns) • It's very hard to estimate things that you don't know you don't know. (unknown unknowns)
- 17. USUAL MISTAKES WITH ESTIMATES • Unclear definition of done making estimate count only partial effort • Giving and me an estimate for “it” before anyone knows what “it” is • Asking for an ESTIMATE with vary limited info then keeping the team committed to it even with changed requirements • Doing estimates for someone else or accepting an estimate from someone based on it’s reputation • Arguing that developers are making padding in estimates
- 18. DEADLY SINS OF ESTIMATION • Confusing targets with estimates • Saying “yes” when you really mean “no” • Committing to estimates too early in the cone of uncertainty • Assuming underestimation has no impact on project results • Estimating in the “impossible zone” • Overestimating savings from new tools or methods • Using only one estimation technique • Not using estimation software • Not including risk impacts in estimates • Providing off-the-cuff estimates
- 19. ADVICES FOR BETTER ESTIMATING • Keep track of what was the original estimate and what it turned out to be • Do some in advance analysis and design • Break down project into components that can be normalized in effort needed • Breakdown work into smallest possible tasks – That would not work for larger projects • Count all activities in • Make padding in estimate
- 20. AT THE END WE ALWAYS OVERESTIMATE TO SAVE OURSELVES
- 22. #NOESTIMATES • #NoEstimates is a hashtag for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development. That is, ways to make decisions with “No Estimates”. • It is not a complete methodology in traditional sense but rather set of ideas given by different people.
- 23. #NOESTIMATES IN SHORT • Organizations and individuals spend a lot of time estimating • A lot of the estimates are inaccurate, or • Even when the estimates are accurate, they are ignored, therefore • The time spent creating estimates is wasted
- 24. ESTIMATES AS COMMITMENTS • Estimates that are problematic are those estimates that inadvertently or otherwise become commitment.
- 25. MOST BACKLOGS ARE WASTE • “Most backlogs are waste. Estimating backlog items is therefore super- waste. Revising backlog estimates are in mentally-deranged territory.” by Paul Kipp • So much of the backlog never gets implemented or gets so much changed over it has no correlation with original idea. • About 50% dropout ratio. • Product backlog is not list of items “we will do” it is list of items “we might do”
- 26. AGILE DOES NOT NEED ESTIMATES • Per Woody Zuill agile does not need estimates. • We ought to deliver frequently and always most valuable requirements.
- 27. DELIVER EARLY AND OFTEN • If we are delivering early and often then we can make better decision instead of estimating • Promote the culture of agility in entire organization • If marketing waits on our output to promote the project let them be agile and do in increments
- 28. REAL CONSTRAINTS • Instead of constraining on estimate constrain on deadline or budget. • Creativity comes up when you need to resolve real constraint, 20$ to feed the family for the week.
- 29. OPPORTUNITIES LOST WITH PROJECT PLAN • Saying we came on budget does not necessarily mean good thing. • Can we think it as hurray we spent all money • Is it better just doing 20% of work to get 80% of features
- 30. FOCUS ON VALUE INSTEAD OF COST • Iterative Funding • Emergent Value • Problem with concept of success on time and on budget, where is the value • Focusing on cutting costs might end up being more costly • If I am an investor and I want to know if am I going to get a result for my money • If we actually look at it from a budgetary constraint point of view and say this is how much money I’ve got, what can we do for this amount of money.
- 31. STORY COUNT AND CYCLE TIME • PBI Size is usually the same • Instead of counting Story Pints count number of PBIs • Do forecasting instead of estimating
- 32. #NOESTIMATES IN EXAMPLE • Suppose you have a $30,000 to do a kitchen remodel…
- 33. #NOESTIMATES CRITICS • Estimates are flat-out natural, ubiquitous, and unavoidable in practical life and in business; • Estimates help in project selection • Estimates provide a reference point • The root cause of poor estimation is usually lack of estimation skills. • Many comments in support of #NoEstimates demonstrate a lack of basic software estimation knowledge.
- 34. www.agile.ba #NOESTIMATES, IS IT FOR ME?
- 35. CONTEXT MATTERS • Product vs. Project • Research project with a lot of unknowns vs standard line of business app • Type of work - Bug vs. User Story • Type of client/contract
- 36. DISTINCT BETWEEN ESTIMATES, TARGETS AND COMMITMENTS. • Estimates are given and owned by the implementation team. • Targets are set by the business. • Commitments are made and owned together.
- 37. BE AGILE • Focus on value instead of cost • Deliver often
- 38. FINALLY • I will have to get better in estimating. • Use estimate when appropriately • Providing accurate estimates help building a trust • Estimates and Realistic commitments promote efficiency
- 39. EXPLORE MORE • #NoEstimates • Prominent names Woody Zuill, Vasco Duarte, Neil Killick, … • Steve McConnell vs. Ron Jeffries debate • http://www.noestimates.org