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 estimate which is not a accurate time it finally used.
How would you do time estimation?
General Estimated Time
I would like to conclude the general estimated time from the comments in this post.
The responded estimated time would be double of your estimated time generally.
Responded Estimated Time = 2 * Estimated Time
Why
- The task may be highly unknown which developer may never try.
- Extra task may be required such as deployment, merge, review, testing. The definition of real completion may be different from your definition.
- There may be extra requirement such as documentation
- There may be technical obstacle which block you continue
- Meeting, Communication and other assigned task make you cannot continue
- Personal problem such as sick, family issue and daily life problem
- Third Party Dependency. It may be your teammate, client or partner
- There may be something more that you cannot imagine when you do estimation
It is just draft response to our customer or boss to make them feel safe. Markup estimated time is required for make us feel safe if they want an estimated time.
Time estimation is just iterative estimation. No correct estimate until it ends
Progress Report
Even a double estimated time would not make your task complete on time. I suggest you to have regular progress update for your boss, customer or any stakeholder. Any surprise of agreed estimated time would make you get a extreme trouble. Progress update may make you safer.
This post is republished in Medium
Oldest comments (41)
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.
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
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 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.
I don't
Why?
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.
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.
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 always double my estimation:
= +100%
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.
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.
You add time to write tests?? Strange.
Why not?
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.
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.
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.