707

We, as programmers, are constantly being asked 'How long will it take'?

And you know, the situation is almost always like this:

  • The requirements are unclear. Nobody has done an in depth analysis of all the implications.
  • The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.
  • You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.
  • The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?
  • No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Many of these are organizational or cultural issues that are not simple and easy to solve, but in the end the reality is that you are being asked for an estimate and they expect you to give a reasonable answer. It's part of your job. You cannot simply say: I don't know.

As a result, I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again. But it does.

What is your personal process for deciding and delivering an estimate? What techniques have you found useful?

jlevis
  • 111
  • 2
Sergio Acosta
  • 9,568
  • 3
  • 25
  • 36
  • 17
    See also [How to explain that it's hard to estimate the time required for a bigger software project?](http://programmers.stackexchange.com/q/102856/31260) [How to learn to make better estimates?](http://programmers.stackexchange.com/q/16326/31260) [Getting non-programmers to understand the development process](http://programmers.stackexchange.com/q/4/31260) and [What can I do to get better at estimating how long projects are going to take?](http://programmers.stackexchange.com/q/39411/31260) – gnat May 22 '13 at 05:04
  • 4
    If the requirements are not so clear, you can estimate with a 50% error margin (wider range). If the requirements are clear, you can estimate with a 20% error margin. Another good strategy that worked for me is to split a project into stages. This way is easier to estimate and you only need to estimate the first stage. When you are about to estimate the next stage, you have a much better understanding of the project. Also, trust between you and your contractor should be better. I also always write my assumptions and preconditions. Never write "it will work on IE8 or higher", be specific. – Francisco Goldenstein Jun 10 '14 at 14:13
  • Sergio, "As a result, I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again. But it does." How much do you feel improved today? – Remigijus Pankevičius Apr 17 '15 at 20:44
  • 4
    @r.pankevicius Honestly, I just stopped giving estimates: https://rclayton.silvrback.com/software-estimation-is-a-losing-game – Sergio Acosta Apr 18 '15 at 05:16
  • 2
    I think it's also important to see the nuance between "estimates" and "deadlines". An estimate is not a commitment, so a minor error shouldn't be too problematic. I wrote a lengthy blog post about this here in case anyone is interested: http://marcgg.com/blog/2015/08/27/deadlines-estimates-software-startup/ – marcgg Oct 19 '15 at 06:44
  • You may want to read about the "Cone of Uncertainty" – Bradley Thomas Jul 14 '16 at 17:41
  • Maybe the pareto principle could help? 80% is preparation, and 20% is actual work. From the past, look at how much time you needed to write a certain amount of code, multiply that by four and add that time to your initial estimated time. – Ikem Krueger Feb 23 '18 at 00:31

17 Answers17

425

From The Pragmatic Programmer: From Journeyman to Master:

What to Say When Asked for an Estimate

You say "I'll get back to you."

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

In the section, the authors recommend the following process:

  • Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
  • Make sure you understand what is being asked. Determine the scope of the problem.
  • Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
  • Calculate the estimate based on your model.
  • Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
  • Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.
Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 34
    This is also a big part of McConnells's "Black Art of Software Estimation". *Never* off-the-cuff it. – Paul Nathan Sep 03 '10 at 17:35
  • 1
    I haven't read Black Art of Software Estimation yet. Its the only Steve McConnell book I haven't read (well, I've never read After the Gold Rush, but I did read the second incarnation of it - Professional Software Development). – Thomas Owens Sep 03 '10 at 18:15
  • 15
    I highly recommend the McConnell book. If possible, ask anyone who needs an estimate from you to take his estimating quiz: http://www.codinghorror.com/blog/2006/06/how-good-an-estimator-are-you.html You can present it as a game, but it often helps to get the message across. – Paddyslacker Sep 03 '10 at 20:57
  • 139
    You can *always* say "I'll get back to you." If someone says "Well, I need an answer," say "If I give you an answer now, it will be a lie. I do not have enough information right now. It would be a disservice to us both for me to make something up on the spot." – Andy Lester Oct 08 '10 at 22:14
  • 18
    @AndyLester - plenty of situations arise where if YOU don't give an answer now, someone else will, and either take the project and the money with them, or still pin the blame on you in the end for missing an estimate you had nothing to do with. It sucks, and it's wrong, but it's unfortunately reality. – Joris Timmermans Nov 17 '11 at 14:24
  • 2
    @MadKeithV I have never been in that situation, and I've sat in and been involved with multiple project proposals for multi-million dollar contracts on both sides of the fence. In fact, in my experiences, after an RFP is published, the bidders have ample time to review the documents, ask questions, and produce estimates for cost and time. – Thomas Owens Nov 17 '11 at 14:28
  • 3
    @ThomasOwens I'd never use a shooting-from-the-hip estimate for a contract but I do use those estimates before the contract stage. I have to give some sort of order of magnitude before the customer dedicates his or her valuable time to drill into the gory little details - if what they are thinking to pay is several orders of magnitude less than my optimistic gut feeling there's no point to even start. – Joris Timmermans Nov 17 '11 at 14:51
  • @MadKeithV That concept is foreign to me. Perhaps it's just not how it works in the defense industry, or at least on the types of projects that I've worked on. There's just an RFP, some back-and-forth, and then bids. The customer creates some type of conops document or system requirements and draws up an RFP. Then, bidders review these documents, ask questions, and eventually submit a bid. I've never seen pre-RFP discussions, although I have seen RFPs that just go nowhere because of what the bids look like. – Thomas Owens Nov 17 '11 at 14:57
  • I usually take my personal (accurate) estimate, and multiply it by four or five, it has the advantage of being both competitive AND relaxing. But then if you're not ten times faster than most people, this won't work. – Morg. Jun 04 '13 at 11:17
  • A much better question in this situation is "When should I ask you about the estimate again?" - sometimes this will require a second derivative answer: "I will know answer to THAT in three days." It rarely goes more meta than this. Otherwise, I'm giving a wiiiide bracket: "Anything between an hour and two weeks. We're searching; it's an hour since found until fixed, but it first needs to be found." – SF. Nov 22 '15 at 08:06
  • And there's always... "It's six hours of work. Now when will these six hours of work be scheduled, that's out of my hands, talk to my boss." – SF. Nov 22 '15 at 08:13
  • Statistically we under-estimate by 30%. So just multiply your estimates with 1.3 and it should be accurate :) – David Jan 14 '16 at 17:13
  • 2
    "Determine the accuracy that you need" should be changed to "Determine the precision you need". Sorry to be pedantic but it's a really really important point you are making here. The biggest challenges I see around estimates is the lack of understanding of precision and accuracy and how they relate to each other. – JimmyJames Jul 14 '16 at 16:00
  • +1 take time to make a decision. If your employer won't allow you to make an educated guess, then they are bad at their job and shouldn't be working with software developers. I always split my task into sub-tasks, decide how long each sub-task should take given past experience, then add 1 day for each sub-task for expected technical debt. Then I give it to my boss. If he wants it done sooner, he can choose what feature to cut. – EvSunWoodard Oct 25 '16 at 17:44
  • When did suggesting that one purchase a book become an acceptable answer? – icirellik Jun 14 '17 at 02:25
  • @JorisTimmermans This is true, but usually if stakeholders prefer someone who gives the answer "now", it means they are bad and this is a project doomed to fail. You have all to gain by staying out of it. – Dario Fumagalli May 21 '18 at 09:01
  • @DarioFumagalli I disagree that you always have "all to gain" by staying out of it. If you're a freelancer and you need the work, then taking on a sensible amount of extra risk (in the schedule) for an actual paycheck and food on the table can be a very sensible choice. There are other factors at play too, such as "how much could I deliver to make the customer more flexible in allowing slippage from the original schedule". I do prefer to work on projects where planning and estimation is done properly, but sometimes that's an unaffordable luxury. – Joris Timmermans May 21 '18 at 12:54
  • I am a 1 man operation, I've learned over 35 years that a bad deal is a bad deal and "desperation for food" does not turn it into a good deal. If you are forced to do it by lack of other work, then do it. But if you have a choice, don't. – Dario Fumagalli May 23 '18 at 07:32
  • How do you track your estimations? – Filipe Giusti Nov 20 '18 at 17:29
  • @ThomasOwens I just edited that question you just deleted to make it conform to the rules of the community. Could you please give it a look and undelete it? Thank you. –  Feb 24 '21 at 14:31
183

Software estimation is the most difficult single task in software engineering- a close second being requirements elicitation.

There are a lot of tactics for creating them, all based on getting good requirements first. But when your back's against the wall and they refuse to give you better details, Fake It:

  1. Take a good look at the requirements you have.
  2. Make assumptions to fill in the gaps based on your best guess of what they want
  3. Write down all your assumptions
  4. Make them sit down, read, and agree to your assumptions (or, if you're lucky, get them to give in and give you real requirements).
  5. Now you have detailed requirements that you can estimate from.

It's like my mother used to threaten when I was a kid "Hurry up and pick out some clothes, or I'll pick them out for you!"

Fishtoaster
  • 25,909
  • 15
  • 111
  • 154
  • I asked a follow up question concerning your 3rd point. http://programmers.stackexchange.com/questions/132970/how-to-infer-my-assumptions-i-based-my-time-estimate-on – k0pernikus Feb 02 '12 at 13:24
  • 1
    How long does it take to write good requirements? – mmehl Nov 08 '16 at 22:20
156

I did development for a guy who was very adamant about wanting accurate estimates. What we settled on, which worked very well, was this:

  • I billed for all the time I spent estimating. It came to around 20-25% of what I billed.
  • I did extremely detailed examination of the tasks. No shooting from the hip. I went into the code, figured out what lines needed to be changed, what other parts of the program it would affect, how much testing I'd have to do to ensure that things still worked. I'd estimate each piece in units of .1 hours (6 minutes).
  • I sent him my estimate for each task along with that detailed breakdown.

20-25% of billing sounds like a lot.

But he'd ask me to make change XYZ, thinking it'd take about 2 hours. In 1 hour of detailed estimating, I'd determine it'd take 8.5 hours. So he'd decide whether it was worth 8.5 hours of pay. If not, then he saved 7.5 hours over what it would've cost him if I'd done it without an estimate.

And if he did want to invest the 8.5 hours, the detail work I did for the estimate was work I'd have had to do anyway.

I found that with this method I was able to bring most tasks in on time or even early, without having to heavily overestimate. Because the time was broken down so minutely, I could tell early on if I was slipping. If I hit roadblocks so that after 3 hours I could tell that my 8.5-hour task was going to take 12, I could talk to him about it before more time passed so he could reevaluate and yank the feature if he was concerned about the cost.

Was he nickel-and-diming? No, I looked at it as letting him apply his money where he saw the most benefit. And I was glad to get experience in estimating, which I'd always been terrible at.

Kyralessa
  • 3,703
  • 2
  • 19
  • 20
  • 13
    That sounds like a very adequate technique. In fact, when you are making an estimate for your own company the estimate time is being paid as part of your salary also. I'm afraid, however, that the problem is that most organizations want estimates of much bigger tasks than the ones that can be expressed in .1 hour chunks. Thanks for your answer. (Are you the same Kyralessa from the joel on software boards?) – Sergio Acosta Sep 29 '10 at 06:05
  • 1
    Yes, the same one. – Kyralessa Sep 29 '10 at 13:32
  • @SergioAcosta the point is you use the analysis/estimation time to break down the task into smaller chunks. This is the best answer, imho. – NimChimpsky Aug 07 '15 at 07:40
  • 11
    So if it is like 5 months project you should be estimating it for a month or more. Probably managers will not accept that :) – Darius.V Jul 13 '16 at 04:46
  • 1
    @Darius.V, you make a good point. In this case the client's decisions were Yes or No to particular features, not an overall Yes or No to the entire project. This technique is certainly more challenging if doing the entire project or not depends on the overall estimate. On the other hand, if you're budgeting for six months for a project, but the project might actually take a year, would you rather find that out after six months, or after two or three? – Kyralessa Dec 26 '16 at 16:33
  • @Darius.V yah your comment actually makes sense, that's why you get those RFPs in which they want a detailed proposal sent back. I didn't really get it until this particular post detailed out for some reason. You end up screwing yourself over if you don't do the due diligence as the tldr; – King Friday Dec 03 '17 at 18:22
  • @Kyralessa this technique works if you have code or precedents which you can use to base the estimating on. With greenfield projects or features where even the technology being considered might be new there are several unknown unknowns and a different estimation technique may have to be followed from what you're suggesting – pcodex Jan 14 '21 at 02:20
  • @pcodex In that case, those "unknown unknowns" are called _risks_, and they need to be mitigated. One way is to simply tackle them head-on: Do those parts of the project first. Another way is to do accurate estimates for the knowns, and much wider estimates for the unknowns, to reflect the uncertainty. A good project manager (and I don't claim to be trained as a project manager, mind you) will have tools to deal with this situation. – Kyralessa Jan 14 '21 at 05:42
  • " is to simply tackle them head-on: Do those parts of the project first.." .....don't agree with you here. With unknown unknowns there would be nothing to tackle head-on and no there can be no definite risk mitigation plan since they are unknown in the first place. We can only be sure of what has occurred and an empirical approach is what would make sense in the situation I've outlined not your approach of trying to do an upfront estimation. – pcodex Jan 14 '21 at 13:11
  • @pcodex You mitigate unknown unknowns by building more slack into the project plan. – Kyralessa Jan 14 '21 at 15:16
69

We're often asked for an "ballpark estimate" during meetings where we're given very broad and vauge ideas of what they'd like to do. I always say, "if you want an answer today it's a year and a million dollars. If you'd like to give me a lot more details and some time to review them then I can refine those numbers for you."

They almost always get the point.

Walter
  • 16,158
  • 8
  • 58
  • 95
  • 11
    When they say it's too much, I pretend to think for a minute then say, "You're right! it is 18 months and 2 million". – CyberFonic Dec 03 '17 at 23:19
58

It depends on what the estimate is for.

For an initial, high-level estimate for a business case then the key things are:

  1. Speed. Whatever method you use it needs to be quick. The whole point is the stakeholders aren't sure if it is even worth doing the project - which is why they need the numbers for the business case. If the business case was solid they wouldn't need your estimates. The bulk of these projects won't go ahead so it is important that too much effort isn't expended providing the estimate.
  2. Give a range. Make it broad. You have had no time to analyse requirements, workshop with stakeholders, validate assumptions. A wide range tells the recipient of the estimate "Software projects are naturally complex and risky - if you want a proper estimate you need to give me more details and more time". The problem with giving a single number or a narrow range is that it paints you into a corner by setting expectations before any real analysis is done.

I find the best technique to pick a comparable project that "feels" the same. "Feel" is completely subjective - but with this kind of estimate my experience tells me you won't find objective measurements. Then provide a wide range. I've read some books that say a range of -50% to +100% is good but it depends on many factors.

For a detailed, low-level estimate:

  1. You need a baseline. If the baseline isn't stable the estimate is meaningless.
  2. Bottom up is best. Get a detailed work breakdown, estimate each component then roll it up into a larger number. I find planning poker to be a great technique here.
  3. Document contingency. Make it clear where any contingency (if any) is added. Is it added to each line item? Or to the whole estimate? Or to specific risks? Or is there none?
  4. State your assumptions. Validate as many as possible given the time frame.
  5. State explicitly what is included and excluded in the estimate. For example, is review included? Are technical delays included?
darreljnz
  • 1,077
  • 1
  • 7
  • 9
29

Some advice from the dark side from one who learned the hard way.

The requirements are unclear. Nobody has done an in depth analysis of all the implications.

Don't do an estimate at this point. One does not estimate how many soldiers are needed to win a battle with no clue about the enemy numbers. The estimate is made after scouting. This is unless you already fought this enemy.

The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.

This is your responsibility to factor in unless you expect others to have the expertise about this area.

You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.

Same as above, even for unanticipated work that's created by a slob team mate next to you with a near non-existent test procedure which causes your code to glitch out that you can't perfectly predict in advance. It's a weather forecast.

The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?

Understand the user-end requirement here, think like a user. Don't do what your peers do if they estimate something to be "done" just because some basic functionality with a barebones workflow that no user can possibly tolerate is what they consider to be "done". Think of it from the user standpoint, because that's all the client you're making the estimate for will typically understand. Estimate towards the complete user-end requirements, not towards the barebone technical requirements. And realize that your clients asking for estimates will be totally inaccurate here about how they word things and understand the technical aspects of what you say.

No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Don't do this! You sound like a self-motivated hard worker and possibly one who gives in easily to coercion.

The problem here is this: let's say you and Joe made time estimates for the same task (but between two separate employees, unaware of both estimates at one time). You estimate valiantly, "one week". It's okay you think, you'll work over 100+ hours a week, unpaid overtime. Now you're three days late.

Meanwhile, Joe estimates 5 months. You think this is ridiculous, you think you can pull this off in one week. How much does Joe work? 10 hours a week? ... except he finishes on time in exactly 5 months.

Guess who gets perceived as the jackass? That's right, you. Joe seems like a great worker, you seem unreliable now. It doesn't matter so much that you might have achieved an even better result in ~7% of the time that Joe took. What matters is that you were 3 days off from a one week estimate.

Never err on the side of the tighter estimate. Err on the side of the looser estimate. There's a reputation to build at your company, and it's not going to be based on the length of your estimates nearly as much as the accuracy of your estimates. It's easy to be accurate with an estimate that's too long, you just get more time to work on the problem and solve it better. An estimate that's too short leaves no breathing room at all, you either meet it desperately or you're screwed.

ChrisF
  • 38,878
  • 11
  • 125
  • 168
19

"Two weeks!"

Seriously. My first estimate is always two weeks. Because I have some sort of bizarre mental block that makes me think everything sounds like it'll two weeks.

I try to work around it, try to really think about how long I think something will take, trying to identify all the potential trouble spots and bits that look too black-box-y for me to be accurately estimating. And try to recognize that if my answer is "Two weeks!", I've likely failed to do so.

Pretty much every good manager I've had has learned to recognize "Two weeks!" as an answer that requires a mild verbal pimp-slap in response.

BlairHippo
  • 8,663
  • 5
  • 41
  • 46
18

There is a blog entry that outlines how to keep a record of how accurate your previous estimations have gone, and then next time you say to someone "it'll be two weeks", you can look at your previous history and see how long it actually took last time you said "it'll be two weeks".

I haven't tried it myself, but I'd like to, to see how accurate my estimations are.

k0pernikus
  • 177
  • 8
Richard
  • 1,868
  • 15
  • 18
  • 2
    Joel's Fogbugz goes further on that and analyses your data for you using evidence based scheduling. Ie, each developer enters how long they think each task will take, and later, how long that task took, and it guages how accurate each developer is with their estimates to produce a probability curve for a finish date. – Chris Buckett Sep 26 '10 at 19:49
12

It depends on the organization and how the estimates are used.

If the estimate is just to provide a general idea on when it will be ready, I can generally do a quick estimate based on my experience. Often times I will include any uncertainty or possible variations with the estimate along with how the changes may impact other areas of the system and the extent of regression testing required.

If the estimate is used for anything contractual or in a scenario where more precise timing is required, I do a full work break down. This is more work and requires more in depth thinking about the design and changes to the system, but is much more accurate, especially for larger pieces of work.

In either case, on-going communication is key. If you do run into something unexpected, make it known at the time instead of waiting until the deadline. If the requirements are not-clear, make sure you document your understanding of them and the functionality that you plan to deliver. This is also helpful with any assumptions you make. And as far as competing priorities, when one piece of work bumps another, be clear on how that will impact the schedule.

g .
  • 707
  • 6
  • 12
  • 2
    +1 for the need for on-going communication. IMO, this is **the** most useful part of the Agile model. – Scott Weldon Sep 23 '15 at 05:37
  • This is the first decent answer here simply because it's the only one thusfar (I'm reading top to bottom) that stresses "ongoing communication". Everyone else seems to think estimate-communication is a one-off event. That's bad advice, and a poor approach to these things. *This answer* is good advice. – Adam Cameron Dec 04 '17 at 08:04
10

Estimates for what? Small tasks or complete solutions.

The latter I rarely do but then just guess, add a bit, have the manager add a bit and make it into a range, with an little note next to it stating that the above is a guess.

Small tasks - Planning poker I've found to work really well (not perfect, some 1pt tasks have taken much longer and some 5pt tasks took minutes, but it all evens out in the end).

mlk
  • 1,049
  • 8
  • 18
8

Confidently. I can't tell you how many times I botched up an initial meeting with a client by not putting on professionalism when giving an estimate. Even if you're blowing numbers out of thin air - make sure you always keep some estimate around. That said, be careful not to estimate yourself into a hole. Different things take different amount amounts of time, effort and resources to put together. Here's a good way to do it:

Them: How much will it cost?

Me: It depends on what you want me to do. Generally, I start this sort of project at around $X.

Moshe
  • 5,022
  • 2
  • 30
  • 49
8

Present a range based on what you know today. Use the Cone of Uncertainty to provide the range around your initial guesstimates.

Every week calculate how much is left to do, re-estimate based on what you know. Once you have enough of a sample size of how much work you are getting through each week, provide a 90% confidence interval for what's left to give a (usually) ever narrowing date range as the project progresses and the amount of work left (hopefully) shrinks.

Paddyslacker
  • 11,070
  • 5
  • 55
  • 65
7

Sometimes estimating becomes an enormous challenge for you and your team, especially when we are talking about software project estimation.

Once we had decided to share our experience and our knowledge about software estimation process and defined four distinct types of estimations:

  • ballpark figure
  • service estimate
  • feature estimate
  • componential estimate

Of course, those types are distinct. Ballpark is what is often called a “guesstimate”. So it's an approximate number or range that gives a general idea of cost and that may help a prospect decide whether they would like to take the discussion further.

As a rule, clients need a ballpark figure at the beginning of the project. And our advise is: discussion of the project and providing ballpark figures should just be steps well towards receiving componential estimate (which is flexible, one can make use of componential type estimate for the whole development process. No need to re-estimate from scratch when you want to add, remove or replace features, services etc).

Everyone should keep in mind the risks that come with software development estimating: underestimating, overestimating, total epic fail scenario etc.

You can read more on our blog!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Hope this information will help you!

Olha
  • 89
  • 1
  • 2
6

I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again.

It sounds like you're being asked for a commitment, not an estimate. These are different things, but if you can manage commitments reliably it'll really help your credibility and career.

Some advice based on my ~10 years of experience:

  • Always provide a range (i.e. lower and upper bound). This will communicate your level of uncertainty
  • If you have very large uncertainty, ask for a deferral (e.g. 1 day to do analysis, and then provide a tighter range)
  • If the task it too large, break it up and provide a range for each piece
jamesfmackenzie
  • 211
  • 2
  • 2
4

First, if some task was assigned to me I would break it down into subtasks.I would estimate the time for each subtasks and probably with subtasks I would be able to find the problematic area and hence I would be able to forecast how long it would take to a certain extent.

But still all the planning would help only to a certain extent. Only when you start coding you can find the exact issues

Gopi
  • 3,113
  • 1
  • 24
  • 30
1

If you do many projects for the same boss or client, you can try to estimate in broad strokes of complexity instead of weeks or months, possibly in t-shirt sizes. Identify a few past projects, and assign them the sizes S, M, L, XL.

And then ask yourself: which project does that sound similar to in scope? And then instead of answering with "2 Months", you can answer with "sounds like an L to me" (or whatever your calibration for project turns out to be).

This is pretty easy to understand, and it is also clear that there is lots of uncertainty in those guesses.

Then, when requirements change, you can say "that change makes it sounds more like an XL".

moritz
  • 121
  • 1
  • 3
  • this is quite smart (if you are allowed to use it): I prefer going with a similar approach but just generalising with time values, so I will answer "this will take a week or so" or "it's going to be a matter of days" for something small and avoid answering when the project is going to be bigger than a month and need a proper estimate – Edoardo Apr 25 '18 at 14:18
0

A bit late but when I was in the military we were instructed to use PERT to determine estimates. It does require some experience in your field and the task at hand. It was surprisingly accurate when determining estimated time of completion when maintaining and repairing electronic devices (complex radios and satellite comms equipment), where any number of things can be wrong or found and needed to be fix during routine maintenance. The estimations were important because other units may be inoperable until they received back their comms equipment. One that I've used is this Free Online PERT Calculator

xtreampb
  • 144
  • 3