{"id":319,"date":"2019-03-01T23:07:59","date_gmt":"2019-03-01T23:07:59","guid":{"rendered":"http:\/\/rainforestqa.com\/2019-03-01-how-to-estimate-a-project-timeline\/"},"modified":"2025-03-18T13:20:57","modified_gmt":"2025-03-18T13:20:57","slug":"2019-03-01-how-to-estimate-a-project-timeline","status":"publish","type":"post","link":"https:\/\/www.rainforestqa.com\/blog\/2019-03-01-how-to-estimate-a-project-timeline","title":{"rendered":"How to estimate a software project timeline"},"content":{"rendered":"<p>One of the first steps in getting a new project underway is figuring out how much time and resources you&#8217;ll need to allocate to getting the job done. But estimating these numbers can be challenging even for experienced teams. Here are some of the reasons that our engineering team think estimates are important, and the guidelines we use for making estimating project timelines a little less painful.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_83 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.rainforestqa.com\/blog\/2019-03-01-how-to-estimate-a-project-timeline\/#The_Impact_of_Project_Estimates\" >The Impact of Project Estimates<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.rainforestqa.com\/blog\/2019-03-01-how-to-estimate-a-project-timeline\/#Bad_Estimates_Are_Better_Than_No_Estimates\" >Bad Estimates Are Better Than No Estimates<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.rainforestqa.com\/blog\/2019-03-01-how-to-estimate-a-project-timeline\/#3_General_Rules_for_Better_Estimating\" >3 General Rules for Better Estimating<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.rainforestqa.com\/blog\/2019-03-01-how-to-estimate-a-project-timeline\/#How_to_Come_Up_with_a_Project_Estimate\" >How to Come Up with a Project Estimate<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"The_Impact_of_Project_Estimates\"><\/span>The Impact of Project Estimates<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>We think the point of estimating things is to force you to plan what it is you need to do to complete the task so that you will be less likely to run into unforeseen problems. This is a strategy to reduce surprises and risk, but there is a trade-off involved because it\u2019s not possible to perfectly plan &#8211; the best estimate of how long something will take can only come after you\u2019ve completed it and everything that was unknown is known.<\/p>\n<p>Given this, planning is a trade-off in time spent planning verses using that time in \u201cdoing\u201d. Generally speaking, the bigger a task the more time you should spend working out what\u2019s involved and how complex each part might be (because getting this wrong will result in bigger problems if we get parts wrong &#8211; a 3 month project with a bad assumption could cost 3 months or even more as you might need to work around the work you\u2019ve already done).<\/p>\n<p>The smaller the task the less time you need to plan what you\u2019re doing, because it\u2019s cheaper to make a mistake and because you\u2019re more likely to give a good estimate. Sometimes, just doing the task is the right thing to do, because you\u2019ll learn quicker what needs to be done &#8211; this is fine, just make sure that everyone involved knows there is potentially hidden complexity in the task.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Bad_Estimates_Are_Better_Than_No_Estimates\"><\/span>Bad Estimates Are Better Than No Estimates<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>It\u2019s also fine for estimates to be wrong, after all they are our guesses based on imperfect information, and so it\u2019s unsurprising that the unknown will mess up our day.<\/p>\n<p>You should know, we developers are <a href=\"https:\/\/en.wikipedia.org\/wiki\/Software_development_effort_estimation\" target=\"_blank\" rel=\"noopener\">bad<\/a> at estimating stuff:<\/p>\n<blockquote><p>Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. For a review of effort estimation error surveys, see.<sup><a href=\"https:\/\/en.wikipedia.org\/wiki\/Software_development_effort_estimation#cite_note-3\" target=\"_blank\" rel=\"noopener\">[3]<\/a><\/sup> However, the measurement of estimation error is problematic, see <a href=\"https:\/\/en.wikipedia.org\/wiki\/Software_development_effort_estimation#Assessing_the_accuracy_of_estimates\" target=\"_blank\" rel=\"noopener\">Assessing the accuracy of estimates<\/a>. The strong overconfidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or \u201calmost sure\u201d to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70%.<a href=\"https:\/\/en.wikipedia.org\/wiki\/Software_development_effort_estimation#cite_note-4\" target=\"_blank\" rel=\"noopener\"><sup>[4]<\/sup><\/a><\/p><\/blockquote>\n<p>If you trust everything you read in Wikipedia, this means you should almost always increase your estimate by 30%!<\/p>\n<p>The article <a href=\"https:\/\/ardalis.com\/5-laws-of-software-estimates\" target=\"_blank\" rel=\"noopener\">5 Laws of Software Estimates<\/a> has a lot of things in it that I agree with, whilst you\u2019re taking the time to read this, you should read it as well. For one thing, it has more memes in it.<\/p>\n<p>It\u2019s important to state that when it comes to estimates we\u2019re not looking for people to use mystical formulas or complicated systems (of which there are many in <a href=\"https:\/\/en.wikipedia.org\/wiki\/Software_development_effort_estimation\" target=\"_blank\" rel=\"noopener\">this Wikipedia article<\/a>) &#8211; we\u2019re looking for you to break down tasks and give a back-of-the-envelope estimate of how long they will take. This isn\u2019t rocket science people.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"3_General_Rules_for_Better_Estimating\"><\/span>3 General Rules for Better Estimating<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3>1. Write stuff down<\/h3>\n<p>Writing forces you to expose all the hidden assumptions you\u2019re making when you\u2019re thinking through things. It\u2019s much easier to spot missing\/inconsistencies when they are written down. It means that you can ask other people to check your reasoning whilst you\u2019re doing something else and you can refer back to it when you forget what it is you\u2019re supposed to be doing.<\/p>\n<h3>2. It\u2019s ok to be uncertain<\/h3>\n<p>Everything is uncertain. This is fine. Say why you\u2019re uncertain and give a range with some explanation of why you\u2019re uncertain and why you\u2019ve chosen the lower and upper bounds of the range.<\/p>\n<h3>3. Ask your peers<\/h3>\n<p>Unless you\u2019re starting a brand new project, you\u2019re going to be working around someone else\u2019s code, their input on your plan and estimate is likely valuable and well informed, so asking for a second opinion is a good way to confirm what you know, but also find out what you might have overlooked.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"How_to_Come_Up_with_a_Project_Estimate\"><\/span>How to Come Up with a Project Estimate<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Here are some general guidelines for crafting a solid estimate.<\/p>\n<h3>1. Break the Project into Tasks<\/h3>\n<p>Break the high level task down into the individual tasks and investigate each of those things. Smaller things are easier to estimate, and it\u2019s easier to give concrete estimates for them. For example \u201cadd a method to the controller\u201d is simpler and going to have a better estimate than \u201cwrite an application for checking mobile apps are valid.\u201d<br \/>\nAlso, if any single task gets too big, the things you&#8217;re guessing about it will probably be too large and abstract and therefore you\u2019ll miss things &#8211; so you\u2019ll get a better estimate if you break it down into simpler sub-tasks.<\/p>\n<h3>2. Determine the Overall Objective<\/h3>\n<p><strong>Is the product objective or outcome of this task clear?<\/strong><br \/>\nIf not, it will take longer because you\u2019ll have to go back and find out the information you need (and wait for the person to work out what they want), or you\u2019ll deliver something only to be told that it\u2019s the wrong thing and you\u2019ll have to do it again. You should try and avoid this\u2026<\/p>\n<p><strong>Is it quick to know whether the task has been completed, or do you need to wait to know the outcome (e.g. is it a daily cron job, do you have to wait for Product to do something, etc)<\/strong><br \/>\nIf you get fast feedback, then as soon as you see it\u2019s working you\u2019re done. Otherwise you have to wait for someone else and then you might have to fix bugs and wait for them and fix more bugs and wait for them and so on and so forth.<\/p>\n<h3>3. Identify Outlying Factors Needed for Success<\/h3>\n<p><strong>Does the project have tests?<\/strong><br \/>\nIf not, it\u2019ll take you longer because you\u2019ll have to spend more time manually testing or fixing bugs.<\/p>\n<p><strong>Is the CI\/CD config up-to-date?<\/strong><br \/>\nIf not, it\u2019ll take you longer because you\u2019ll need to fix the config.<\/p>\n<p><strong>Do you have access to all resources needed to complete the task? (app configuration, external services, etc.)<\/strong><br \/>\nIf not, you\u2019ll have to wait to get the information you need and it might be wrong and it might make it harder to debug problems and it might mean that it takes longer to fix problems (because you have to wait for someone else to change the thing again.)<\/p>\n<p><strong>Does your task have any dependencies or anticipated code conflicts?<\/strong><br \/>\nIf you have to wait for someone else to provide something, they might be late and that could cause your task to be later.<\/p>\n<p>If you\u2019re working on a code path that you know someone else is working on or has had a lot of changes recently (so someone else might be working on it), their changes might break yours, then you\u2019ll have to work together to sort it out and this will probably take longer than expected.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In this post we explore how to develop a project timeline and some general best practices for smoother project management.<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","inline_featured_image":false,"footnotes":""},"categories":[6],"tags":[],"class_list":["post-319","post","type-post","status-publish","format-standard","hentry","category-engineering"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts\/319","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/comments?post=319"}],"version-history":[{"count":3,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts\/319\/revisions"}],"predecessor-version":[{"id":3092,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts\/319\/revisions\/3092"}],"wp:attachment":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/media?parent=319"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/categories?post=319"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/tags?post=319"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}