Model the Future or Probability Theory in Action (based on Joel Spolsky’s article)

Model the Future or Probability Theory in Action (based on Joel Spolsky’s article)

Link to the original article explaining the principle of Evidence Based Scheduling (in the original Evidence Based Scheduling – EBS)

What problem did you manage to solve?

From the experience of working in the Frontend side by side with the Product Manager, before the next task came to work, I was interested in how much time it would take (suddenly). This, one might say, was stressful because such an assessment should touch on all possible “inhibiting” factors. I will list some of them:

  • Repeated clarification of details until the task becomes “transparent”

  • Breaks in work for various reasons

Yes, too abstract, and both points can be broken down into many factors, but the problem itself came down to taking them all into account implicitly. Conventionally, we will assume that the problem is localized (you will be surprised, but the details are really not that important).


To get a forecast for a specific task by terms, it is enough to have statistics on similar tasks, each of which should have: 1) date of start by the performer; 2) the date of the forecast from the performer; 3) the date of its actual completion (which must then be moved as the task is completed). Thus, the process of planning the terms of the feature before the developer takes the task to work should be based on two questions for him:

  1. What is the difficulty of the feature on a scale of 1 to 5?

  2. How much time do you need to complete it?

Next comes the question of self-control of an effective manager – to record the start and actual completion dates of this task (this is important!). From the moment the first task is completed, you can predict the future, taking into account the mistakes of the developer, based on previous experience with him: The more tasks gained in experience, the more accurate the forecast.

Yes, by the way, an important point! The performer’s forecast should not be based on analytically calculated program forecast (recursion will not be useful in this case either, if you understand what I mean).

The investigation is always the result of the decisions made

🔥 Demo

I wanted to collect feedback on the implementation demo version.

A few words about how I use this program in my work:

  1. I am creating a new task assigned to an executor who evaluates it everywhere:

    and) subjective assessment of complexity from 1 to 5 – perhaps this estimate can be adjusted based on the fact of completing the task (I think, based on the results of the retrospective at the time of completing the task – it’s time);

    b) subjective deadlines (initial date of promise from the executor) – there is no point in changing it later, because this is the basis of the method;

    c) fix the start date of execution – it must correspond to the fact of the start;

  2. If the task is not the first! I receive forecast according to the EBS method for the worst development optionit is the same term that should be voiced. Product to the Manager;

  3. I record the actual date of completion of the task – this is exactly the parameter that should be adjusted if the task required refinement for more accurate statistics and, as a result, a more accurate assessment of subsequent tasks.

Before setting the task, you can estimate how much the tested performer will “cheat”:

The main task is to display the most unfavorable schedule

Constructive criticism is welcome in the comments

Related posts