Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Voxera113885yOften 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. -
mr-user13495yI 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.
-
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
How do you guys get better at estimating your tasks? I find myself frequently late with mine 😵
question