A brief walk-through on how developers can create Great Software Estimates that define how long it will take to code, develop and ship.

1. HOW TO MAKE GREAT
SOFTWARE ESTIMATESGreg Thomas
http://www.rambli.com

2. And it begins…How long does it take to build this widget?
When will you be done?
Do I know what am I doing?
Where do I start?
What did they ask for?
Did I think this through?
Have I missed something?
Am I as fast as Jeff?

3. estimating
These are all questions we ask ourselves when
we, as developers, are presented with a new
problem and asked to provide an estimate as to
how long it will take AND when it will be ready.

4. START?
Two questions with two
answers where one does
not necessarily answer the
other.
WHERE DO WE

5. EXPERIENCEKNOWLEDGE UNDERSTANDING
How long it will takeIt starts with looking at your experience, knowledge and gaining a keen
understanding of the problem.
It starts with 3 Core Tenants

6. Experience
• Have I ever worked on this
component?
• What language am I using?
• Do I know this language?
• Is this a hard problem?
• Do I know the platform?
• Do we have requirements?
• Is this a high-priority?
• When does it need to be done?

7. Experience starts
the process of
asking yourself
these questions
with each problem.

8. experienceThe person with the most practice in that
particular area of development will always
yield the most “near” accurate estimation as
to what needs to be done and how.
Experience grows over time and increases
with each success and failure.
You want to fail, to get better.
http://www.rambli.com/2015/10/factors-of-
software-estimation-experience/

9. Ruby on Rails
ERP
Manufacturing
CRM
Design Patterns
MySQL
.NET
SharePoint
Java
PLACEHOLDER
Communications
PHP
Knowledge• Do you know what language you
are using?
• Do you know the underlying
framework and architecture?
• Do you have Domain Knowledge
to your field?
• Do you have expertise on the
platform you are building on?

10. What do I know
that I can leverage
in this estimate?

11. KnowledgeThe culmination of everything we know applied to what we know about the
problem and our experience.
http://www.rambli.com/2015/10/factors-of-software-estimation-your-
knowledge/

12. UNDERSTAND
“I didn’t understand the
problem”
“I’m not 100% sure what
to do here”
“It should just work”
“It didn’t do this last
time”
All statements that are uttered
after you have started coding,
but failed to take the time to
understand the problem you
are trying to solve.

13. Never start coding
if you do not
understand what
you are trying to
code.

14. Understand the problem
1) Know the end user and identify what they expect
2) Learn the platform/architecture that you are building on
3) Write down your assumptions and vet them with your users, peers
and team.
There is no “should” when you Understand.
http://www.rambli.com/2015/10/factors-of-software-estimation-
understand-the-problem/

15. When will
We ship?

16. Not YETWe have only figured out how long it
will take to accomplish our task
By Understanding the Problem, leveraging
our Experience and applying our
Knowledge we have created an estimate
that we feel can stand by.
But it is not shipping time!

17. JANUARY 2015SO When
will it be
ready?

18. Your ConfidenceIs the most important component to any estimate. How confident are you in
your estimate? 75%? 80% ? 50%?
Whichever the percentage, that is your SLUSH, which is the amount
of extra time you think you might need to accomplish this task.
http://www.rambli.com/2015/11/factors-of-software-estimation-slush/

19. And what should younot
apply to an estimate?

20. 80mph
SpeedDo not build “acceleration” or “in the zone”
time to your estimates. You are only as fast
as you are going now. Building in future
“I’m gonna know it by then” numbers will
only hurt you down the road.

21. No CopyingNEVER use someone else’s estimates
as yours. You don’t have their
experience, knowledge or
understanding of the problem.
They are not yours, you are already
behind if you take them as your own.

22. No
GuessingGuessing is for the lazy – “I don’t
know, say 200 hours” – this
means nothing, this helps with
nothing, it might as well have
been 2 hours as the result will
have been the same.

23. Good Estimates are composed of
• Knowledge
• Experience
• Understanding the Problem
• Condfident Slush
Bad Estimates
• Apply Speed Factors
• Copy other People
• Guess
SO REMEMBER…

24. Good estimates
Will tell you howlong andwhen
you will deliver
Bad estimates
Will give younothing

25. T h e e n d
Greg Thomas
http://www.rambli.com