ESTIMATES OR

#NOESTIMATES

CONFERENCE SPONSORS

PLATINUM

GOLD

SILVER

BRONZE

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

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

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

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

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

ESTIMATION METHODS

• Expert Judgment Method

• Estimating by Analogy

• Top-Down and Bottom-Up Methods

• Algorithmic Method

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.

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

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.

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.

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.

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

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

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)

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

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

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

AT THE END WE ALWAYS OVERESTIMATE

TO SAVE OURSELVES

www.agile.ba

#NOESTIMATES

#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.

#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

ESTIMATES AS COMMITMENTS

• Estimates that are problematic are those estimates that inadvertently or

otherwise become commitment.

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”

AGILE DOES NOT NEED ESTIMATES

• Per Woody Zuill agile does not need estimates.

• We ought to deliver frequently and always most valuable requirements.

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

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.

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

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.

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

#NOESTIMATES IN EXAMPLE

• Suppose you have a $30,000 to do a kitchen remodel…

#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.

www.agile.ba

#NOESTIMATES, IS IT FOR ME?

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

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.

BE AGILE

• Focus on value instead of cost

• Deliver often

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

EXPLORE MORE

• #NoEstimates

• Prominent names Woody Zuill, Vasco Duarte, Neil Killick, …

• Steve McConnell vs. Ron Jeffries debate

• http://www.noestimates.org

www.agile.ba

QUESTIONS? COMMENTS? CONCERNS?

www.agile.ba

THANK YOU!