Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Voxera763131dOften by overestimating and using more rough scale.
We use 1day, 3 days, 5 days, 8 days and so on.
Sure there are tasks that take less than one hour.
But with branching, merging, code reviews and every day questions you have a lot if time you usually do not count but that still exists.
And if we find time to spare its easier to pull more tasks into the sprint.
For larger projects, try breaking it down and preferably only estimate the first steps as most later parts might depend on the first, or on user experience and testing.
What kind of estimates are you thinking of, tasks to be done in a sprint, or a new complete project?
But a safe way is to consider wort case, double it, then double it again, at least for any large project or task.
The ones taking more time than expected usually out number the ones that go as planned.
Don't be optimistic.
Often people forget that developers shit too.
Once I looked at the estimation, it was like...
"5 test case per hour. 1 day = 40 test case" WTF?.
halfflat197731dThe trick, and this is an old trick, is to double the number and use the next largest unit of time.
2 hours -> 4 days.
The problem is that that just gives you a new estimate subject to the same issue.
mr-user103231dI try to draw the task diagram which show how the task are linked together with best and worest estimate. Then I double the worest estimate since you can be sick or have burn out.
dennie17038731dDon't do estimates
My method :
Take a number of hours you THINK task will take.
Add 25% for mindfucks
Add 50% for testing
Add 25% for "administrative" time
And add an hour or so for "relaxing".
In case of need to bill it to another client (eg : not an internal dev task) : Double the amount.
Usually works pretty well