Accurate task prediction - the holy grail of SW development

Oct 1 2017

Software task estimation is the process of predicting the time and effort required to complete tasks. Generally, estimates are used to help customers and managers to make decisions regarding how long it will take to accomplish project.
It's known that programmers often consider task estimation to be one of the most difficult things they do and consistently find themselves with inaccurate or underestimated task predictions. To handle this problem, they pad their estimates but in many cases their rough guesses are too low.
Regrettably, developers think that estimation is literally the equivalent of making a weather forecast. We can't expect a forecaster to a prediction for rain a month from now but still, it's useful when making near term forecast.

Software estimation is a process we make to predict the time and the efforts required to complete development tasks. Generally, it helps us to make ongoing decisions and predict the project deadline.

From a 10,000 foot view, estimation allows decision makers drawing up a roadmap and determine the time-to-completion of a project. Above all of that, it allows to better understand what is the predicted cost of the project and what is the time to market.

Why it's so hard to estimate

There are several factors that lead to skewed software estimates. From my own experience, I've seen all of the following (but I'm sure there's more):

  • Tasks granularly and non specific declarations - Task parameters are too ambiguous leading to a lot of debate on how it should be best implemented. Sometime the requirements are not clear enough or no in depth analysis has been conducted. From my point of view, this is the most common problem.
  • Task creates new tasks (nested tasks) - common with research tasks whose outcomes include some sort of solution to be built in the sprint.
  • Estimates made for unfamiliar technologies - trap for developers who inaccurately estimate the time to completion based on past experience with disparate platforms.
  • Working on unrelated tasks - i.e. context-switching. the tasks assigned to a developer are unrelated and force them to "spin up" for each one.
  • New features that are estimated may break some assumptions a developer made in previous implementations - Sometimes the developer is not aware of those assumptions .sometimes a refactor is performed or not considered when estimating.
  • Tasks with dependencies - developers become immediately blocked because precursor tasks are unfinished. This is especially problematic if the dependencies need to be finished by multiple people.
  • Research tasks with non-tangible outcomes - I've seen people take weeks to research/prototype some solution. If you don't constrain ambiguous tasks, you're inviting the task-taker to waste time.
  • One person estimating for another - common when developer is absent during planning and another does the estimation for them.
  • Peer pressure - engineer(s) press another to accomplish a task faster than they believe they can. This generally happens in high-stress environments when a stronger personality bullies a developer into working harder.
  • External pressure -  pressure by management to estimate less/more time-to-completion because of political and financial agenda.
  • Other tasks - You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.
  • The 'done' definition is probably unclear -  When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?
  • Programmer's pride - No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

None of these factors should surprise you. In fact, our software estimation processes are designed to deal with them. Our solution is to apply psychology and mathematical models to develop better estimates. In fact, I feel like we waste more effort (per capita) than any other industry analyzing our own development practices seeking better efficiencies.

Are there any ways to deal with estimation?

There are a number of estimation methodologies to choose from—and here we’re going to look at four tried-and-trusted ones that work for all types of projects.

Before listing the methodologies, I would like to emphasize the fact that most of the techniques are based on historical estimations and performance.  But how do we save and store the historical data? There are pretty much techniques to do it. At Spectory, in the planning meeting, the developers estimate the required hours to complete a task. The time estimate is saved on a task card using a predefined identity. So now we have the original time estimation. What about the real time required to complete the task? The relevant and the actual data is collected across the board so we can easily calculate the difference and derive the final estimation for a given feature.

Analogous Estimating

  • In this method, the estimation is based on historical data. Identical tasks that have been implemented in the past can be used as a reference.
  • For example: you need to implement an unsubscribe mechanism that applied on all of the emails sent from your system and sends a notification to the super user. In a previous project implementing an unsubscribe mechanism took 25 hours to develop and you estimate it would take about 5 more hours to implement and test the notification feature.  
  • In case you don't have a sufficient historical data, you can consult a developer who has experience with this area. In this case the initial estimate needs to go up by 20-30% depending on the complexity of the feature.

Three-point estimation

  • In this method, you should set three-point estimate for a task.
    • A – the best case or the optimistic estimate
    • M – the most likely estimate for completing the task
    • B – The worst likely estimate for completing the task

    In our example, to implement the unsubscribe mechanism, it will take 20 hours for the best case. The optimistic estimate for completing the task is 22 hours and the worst is 30 hours.

  • Now, to get the desired estimation, you can use one of the following formulas:
    • The simplest: ET = (a + m + b) / 3 so we will get (20+22+30)/3 = 24 hours.
    • To get more accurate use: ET = (a + 4m + b) / 6 will give us  23 hours.
    • The most complex that takes the standard deviation into account:
      • E = (a + 4m + b) / 6  in our case we get 23 hours
      • SD = (b – a) / 6  - we will get 1.6
      • ET = E + 2 x SD - we will get 23 + 2*1.6 = 26.2 hours

    • The Three-point estimation is the most accurate estimation technique that reduces the risk of over optimistic and over inflated estimate.

    Bottom-Up Estimating

    • Bottom up estimating is the process of estimating individual sub tasks and rolling them up into an overall task estimate.
    • This technique is used in conjunction with each or any of the other techniques. The three estimate types are used on individual sub tasks, which are then “rolled up” into the overall task.

    Parametric Estimating

    This technique is similar to the analogous estimating but adds an additional layer of accuracy by dividing the task into small measurable units.

    Finally, how do I become a great estimator? Estimation Guidelines!

    Good estimates can help you determine which proposed set of features might fit a budget or help determine the order of magnitude of the price for a piece of software. The moment a project starts the estimates and reality will start to diverge. Insights and features change, so the estimates should change with them if they need to stay somewhat accurate.

    Use these steps to make accurate time estimates:

    Understand What's Required

    • What is the goal of the task and what is the required scenario.
    • Start by identifying all of the work that needs to be done for the estimated task.

    Order the sub tasks

    • List all of the activities you identified in the order in which they need to be developed.
    • In this stage you don't need to provide an estimate.

    Decide Who You Need to Involve

    • Brainstorm the task with others
    • Get help from people who have prior experience with the task.

    Make Your Estimates

    • Choose one of the methods described above.
    • Estimate the time needed for each sub task rather than for the task a whole.


    I heard many developers saying that they don't need to estimate due to the fact that the project will anyway be off by a factor of 2-3 eventually. 
    I'm afraid to say but they are totally wrong! Time estimation is a major part of professionalism  and a key component of any software development project.
    We should aim to achieve the most accurate time estimation possible . 
    Using estimation technique as mentioned previously along side historical data analysis can lead you to an accurate and realistic estimation. 
    So now, when you estimate, follow the steps described in this article.

    Dan Y.
    Software Developer
    Back to Blog