Designing Software

Estimates
June 18, 2020
Daniel Vu
  A software estimate should account for…
 What is going to be done
 When is it going to be done

What is a
software
 ”Good” estimates generally also include…
 How confident we are in meeting it

estimate? 

Clarity on what is “not” getting done
Milestones to track progress
 Ability to get feedback along the way
 Waterfall vs Agile
  Software Engineer
 Consult with stakeholders on current functionality
and complexity of adding features

Software  Sr Software Engineer

 Estimate effort for current and future projects of

Engineering small to medium scope

 Engineering Manager
Track Roles  Direct the project team in estimation, analyzing,
coding, debugging, testing, and modifying software
  Establishes realistic standards
 Stakeholders know what they are getting and when
Why are they are getting it
 Dev teams get to protect their time and health

estimates  Builds trust

 Good to have a track history of delivering for
important? stakeholders
 Good to know you can rely on your teammates
  Not enough thought put into them
 The pressure to start developing and deliver value
immediately is high
 Too much going off of “gut”
Why do so  Uncertainties / Unknowns

many
 Unknowns can completely throw off an estimate if
it’s large enough

estimates  Past experience biases

 We always assume that because we built X in a

fail? certain number of days, we can build Y in a

proportional amount of days

 Stakeholder Pressure
 People always want it done now
Strategies
  Teammates may see unknowns or alternative

Consult your solutions that you weren’t aware of

 People who spend more time in the codebase can
team provide more accurate estimates
Break it down to
smaller tasks

 It’s almost impossible to

accurately estimate large
projects
 People are more accurate at
gauging how long a small task
will take
 Sum up the time for all the
tasks
  Get rid of enough uncertainty
 Build POC’s, look at what the code base is already
Do Research doing

/ Spikes  Timebox your research

 You can spend eternity creating the “perfect”
estimate; learn when the estimate is “good enough”.
  Always ask about the scope
 What are the edge cases

Ask 

What are the future plans for the project
What is the current health of the code base

questions 

What resources / technologies should / can I use
Who can help
  People always say ”it’s going to be done in X
days”
Provide  Instead, try saying “it’s going to take X to Y days”
Estimate  The wideness of the range is indicative of how
“confident” you are

“Ranges”  Consider 1-4 weeks vs 3-4 weeks, what do those

ranges say?
  Sounds silly but it’s important because no one
gets a “100% productive day”
 Meetings
 Support
 Learning

 Estimates should* reflect the team’s realistic

velocity on an average day, not just “heads down

“Padding” time”
 * Depending on who is asking for the estimate. For
stakeholders, never give estimates for “heads down
time”. For teammates, sometimes it’s helpful to
know how much focus time you need

 Don’t go crazy on this; always be ready to defend

your estimates
Communicating the
Estimates
  From the Pragmatic Programmer

What to say You say ”I’ll get back to you”. You almost always get
when asked better results if you down the process down and
spend some time…

for an … Estimates given at the coffee machine will come

back to haunt you.
estimate
Acknowledge the Costs
Something always has to give
  People always want it now

Know what’s  People don’t always know the difference between

“it will take 2 weeks of time to complete” and “it

happening will be done in 2 weeks”

 We’re always working on multiple projects

around you  Be careful what you promise at any moment

 Always doing reprioritizing projects
  Who is listening?
 Stakeholders
 Project Manager
 Technical Leads
 Senior Developers
 Team Members

Tailor your  How literal is someone going to take your estimate

 Me? The team lead? Probably understanding and
estimates flexible
 Stakeholder? Probably stricter

 Know who is the audience of your audience

 Everything goes up the chain
 People don’t convey the nuances that you are going
to convey on your initial presentation
  “In preparing for battle, I have always found that
plans are useless, but planning is indispensable.”
-Dwight D. Eisenhower

Estimate  Be ready to throw away your plans, software

Often estimates rarely go perfectly
 Replan, readjust, and recommunicate
 Retrospect
Done!