Estimates are not promises
Your gut lies
Premature estimation is sabotage
Big teams are slower than small ones
Beware unwarranted precision
Count all the things!
When in a pinch, use a proxy
You can’t negotiate math
2. BACKGROUND
• Self-taught
• 5+ years of full-time development
• Former CTO for a small web startup
• Former Director of Development for
a digital marketing agency
• AtlantaPHP Steering Committee
8. (N) ES-TIM-ATE:
An attempt to quantify something in
the face of the unknown.
By definition, estimates are imprecise
and tentative, versus
9. “GOOD” ESTIMATE
A good estimation approach should
provide estimates that are within 25%
of the actual results 75% of the time.
Conte, Dunsmore, and Shen (1986)
10. CERTAINTY
Sadly, people asking for control or
visibility really want certainty.
Which doesn’t exist.
Dan North
https://twitter.com/tastapod/status/116271851767992320
11. DISTINCTIONS
Target: a stated desirable business
objective
Commitment: a promise to deliver a
specific product within a specific
timeframe
12.
13. DEFINITION
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
targets.
Steve McConnell, Software Estimation
19. HOFSTADTER’S LAW
“It always takes longer than you
expect, even when you take into
account Hofstadter’s Law.”
Douglas Hofstadter
Gödel, Escher, Bach: An Eternal Golden Braid
23. THE PLANNING FALLACY
Students estimated their senior thesis
completion time in a 1994 study:
27.4
33.9
48.6
55.5
60
50
40
30
20
10
0
Best Case
Expected Case
Worst Case
Actual
Source: Wikipedia
24.
25. TIME FRAMES
“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.”
Rob Bowley
https://twitter.com/robbowley/status/115430969825181696
26. TIME FRAMES
Can it be done in…
• 5 minutes?
• 1 hour?
• 1-2 days?
• 1 week?
28. DEFINITION
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
targets.
Steve McConnell, Software Estimation
30. OVERESTIMATION
• Inflated prices – might lose the job
• Lack of urgency – project time fills
up the estimate when it could have
been done faster
• Procrastination
33. IS IT USEFUL?
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?
Rob Bowley
46. TIME FRAMES
Can it be done in…
• 5 minutes?
• 1 hour?
• 1-2 days?
• 1 week?
47. DECOMPOSITION AND
RECOMPOSITION
1. List all the features
2. Break the features into sub-features
3. Break the sub-features into
components
4. Estimate the components
5. Add the estimates up
48. LAW OF LARGE NUMBERS
The tendency for errors on the high
side and errors on the low side to
cancel each other out.
i.e.,
The accuracy of the sum is greater
than the accuracy of the individual
estimates.
49. PAUL JONES’ METHOD
1. List all the controllers required for
each feature
2. List all the methods required for
each controller
3. Estimate 1 dev-pair day per
controller method
50. BRANDMOVERS
METHOD
1. List all the logical features required
2. Break down each feature into small
logical components
3. List all the pages and modals required for
each feature
4. Estimate the back-end time required for
each logical component
5. Estimate the front-end time required for
each page
6. Sum up the back-end and front-end totals
53. PROXY ESTIMATION
1. Assign a size classification to each
feature
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
55. CONS
• Less accurate
• Requires collection and archival of
project historical data on a per-feature
basis
56. STORY POINTS
• Uses a point scale: 1, 2, 4, 8, 16
• Break down the project into epics and
stories
• 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
59. T-SHIRT SIZING
• 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
business value
60. EXAMPLE
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
61. VALUE TO COST RATIOS
Development Cost
XL L M S
XL 0 4 6 7
L -4 0 2 3
M -6 -2 0 1
S -7 -3 -1 0
Business Value
62. BIZ VALUE EXAMPLE
Feature Business
Value
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
65. PROBLEM SOLVING
When the estimate and target conflict:
• Negotiate features
• Negotiate time
• Negotiate price
66. ATTITUDE
• 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
of physics
69. THE SETTING
• Former employer of mine
• Start-up, naïve and inexperienced
• Needed cash bad
70. THE CLIENT
• Small company in Atlanta
• Four separate disconnected
systems
• Wanted web-based workflow
consolidation
• Wanted online ordering and
payments
71. THE ESTIMATE
• 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
72. THE FALLOUT
• 18 months later…
• 2,500 man-hours
• 1,500+ Subversion commits
• Lots of “unknown unknowns”,
hidden complexities, and scope
creep
73. THE MORAL
• Don’t succumb to optimism or
planning bias
• Use a good estimation methodology
• Try not to do fixed bidding
• Always have a thorough scope
before starting
74. ESTIMATION PROTIPS
1. Estimates are not promises
2. Your gut lies
3. Premature estimation is sabotage
4. Big teams are slower than small ones
5. Beware unwarranted precision
6. Count all the things!
7. When in a pinch, use a proxy
8. You can’t negotiate math
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?
Ever been asked for a “gut estimate?”
It’s not at all uncommon to be asked to estimate something about which you have next to no knowledge.
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 book Software 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.
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 Rob Bowley’s timeframes?
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.
Had four separate systems in place for managing customer data, billing, inventory, and fulfillment