3

How do you guys get better at estimating your tasks? I find myself frequently late with mine 😵

Comments
  • 1
    Often 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.
  • 0
    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?.
  • 2
    The 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.
  • 1
  • 1
    I 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.
  • 1
    Don't do estimates
  • 0
    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
Add Comment