What are the different project estimation techniques in software engineering? What are some things you should take into account when estimating the completion deadline of a software development project?<\/p>\n\n\n\n
When you\u2019re programming something for someone, they always want to know when it will be done. Most of the time, you won\u2019t know exactly how long something will take, so you\u2019ll provide an estimate instead of a guarantee.<\/p>\n\n\n\n
There are many methods you can use to give your managers and clients an estimation, and we\u2019ll cover three of the options. <\/p>\n\n\n\n\n\n\n\n
When you are giving a client an estimation of the project’s completion date, it’s important to stress that it is an estimate<\/em>, not a commitment. Estimates have the following qualities:<\/p>\n\n\n\n 1. They aren\u2019t promises<\/strong> (though businesses often interpret them as such, which is why there\u2019s often conflict between programmers and businesspeople).<\/p>\n\n\n\n 2. They aren\u2019t single numbers\u2014they\u2019re probability distributions. <\/strong>They factor in the following three <\/em>numbers:<\/p>\n\n\n\n 3. Best-case.<\/strong> If everything <\/em>goes right, you\u2019ll be finished in this amount of time. This number should be very<\/em> optimistic\u2014there\u2019s only a 1% chance that you\u2019ll make this number.<\/p>\n\n\n\n 4.<\/strong> Nominal. <\/strong>This is the amount of time you think is most likely.<\/p>\n\n\n\n Worst-case.<\/strong> If everything <\/em>goes wrong, you\u2019ll be finished in this amount of time. This number should be very<\/em> pessimistic\u2014there\u2019s only a 1% chance that this is how long the task will take you.<\/p>\n\n\n\n Missing an estimate isn\u2019t<\/em> unprofessional because estimates aren\u2019t guarantees. However, professionals make their estimates as accurate as possible using well-tested estimation methods. <\/strong><\/p>\n\n\n\n Here, we’ll discuss three project estimation techniques in software engineering that are commonly used by professionals in the industry.<\/p>\n\n\n\n The first estimation method is called wideband delphi and uses consensus to make estimations by pooling the experience and knowledge of several people. <\/p>\n\n\n\n Here are the steps:<\/p>\n\n\n\n 1. Everyone discusses a task<\/strong>\u2014what it involves, how to do it, and possible delays or hiccups.<\/p>\n\n\n\n 2. Individually and privately, everyone estimates the nominal time.<\/strong> Be objective and honest about these dates\u2014don\u2019t factor in hope or miracles. Hope is dangerous because it leads people to create unrealistic schedules and then when things don\u2019t work out, people\u2019s reputations suffer.<\/p>\n\n\n\n 3. Everyone reveals their estimate at the same time.<\/strong> This is so that no one\u2019s estimate influences anyone else\u2019s.<\/p>\n\n\n\n If there are any major discrepancies, the conversation continues.<\/p>\n\n\n\n 4. After the discussion, repeat steps 2 and 3 until everyone reaches a consensus.<\/strong><\/p>\n\n\n\n 5. To determine the best-case estimate, repeat only steps #2 and #3. Take the lowest estimate.<\/strong><\/p>\n\n\n\n 6. To determine the worst-case estimate, repeat only steps #2 and #3 and take the highest estimate.<\/strong><\/p>\n\n\n\n There\u2019s another version of wideband delphi you might find useful for estimations:<\/p>\n\n\n\n 1. Write all the tasks onto cards and spread the cards out randomly on a surface.<\/strong><\/p>\n\n\n\n 2.<\/strong> As a group (but without talking), everyone arranges the cards in order of how long they think each of the tasks will take.<\/strong> Anyone can move any card, and once a card has been moved a certain predetermined amount of times, it\u2019s taken off the table and the group will discuss the task until they agree on an estimated time.<\/p>\n\n\n\n 3. Sort the cards into approximate time frames.<\/strong> Usually, the buckets are 1, 2, 3, 5, 8, and these numbers can represent weeks, days, or points (units of complexity). (Shortform example: One complicated feature might be assigned 10 points, while a simpler feature would only be worth one).<\/p>\n\n\n\n The second estimation method is the program evaluation and review technique (PERT).<\/strong> While it doesn\u2019t formally involve consulting others like wideband delphi, feel free to ask your teammates and the people around you to weigh in because their perspective might improve the accuracy.<\/p>\n\n\n\n Here are the steps: <\/p>\n\n\n\n 1. Create your distribution<\/strong> by coming up with the best case, nominal, and worst-case numbers. <\/p>\n\n\n\n 2. Describe the probability distribution using the following formula<\/strong>: (Best + (nominal*4) + worst)\/6<\/p>\n\n\n\n Most of the time, this calculation will return a pessimistic-ish number because the right side of the distribution curve will be longer than the left.<\/p>\n\n\n\n 3. Calculate the standard deviation (how much uncertainty there is)<\/strong> using this formula: (Worst – best)\/6<\/p>\n\n\n\n 4. Express the estimate as a range.<\/strong> The task will take the probability distribution amount of time plus or minus the standard deviation. <\/p>\n\n\n\n You\u2019re rarely working on just one task at a time. You could estimate how long doing all your tasks would take by adding up all the nominal estimates, but there’s a more accurate way that takes into account the uncertainty surrounding doing multiple tasks at once.<\/p>\n\n\n\n To do the calculation:<\/p>\n\n\n\n 1. Follow steps 1-3 above for each of the individual tasks.<\/strong><\/p>\n\n\n\n 2. Add the probability distributions (calculated in step #2 of PERT) together.<\/strong><\/p>\n\n\n\n 3. Use the following formula to calculate the standard deviation of the group of tasks:<\/strong> \u221a(Task A standard deviation^2 + Task B standard deviation^2 Task C standard deviation^2 \u2026) <\/p>\n\n\n\n 4. Express the estimate as the step #2 number plus or minus the step #3 number.<\/strong><\/p>\n\n\n\n The law of large numbers states that if you break a big task into smaller chunks and estimate how long each chunk will take, adding up the chunk times will give you a more accurate estimate than simply estimating the big task as a whole. <\/strong>This is because the errors in small tasks compound when you do the math, which is more realistic, because uncertainty also compounds in real life.<\/p>\n\n\n\n Once you\u2019ve calculated your estimates, it\u2019s time to share them. Once you do, there\u2019s always the possibility that people won\u2019t like them and will want something done faster.<\/strong> If this happens, you have three options, not all of which are professional:<\/p>\n\n\n\n Saying no<\/a> has a bad rap, but it\u2019s the most professional thing to do in many situations. If it\u2019s impossible to get something done properly (adhering to discipline) by a certain deadline, and you say anything other than no, you\u2019re essentially lying.<\/strong><\/p>\n\n\n\n Here are some of the situations where you might think you can\u2019t say no, but in reality, it\u2019s the right thing to do:<\/p>\n\n\n\n 1. When it\u2019s technically <\/strong>possible <\/em><\/strong>to get the job done, but only if you do it badly. <\/strong>Doing damage is unprofessional\u2014remember, your first commitment should be to your standards. (Martin\u2019s experience shows that breaking discipline is always less productive\u2014when a hurried developer writes messy code, all the other developers are slowed down too as they navigate the mess.) If the only way to get something done is to skip testing or write messy code, say no.<\/p>\n\n\n\n 2. When the adversary is your manager. <\/strong>Your job isn\u2019t to follow your manager\u2019s orders; it\u2019s to defend your objective, which is to have enough time to do a professional job. Your manager expects defense from you.<\/p>\n\n\n\n 3. When you want to be a team player. <\/strong>Being a team player means doing your part of the work well, helping others, and communicating truthfully. It doesn\u2019t help your team to agree to do something impossible on their behalf. It also doesn\u2019t help your team to let them fail because they\u2019ve ignored your \u201cno\u201d\u2014if they refuse to acknowledge your answer, speak to someone higher up.<\/p>\n\n\n\n 4. When someone begs, cajoles, or casts you as a hero. <\/strong>Accolades and glory are tempting. You don\u2019t have to swear off heroism, just swear off working unsustainable overtime. If you really want to be a hero, do the job properly\u2014meet both a reasonable <\/em>deadline and the budget.<\/p>\n\n\n\n 5. When you\u2019ve already said yes.<\/strong> Sometimes, you\u2019ll say yes to a project that has hidden complications. Once you discover that the complications will affect your ability to do a job well, you can say no in light of the new information, even though you\u2019d previously agreed.<\/p>\n\n\n\n It\u2019s especially important to say no in high-stakes situations<\/strong> (such as if your company will fail if the software doesn\u2019t work). This is because high-stakes situations are when managers most need accurate information and honesty.<\/p>\n\n\n\n You don\u2019t need to explain why you\u2019ve said no. <\/strong>What\u2019s important and relevant is that something is impossible\u2014your manager doesn\u2019t need to know why to make decisions or rearrange a schedule. If your manager is reasonable and has a lot of technical knowledge, you can explain if you want to, which will usually produce one of the following reactions:<\/p>\n\n\n\n Never agree to \u201ctry\u201d to do something in a time period shorter than your estimation. <\/strong>The word \u201ctry\u201d has multiple definitions and implications, none of which is honest:<\/p>\n\n\n\n 1. You will apply extra effort.<\/strong> If you agree to try to get something done faster, it implies that you haven\u2019t been giving the project your full effort up until this point. You have an extra energy reserve, or a new plan, or a behavioral change you\u2019ve been holding back. If you\u2019re a professional, you\u2019ve already <\/em>been throwing everything you have at the project. Therefore, there is nothing else to <\/em>try, so by promising to do so, you\u2019re lying and making a commitment<\/a> you won\u2019t be able to keep.<\/p>\n\n\n\n 2. You really mean \u201cmaybe.\u201d<\/strong> If this is the case, you should be honest about your uncertainty. If someone insists on a yes or no, and you\u2019re not sure, say no.<\/p>\n\n\n\n 3. You really mean \u201cyes.\u201d<\/strong> The person who\u2019s saying \u201ctry\u201d rarely means \u201cyes,\u201d but it\u2019s often what the listener hears. <\/p>\n\n\n\n If you say yes, you\u2019re committing to getting something done by the date you promised, no matter what it takes<\/strong> (overtime, skipping family vacations, and so on). It\u2019s unprofessional to say yes to something you\u2019re not sure you can achieve because other people are going to plan around you. If you miss a commitment, it\u2019s a huge blow to your reputation.<\/p>\n\n\n\n On the other hand, it <\/strong>is <\/em><\/strong>professional to ask to change the parameters of the task so that you <\/strong>can <\/em><\/strong>say yes. <\/strong>(You cannot say yes without something changing because you already considered every factor during your estimation.)<\/p>\n\n\n\n One of the parameters you might<\/em> change is your working hours, but working overtime will tire you, so it has limitations:<\/p>\n\n\n\n Therefore, don\u2019t agree to work overtime unless:<\/p>\n\n\n\n According to consultant Roy Oshervoe, there are three stages to saying yes and committing:<\/p>\n\n\n\nMethod #1: Wideband Delphi<\/strong><\/h3>\n\n\n\n
A Variation on Wideband Delphi<\/h5>\n\n\n\n
Method #2: Program Evaluation and Review Technique (PERT)<\/strong><\/h3>\n\n\n\n
Using PERT to Estimate Time Required for Multiple Tasks<\/h5>\n\n\n\n
Method #3: Law of Large Numbers<\/strong><\/h3>\n\n\n\n
Sharing Your Estimates<\/strong><\/h3>\n\n\n\n
Option #1: Saying \u201cNo\u201d (Professional)<\/strong><\/h4>\n\n\n\n
Explaining Yourself<\/h5>\n\n\n\n
Option #2: Saying You\u2019ll \u201cTry\u201d (Unprofessional)<\/strong><\/h4>\n\n\n\n
Option #3: Saying \u201cYes\u201d (either professional or unprofessional)<\/strong><\/h4>\n\n\n\n
How to Say Yes<\/h5>\n\n\n\n