Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to Make Great Software Estimates

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

How to Make Great Software Estimates

  2. 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. 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. 4. START? Two questions with two answers where one does not necessarily answer the other. WHERE DO WE
  5. 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. 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. 7. Experience starts the process of asking yourself these questions with each problem.
  8. 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. software-estimation-experience/
  9. 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. 10. What do I know that I can leverage in this estimate?
  11. 11. KnowledgeThe culmination of everything we know applied to what we know about the problem and our experience. knowledge/
  12. 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. 13. Never start coding if you do not understand what you are trying to code.
  14. 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. understand-the-problem/
  15. 15. When will We ship?
  16. 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. 17. JANUARY 2015SO When will it be ready?
  18. 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.
  19. 19. And what should younot apply to an estimate?
  20. 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. 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. 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. 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. 24. Good estimates Will tell you howlong andwhen you will deliver Bad estimates Will give younothing
  25. 25. T h e e n d Greg Thomas

    Be the first to comment

    Login to see the comments

  • Pimpona77

    Jan. 5, 2016
  • RicardoAugusto48

    Mar. 9, 2016
  • VolodymyrKochergin

    Mar. 30, 2016
  • vershatrivedi

    Apr. 12, 2016
  • Nikolos92

    May. 17, 2016
  • phpfour

    May. 28, 2016
  • vishalvkorgaonkar

    Jun. 2, 2016
  • DavidFirester1

    Jun. 23, 2016
  • JoaoPedro419

    Jul. 2, 2016
  • PetrosMarkidis

    Oct. 22, 2016
  • HeathDutton

    Oct. 27, 2016
  • jamesdessin1

    Jan. 6, 2017
  • TabarekAyad

    Mar. 23, 2017
  • NicolleAlonso1

    May. 17, 2017
  • MrunaliDhangar

    Aug. 2, 2017
  • FranciaFranco3

    Sep. 12, 2017
  • LynsieOverton

    Apr. 10, 2018
  • KrzysiekKondracki

    Jul. 18, 2018
  • HerwigAmlacher

    Nov. 29, 2019
  • anuragprasoon

    Sep. 16, 2020

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


Total views


On Slideshare


From embeds


Number of embeds