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
Top comments (41)
I always double my estimation:
= +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.
You add time to write tests?? Strange.
Why not?
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.
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.
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:
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.
I look at the task in hand and take multiple variables into consideration:
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.
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.
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.
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.
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.