ATLANTA PHP USER GROUP
• Director of
• 5+ years of full-time
• Learned estimation
from the school of
A good estimation approach should
provide estimates that are within 25%
of the actual results 75% of the time.
Conte, Dunsmore, and Shen (1986)
Sadly, people asking for control or
visibility really want certainty.
Which doesn’t exist.
Target: a stated desirable business
Commitment: a promise to deliver a
specific product within a timeframe
A good estimate is an estimate that
provides a clear enough view of the
project reality to allow the project
leadership to make good decisions
about how to control the project to hit
Steve McConnell, Software Estimation
HEAVIEST BLUE WHALE EVER RECORDED
“It always takes longer than you
expect, even when you take into
account Hofstadter’s Law.”
Gödel, Escher, Bach: An Eternal Golden Braid
“With software estimation you've only
realistically got a choice of 5 mins, 1
hour, 1-2 days, about a week, and then
all bets are off.”
WHY ARE ESTIMATES
IT’LL BE DIFFERENT
THE PLANNING FALLACY
Students estimated their senior thesis
completion time in a 1994 study:
If there’s as much chance of you
coming up with something meaningful
by rolling some dice or rubbing the
estimate goat then what purpose are
you satisfying by doing so?
CONE OF UNCERTAINTY
• Inflated prices – might lose the job
• Lack of urgency – project time fills
up the estimate when it could have
been done faster
• Inadequate planning
• Missed deadlines
• Overwork, burnout
• More bugs
• Technical debt
• Damage control
• Unplanned interim releases
• Meetings proliferate
BIG TEAMS ARE
1 0 100% 1x
2 3 75% 1.5x
3 6 67% 2x
4 10 63% 2.5x
5 15 60% 3x
6 21 58% 3.5x
7 28 57% 4x
8 36 56% 4.5x
9 45 56% 5x
10 55 55% 5.5x
Source: Paul M. Jones, http://paul-m-jones.com/archives/1591
COUNT ALL THE
“With software estimation you've only
realistically got a choice of 5 mins, 1
hour, 1-2 days, about a week, and then
all bets are off.”
1. List all the features
2. Break the features into sub-
3. Break the sub-features into
4. Estimate the components
5. Add the estimates up
LAW OF LARGE NUMBERS
The tendency for errors on the high
side and errors on the low side to
cancel each other out.
The accuracy of the sum is greater
than the accuracy of the individual
PAUL JONES’ METHOD
1. List all the controllers required for
2. List all the methods required for
3. Estimate 1 dev-pair day per
1. List all the logical features required
2. Break down each feature into small
3. List all the pages and modals required for
4. Estimate the back-end time required for
each logical component
5. Estimate the front-end time required for
6. Sum up the back-end and front-end totals
WHEN IN A
PINCH, USE A
1. Assign a size classification to each
2. Compute the average time required
for similarly-sized features from
actual past projects
3. Create estimate ranges for each
feature based on past performance
4. Sum the result
• Less accurate
• Requires collection and archival of
project historical data on a per-
• Uses a point scale: 1, 2, 4, 8, 16
• Break down the project into epics and
• Assign a point value to each story
• Schedule releases at regular intervals
• The number of points completed per
release is known as “velocity”
• Use the velocity to plan and estimate
the delivery dates for future releases
• 27 story points delivered
• 12 staff weeks expended over 3 calendar weeks
• Effort = 27 points / 12 weeks = 2.25 points/week
• Schedule = 27 points / 3 weeks = 9 points/week
Iteration 2 projection
• 33 story points scheduled
• Effort = 33 points / 2.25 points/week = 15 staff weeks
• Schedule = 33 points / 9 points/week = 4 calendar weeks
• Assign a T-shirt size for development cost
• Assign a T-shirt size for business value
• Create a table of business value to
development cost ratios
• Look up the net business value for each
feature based on the dev cost and
business value T-shirt sizes
• Prioritize the features in order of net
Feature Business Value Dev Cost
Feature A L S
Feature B S L
Feature C L L
Feature D M M
Feature E M L
VALUE TO COST RATIOS
XL L M S
XL 0 4 6 7
L -4 0 2 3
M -6 -2 0 1
S -7 -3 -1 0
BIZ VALUE EXAMPLE
Dev Cost Net Value
Feature A L S 3
Feature C L L 0
Feature D M M 0
Feature E M L -2
Feature B S L -3
When the estimate and target conflict:
• Negotiate features
• Negotiate time
• Negotiate price
• Try to be helpful, offer solutions
• Be creative
• Examine what can be done in
parallel to save time
• Be firm – you can’t change the laws
A HORROR STORY
ONE FINAL WORD
• Former employer of mine
• Start-up, naïve and inexperienced
• Needed cash bad
• Local company in Atlanta
• Had four separate systems in place
for managing customer data, billing,
inventory, and fulfillment
• Wanted this unified and streamlined
into a web-based backoffice
• Wanted a customer-facing portal for
online ordering and bill paying
• Estimated at 1,039 man-hours
• Normal hourly rate was $120/hr
• We did a fixed-bid for $50k, at an
effective hourly rate of $48/hr
• 18 months later…
• 2,500 man-hours
• 1,500+ Subversion commits
• Lots of “unknown
complexities, and scope creep
• Don’t succumb to pressure to be
optimistic when estimating
• Use a good estimation methodology
• Try not to do fixed bidding
• Always have a thorough scope
Hello! I’m Jonathon Hill, been in the industry full time for
Brandmovers is a digital brand marketing companyOur clients are household names – names like Disney, Kohl’s, and Dr PepperProjects vary from small to very largeCurrently hiring a mid-level PHP and front-end developer
This is you. You’re peacefully composing code into a profoundly elegant masterpiece, or maybe you’re just staring at your desk, when…
suddenly this guy shows up. He’s got this big idea that he’s pitching to some VCs.You get the30 secondelevator pitch, and then he says,“I’m gonna need you to go ahead and give me an estimate on that so I can set a budget, and be sure to go ahead and use the new coversheet, mmkay?”
Your answer?How you answer this question is extremely important.
Judging by the number of people that think that “estimate” and “quote” are synonymous, I think there is a lot of misunderstanding on what an estimate actually is.There is nothing at all binding in an estimate, it is more like a measurement.
An estimate is simply a “tentative evaluation or rough calculation”.Even a good estimate (by the textbook definition) has a 25% chance of falling short.Would you buy a car that had a 1-in-4 chance of not starting when you try to crank it?If even the best estimation process has a 25% uncertainty, and you allow estimates to be confused for commitments, then from management’s perspective, or the client’s perspective, you’re just like that car – unreliable.
Dan North sez…
Targets:“We need v2.1 ready to demo at a trade show in May.”“Our budget is $2mm, we must limit the cost of the next release to that budget.”
Here’s the problem: estimates and targets often collide. Good estimates are probability statements based on what is known about the project and available resources, and targets are specific business objects that are sometimes quite solid.At Brandmovers, if we’re building a promotion to help generate buzz and excitement for the next Avengers movie, and that movie launches on a particular date, it isn’t really an option to delay launching the promotion if the project runs over.So if an estimate isn’t a promise, what is a good estimate?
To illustrate the point, I’d like to do a little exercise.
I’d like you to estimate the weight, in pounds, of the heaviest blue whale ever recorded.No cheating, don’t Google it.Give a high and a low estimate.Here’s the catch: I want you to estimate this with a wide enough range so that you are 90% confident that the correct answer is in the range that you set.You’ve got one minute. Go.
Now, I’d like to get a show of hands of how many of you captured the correct answer in your range.Almost everyone gets this wrong.
You might be thinking, “c’mon, this is not a realistic exercise.”Folks, estimating in the face of this kind of uncertainty is business as usual for software estimators. Fortunately, there are techniques that will help you get within 25% of the actual number 75% of the time.The other takeaway here is unless you are into statistics and you have have a mathematical reason for saying so, don’t use terms like “90% confident” or “75% confident.”
Before we go any further, I’d like to share a book recommendation.The exercise we just did comes from chapter 2 of the bookSoftware Estimation, by Steve McConnell.Steve is a former Microsoft employee and also authored the book Code Complete.Software Estimation is pretty much required reading for anyone who is responsible for estimating software projects. This book really helped me to understand why good estimation practices work, and what I had been doing wrong for years before.
Hofstadter’s Law illustrates why estimation is so hard, and why so many people get it wrong.In fact, the difficulties with producing even a ballpark estimate and the the tendency to misunderstand and abuse estimation have led some to seek workflows which eliminate estimation altogether. Some agile methodologies do this.Sadly, the dynamics and business models of many companies do not allow such a luxury.
Optimism bias is when you believe you are safer from a negative event than others.It’s the idea that you can “beat the odds” or it “won’t happen here because” you are somehow immune to the problems that others have faced.
Similarly, the planning fallacy says,“It’ll be different this time!”
Only 30% of the students completed their thesis in the time they estimated.The remarkable finding from this study is just how far off the mark these students were in their estimates – the average actual thesis completion time was longer than even the average worst-case estimate.Think about the implications of this on your own projects.What would happen if 3 out of 4 of your projects took longer than even your worst-case estimate?
A “black swan” is a rare, unpredictable, high-impact event that in retrospect seems not so improbable.While it is true that it is hard to account for a black swan event in your estimates, my real point in bringing this up is to talk about how unknowns make it almost impossible sometimes to produce a useful estimate.Secretary of Defense Donald Rumsfeld is famous for saying,“There are known knowns; there are things we know that we know.There are known unknowns; that is to say, there are things that we now know we don't know.But there are also unknown unknowns – there are things we do not know we don't know.”It’s the unknown unknowns that really get you.
Provide an estimate, even a range, when you don’t have enough information is worse than useless, they can actually hurt your business.
Rob goes on to say,“What’s the least worst situation to be in?Having an uncomfortable situation with your boss now or when – based on your estimates – the project’s half a million over budget and 6 months late?”
The cone of uncertainty shows how error-prone early estimates are. The lines of the cone outline the best case accuracy you could have in various stages of the project; the blue cloud of uncertainty shows what the variability actually looks like in practice.The cone doesn’t narrow itself over time, you have to narrow it by making decisions and defining the specifications.Early in the process, few decisions have been made about the project, so the variability in the project time/cost is very wide.It’s similar to asking a builder to give you a cost estimate on building a building without telling him whether it’s a doghouse or a skyscraper, or something in between. If the builder is smart, he’ll ask some questions before putting pen to paper.Avoid estimation prior to completion of the project requirements, and plan to re-estimate as soon as the user interface design is complete.
Typical business concerns about over-estimating a project include things like…
However, the consequences and costs of underestimating are vastly higher than the cost of overestimating.These include…
Let’s say you’re a freelancer, and you get a project. You know everything there is to know about the project, and as such, you have the ability to work at 100% of your capacity on the project.
Calculating the time required to complete the project is a simple matter of dividing your estimate by the amount of time per day or week that you can devote to the project.
One day, you get a project that you’ve estimated out at somewhere between 3-4 months of development time. However, your client has a target completion timeframe of only 6 weeks. What do you do?
Being the smart businessman that you are, you get help. Your buddy is available to help and you offer to split the costs with him.Great! You get get the project done in 1.5-2 months, since you’ve doubled the capacity to work on the project, right?Wrong.It’s because you’ve now introduced communication overhead between the two of you.
It gets worse, the more people you add.
The communication overhead grows at an exponential rate.
The actual numbers may be higher or lower, this is a hypothetical model to illustrate my point.
It is best to use the largest units and the fewest significant digits as possible.Match the way you present your estimate to accurately reflect how probable your estimate is, and to communicate to all project stakeholders that this is an estimate that has a certain amount of variability to it.
We’ve talked about a lot of theory, what estimates are, what they’re good for.Now let’s talk about some practical methodology.
Remember what Rob Bowley said?
This is the underlying idea behind estimation by decomposition.Essentially, you break down the project features, and then you break down those sub-features down even further to the individual components that must be built.Estimate each component, and sum the individual estimates to produce the overall estimate.
There are a few different ways to do this. The first way was pretty hard for me to swallow at first.I learned it from Paul Jones and in practice it works very well.This method includes front-end, back-end, and QA time built in and was created based on his personal observations from working on many different projects.Notice the large unit of measure (1 day), and the fact that it assumes two people will be pair programming.I never understood why this method worked so well until I learned about the law of large numbers.Simple methods are often quite effective! It doesn’t take complex mathematics or estimation modeling software to produce a useful estimate. A spreadsheet and a good method are all you need.
To estimate, use multiples of 4 or powers of 2.Rules of thumb:Small features = 2hMedium features = 4hLarge features = 8hVery large features = 16hAnything larger than 16h needs to be broken down further.For pages:Layouts = 8hPages with different layout = 4hPages with same layout = 2hModals = 2-4hDouble or triple front-end time for responsive design or mobile optimization.
Comes from Agile
Pivotal Tracker calculates velocity and divides the upcoming stories into various releases based on the stories’ point values, your velocity, and the length of your iterations.
This is not a true estimation method, but it is useful when all you need to do is figure out what order to build the features in, and what features don’t make business sense to build.
When targets and estimates collide, what do you do?
I.e. the target is usually negotiable, but an estimate cannot be negotiated.
Attitude is everything, as my granddaddy used to say.