Do we need estimates? Are the estimates abused so much that they became unusable? There is a new emerging movement behind #NoEstimates that thinks so. But is it for anyone and in any situation?

1. ESTIMATES OR
#NOESTIMATES

2. CONFERENCE SPONSORS
PLATINUM
GOLD
SILVER
BRONZE

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

21. www.agile.ba
#NOESTIMATES

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

40. www.agile.ba
QUESTIONS? COMMENTS? CONCERNS?

41. www.agile.ba
THANK YOU!