Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: estimation

  • Random Thoughts on Estimation

    A lot of discussion on estimation recently. A lot of great arguments but a lot of good old mistakes we’ve already went through. This brought me to a few random thoughts on estimating techniques.

    1. Estimation technique which involves discussion between different people is better than one which just simply uses their estimates as input.
    2. Using factual recorded historical data is better than basing just on experience.
    3. Smaller tasks can be estimated way better than big chunks of work.
    4. Every estimate starts with some kind of guess at the very beginning.

    I know these should be obvious yet I’m surprised how often people:
    – forget about them
    – deny these are true

    Then they head towards wild guesses with some magic number applied, which may have some sense but not when used instead of real estimation.

  • Sure Shot Method to Improve Quality of Your Estimates

    That’s the old story: we suck at estimating. Our schedules tend to be wrong not only because there are unexpected issues but mostly because we underestimate effort needed to complete tasks. There’s one simple trick which allows improving quality of estimates. It’s simple. It’s reliable. It’s good. On the minus side you need some time to execute it.

    Split your tasks to small chunks.

    If a task lasts more than a couple of days it’s too big – split it. If it’s still too big – do it once again. Repeat. By the way that’s what agilists came with over years – initial size of user stories was intended to be a few weeks long, now it’s usually a few days at most.

    Why it works?

    • Smaller tasks are easier to process in our minds. As a result we understand better what we’re going to do. As a result we judge better what means are needed. As a result our estimates are better.

    • Smaller tasks limit uncertainty. In smaller room there are fewer places to hide. The fewer places to hide the fewer unpredicted issues there are. The fewer unpredicted issues the more exact are estimates.

    • Small tasks mean small estimates. A month-long task should be read as “pretty long but it’s hard to say exactly how long” task. Bigger numbers are just less precise. Splitting tasks ends up with smaller chunks of work. Small chunks of work end up with small-sized estimates. Small-sized estimates mean more precise estimates.

    As a bonus, during task-splitting exercise, you get better understanding what should be done and you early catch some problems which otherwise would appear much later and would be more costly to fix.

    And yes, the only thing you need is some time.

  • Evidence Based Scheduling – One More Way to Improve Your Estimates

    Somehow my recent discussions are mostly about estimating. Last discussion on PM Clinic happens to be on the very same subject. It reminded me about great technique which can improve your software estimates. It is called Evidence Based Scheduling and I’ve learned this from Joel Spolsky’s article.

    The basic concept is pretty simple. Jack the Developer gets the task. Actually a bunch of them. He delivers his estimates basing on his guts. Estimates are most likely crappy but at the moment it doesn’t matter much. As Jack does his work he tracks how much time he really spends on the task. It may happen it takes two days instead of planned 4-hour effort. Velocity for this task is 0,25 and it goes to the history of Jack. When Jack’s history is long enough you can use it to judge how crappy his estimates are.

    Evidence Based Scheduling uses Monte Carlo simulation which takes some effort to calculate results. However Joel brings some good news here:

    “Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected. (…) This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}”

    After completing a dozen of tasks you can get pretty much insight which number you should use to multiply Jack’s estimates to get something close to reality. Of course full-blown simulation will probably lead to better results but you get the idea.

    There’s one more gem in Joel’s posting which is worth stressing:

    “Fix bugs as you find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because you don’t know what bugs you’re going to have. When bugs are found in new code, charge the time to the original task that you implemented incorrectly. This will help EBS predict the time it takes to get fully debugged code, not just working code.”

    I know it brings quite a lot of effort for Jack the Developer, since sometimes he fixes bugs really fast and accounting time spent on each bug fix to proper original task adds enough hassle to be reluctant to do so. However the ends are worth means this time.

    I strongly recommend you reading whole article as it delivers all the details about Evidence Based Scheduling.