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 estima...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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:
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!
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.
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
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.
All estimation is waste.
But you need to do so.
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.
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.