How do you estimate time required for assigned task?

Ben on August 29, 2018

When some tasks are assigned to you, your boss would often ask for your estimated time for assigned task. For me, I often say a very draft esti... [Read Full]
markdown guide
 

Approach #1: Don't estimate. Doesn't often work, but worth a try for those times it does
Approach #2: Work out whether you are being asked for an estimate or a quotation. They are different things and most of the time, when people say estimate (i.e., educated guess, likely to be inaccurate) they mean quotation (i.e., expectation around precision and who owns the risk in the case of overruns)
Approach #3: If you've never done the exact same work before, you are guessing instead of estimating. Be open an honest about this when communicating your estimate
Approach #4: Don't lure people into a false sense of precision in your estimates. For an estimate in days, round to weeks. For an estimate in weeks, round to months.
Approach #5: Always estimate in ranges (i.e., from X to Y), but make X your estimate as things always take longer.
Approach #6: Read Steve McConnell's Software Estimation book as well as Waltzing with Bears for deeper insight into estimation and risk management (which is closely related)
Approach #7: Don't estimate :-)

 

I always double my estimation:

  • +30% for writing tests
  • +20% for organisation, communication, coordination, writing issues, moving them around, meetings etc
  • +25% for writing documentation
  • +10% Merge Request and Peer Review
  • +15% tolerance buffer for wrong estimations

= +100%

 
 

I 'm tempted to agree with everything written in this comment except writing the test because I always do Test Driven Development when coding.

From my view, the factor should be 1.75 instead of doubling.

 

I'm doing TDD too, but no matter how you write your tests, you have to invest the time to write them. And putting together some shit code without writing tests is faster (in short term) then working with TDD. And time you have to consider too IMHO.

I think TDD is just a slogan. You cannot design your flow before test.

TDD is only suitable for someone just following the guide or well tested design sepc.

I think Unit Test is good for continuous integration and refactoring. It would be somehow a code quality but it is a measure of test coverage. The quality of a software is based on human.

My estimated time for Unit test would 1/3 of coding.

 

If you do so, your boss may ask why and could you reduce the estimated time. How would you response them?

 

You reduce the task requirement, you cut down from the business logic, otherwise you cut from the product code quality which will lead to longer future task durations and bugs, which leads to less profits, and noone wants that.

this

Haha. But usually, requirement is not very concrete

Sorry then, you can always change your job, work with smarter product owners :D, preferable in-house products, SASS and technical managers.

Or build something random which u think it requested, and if is wrong estimate a new task.

 

I create signpost tasks and assign arbitrary numbers to them (usually Fibonacci numbers). So maybe changing the label on a button is a 1 whereas adding a new per-user setting that needs to be stored on the server is a 3. I track my (or usually my team's) velocity over time, that is how many points we complete each sprint. After 3 or 4 sprints, we usually have enough data to know whether or not a particular group of tasks is doable in a single sprint. But I almost never know how long a single specific task will take. Sometimes it goes way faster and sometimes it goes way slower. That's why I usually commit to a group of tasks because the errors tend to cancel out.

I've found variations of that approach work on most teams I've been on. But really you've got to find the system that works for you and/or your team.

 

Did I miss something, isn't it CA Rally you are mentioning about?

 

Maybe so. I'm not familiar with CA Rally, but it might be the same thing.

 

Unfortunately I don't have the luxury of refusing to give an estimate since work doesn't get approved by the customer without it in my market.

So what I do is I keep track of repetitive tasks and their time. Usually these tasks are small ones like using text, translations, buttons, links etc.

When I have to implement a new feature I've not done before, I review and write out all the small steps that build up into this feature, total them up in time then add a day for unexpected problems or required research/coordination.

My method is fairly accurate so far for my needs, I've only busted my estimation twice, but those two times were considerably large busts.

 

Recent example from my work-life.

"Hey, how long will implementing filters for a search-results-page take (as in front-end-web-dev)."

I'm thinking of the best case, where everything is specified neatly, the design is there (also the tablet-view!!1!!1), API is well known etc.

10 days (80 hrs).

Now I start asking (myself and the colleague).

Do I know the codebase? If not, I add maybe 2 days. (12)

How well is the design specified? Oh, only the desktop-view? Add 3 days. (15)

Is the REST-API known and documented? Ah it's being currently made and is quite new? Add three more days. (18)

Is the local instance of the shop running reliably on my dev-machine? This projects is based on SAP-Hybris, so I add 3 days for initializations, updates, local fuckups etc. (21)

How well are the requirements written? Don't get me started, adds two days for additional client-communication. (23)

This goes on an in the end I arrive at 25 days, which, telling from experience, is a totally OK amount of time to spend on such a feature.

"But do you really need five weeks for this?"

No, I'll most likely be done in half the time, BUT:

  • I'm highly allergic to stress
  • It's not a prophecy, it's a forecast (as in weather)
  • I always take time to learn a new approach/library/API that is relevant to the task (That time I learned a lot about browser-history-api. I often read about people struggling to keep up with all the new stuff. You have to bake learning into estimates, just like testing.)
 

An ex colleague told me something very valuable at the beginning of my career: think about how long it would take in your opinion, then double it. That's your estimation.

 

usually when someone asks me for a time estimation I would ask them for some time so that I can analyse. Say feature "x" will take 6 hours to complete, so I will return 6 * 1.5 = 9 hours as the estimation.

Often it takes less time then the estimated ones, but it's better to be safe than sorry 😁

 

I often found that * 1.5 is not enough.

 

I look at the task in hand and take multiple variables into consideration:

  1. Have I written similar before?
  2. Does it require anything new I'm not familiar with?
  3. What language(s) would be required? (Fluency and knowledge etc)
  4. What is the deadline for this?
  5. Is it just me working on it or is there other devs on the project?

From these variables I'm normally able to give myself a rough estimate on how long, especially with the entities of have I done it before and the familarity, we all know bugs are a giant pain in the ass at times if the answer to both of these questions are yes then it can both slowdown or speedup a process.

As Benjamin mentioned below I sometimes double the time depending on how hard or simple I feel the project could be. I often find that the code side of things takes up roughly 65% of the work, spending more time writing documentation, tests and in some cases a how to use guide for the client can take up a substantial amount of time.

 

How about the buffer to cater for accident?

 

Well when something breaks or a bug is caused it all depends on the type of issues. I normally mark them from severetiy between 1-10. 1 being like a typo and 10 being holy crap everything is on fire what did I do wrong?!!?!?

I'll focus more on the high priority bugs first and find that they can take a lot longer, even if its something very simple causing the issue I'll sometimes find that the period of time to find the actual cause is very long. I can't really guess whether or not bugs is going to happen before I start the actual project, however I can take a little guess on whether or not something may or may not be an issue down the line.

 

Estimates only work for tasks where almost all of the "pieces" are known (Building a house, Building a bicycle, etc...). In software tasks are regularly not fully defined or are misunderstood based on the information supplied. This means that any estimate has to be based on a prediction of the sub-tasks and the effort involved to execute those tasks.

If my personal estimations were gunpowder, I wouldn't be able to blow my nose!

The only possibility to create a reasonable estimate is to document the sub-tasks that are known and then estimate them, and finally add some prediction for unknowns to that total. The documentation of the sub-tasks also helps to make it more clear as to what work is being done so if there are any major misconceptions they can be found as early as possible.

Nothing beats revisiting of the estimations against actual work performed to see how well the estimates were derived. The problem usually becomes that the estimates were wildly wrong and the customer is expecting the original delivery date.

 

We finally arrived at complexity estimation with Fibonacci and a rough calibration saying 6 points are a day (just so everybody has the same gut-feeling-base). We then fill sprints according to the speed.

Though, for quotes - we are not doing in-house development - we need to estimate. Over the years, from issue-data and experience, we came up with a factor of 1.6 to calculate with. IMO this is too low, as we still run into timing issues towards the end.

In an ideal world, we‘d have complexity-estimation for planning purposes based on speed with continuous, open-ended development (it‘s done, when it‘s done). Through the sprint-reviews all sides are up to date and can make decisions.

Hofstadters law seems to be true :-) There‘s also scientific information about this.

 
 
 

Over many, many years of being a developer, I've come to realise it is basically a waste of time. If you are coding something new, it is largely a total unknown and trying to break it down up front and estimate how long it will take is generally futile. Coding something is mostly an organic process that, in my experience, changes all the time - and rapidly. More often than not you find your initial idea wasn't correct and the correct, or better way is much longer or possibly shorter.

Spending time upfront trying to break a task down and put a time on it merely adds time to the total - time that is largely worthless and would have been better spent just getting on with it.

However, it IS usually possible to give a rough completion time once you are at a point where you're pretty confident your solution is working

Yes. I know it and totally know your feeling. But the most depressing thins is that you need to response a estimated time to your customer or boss in the real life. And you need to take responsibility to the estimated time.

 

Go trough the code I need to modify (or make the architecture if is a new one). Split it to subtasks if is big.

Estimate each substask( Including refactoring, tests, debug etc).
Multiply by 2 or 3.
If it is dependent on 3rd party (out of my reach) add a few days.

Mostly my managers asked about the time more to calculate how much can I do in a sprint, so is not really about the exact time, is about how much you can deliver in a sprint.

 
 
 

Right, but you should spend as little effort/time as possible. The outcome of estimation is not working software.

Planning is different imo

But the client need one. And you should give a safe estimation for you.

No, you should use yesterday’s weather to ballpark things youve already done.

Can you reliably estimate something you’ve never done before? No. Should you tell the client things that aren’t true? No. Should you get in the habit of padding? No.

Estimates are NOT working software, ergo they are waste by definition.

 

The best way to handle estimations is to follow the Avalanche Development Process. This will bring your project to a conclusion efficiently.

youtube.com/watch?v=yR_XIPOkSmQ

 

Ben, thanks for such a hot question.

Actually, there are different ways and estimation techniques. However, At Codica, we recommend implementing the following three approaches:

  1. T-Shirt Sizes
  2. T-Shirt Sizes into Story Points
  3. Move on to Fibonacci story points

All of them are pretty clear and easy-to-implement, you just need to take a look at the full version article to get acquainted and start using these approaches right now!

We believe our answer will be useful for you!

 

It never works... but you can write all the issues and select some of them for 1.0 (MVP estimation).

 

That mean you would select MVP as your assigned task.

Maybe the question can be rephrased to "How you estimate time required for select function for MVP?"

I think sometimes MVP in your boss's mind may not be as same as yours. Haha :).

 

You gotta convince your boss how an MVP should be like... that's the dev job :D

Maybe by telling him that implementing the search function for the e-store isn't really important as showing the products in the first place.

Or adding the profile feature isn't as important as registering a user (without any profile just email & pass).

That way things get clearer and estimation become more realistic.

Getting requirement is much more difficult task which always make me cry.

 

I'm a mess calculating time. It almost always takes me longer than I said, specially when we're about to release :(

 

Yes. I agree with you. I always find something blocking you. But the boss always ask why do you need delay.

code of conduct - report abuse