Enhanced burn-down chart: How to estimate game production timelines more accurately and reliably

BCW Project Manager Gennady Khmyznikov spoke about the difference between the popular task burndown chart and its extended version, which eases navigation in the project roadmap.

There exists a persistent problem with predicting project deadlines. Rarely does any complex project finish within the initially projected timeframe.

This happens because new tasks arise during a project’s execution that are impossible to complete the project without, and it is nigh impossible to know about these tasks in advance.

Moreover, these tasks are usually connected to others and can therefore block, accelerate, or slow down the execution of other tasks. Predicting these obstacles at the start of a project isn't always possible, but it's highly desirable.

Levels of project deadline forecasting

In project management, there are three primary levels of complexity in project deadline forecasting:

The first: We work at a constant speed and no new work is added to us.

The second: We work at a constant speed and new work is added to us at a consistent rate.

The third: The speed of our work and the rate of new tasks being added are random variables. And these random variables are defined according to normal distribution, and the parameters of this distribution do not change over time.

The higher the level, the more accurately we can determine the project completion date, but the more complex the calculations become. All popular task trackers mainly use the first level of approximation. We went further and decided to aim for the third level using tables and mathematics.

More about each level

The first level: Suitable for a short forecasting period, for example, for sprints in Scrum. A well-known tool for such forecasting is the sprint burn-down chart - a chart of work burnout within a sprint. Figure 1 shows an example of such a chart, where: 

1. The total volume of tasks (story points or man-hours - it doesn't matter) 
2. The remaining workload for the current date 
3. The initial work completion plan

Figure 1 - Burn-down chart in Jira

The second level: We add information about the added work during the task execution process to the burn-down chart. As a result we get an enhanced burn-down chart. 

Such a tool is already better suited for long-term planning, as it allows you to see on the chart tasks that we did not take into account at the very beginning of the project. Specifically, we’re taking into account more uncertainties. While imperfect, this is a good tool for product / project burn-down.

To build such a chart, we use the same parameters as for the sprint burn-down, but additionally calculate the average rate of adding new work in each iteration and the standard deviation of this rate.

As a result, we get two trend lines - work done and added. Where they intersect is our work completion time. However, in forecasting project deadlines, where there are many unknowns, we cannot confidently talk about the exact completion date.

We can roughly estimate a window of time for when we will complete the project. To semi-accurately calculate that range of dates we use the third level of forecasting.

The third level: Helps determine the probability of completing a project on a certain date. As a result, we get a range of project completion dates. To do this, we use the trend lines for work done and new work added from the enhanced burn-down chart and apply the normal distribution of a random variable from statistics to them.

The normal distribution in this case shows the probability of how much work will be done in a given period of time. We chose this particular approach for calculation, since from a statistical point of view, added work is a random variable that is normally distributed.

How we used this on a Cubic Games Studio project

When implementing our new project at Cubic Games Studio, we decided to apply this forecasting tool for the first time. We prepared a backlog, evaluated tasks, and added the task formation date. When completing a task, we marked the completion date. As a result, using formulas on a separate tab, we were able to visualise our progress. How it worked,step by step.

We form a backlog. We then fix the date of adding to the backlog and the task estimate for the tasks we know. In the process of implementing the project, we will set the task completion date. If we have a new task, we add it and specify the date it was added to the backlog.

Figure 2 - Task backlog with estimates and completion dates

In the calculation table below, we have calculations for our sprints, which calculate our Velocity, standard deviation, average work addition, and standard deviation for this indicator.

Based on these data points, the probability is calculated, as well as the probability of completing all the work by a certain date plus the chances of completing the task within one or more sprints.

Figure 3 - Table of calculation of work performed for each sprint

Below, you can see a visualisation of project completion trend lines. After completing several sprints, we began to understand that we have a lot of additional workload, and the current speed of task implementation is low.

Understanding that we do not have time to implement everything we wanted on time, we make the decision to reduce the scope of our tasks in order to meet the original deadline.

If we had used a regular burn-down chart, we wouldn't fully understand why we are moving so slowly and any forecast about the completion of the project would have to come later.

Figure 4 - Extended project burn-down chart

Conclusion

The combination of the second and third levels of predictions helped us understand in time what is happening with our project, how much new work is appearing and where to limit ourselves in increasing the backlog.

That data allowed us to make timely management decisions and not fail the project. Even though such predictions can only work as estimates, and therefore might be seen as unpopular or inaccurate, we strongly recommend them as a very effective tool for project managers.

Managers will often predict an exact project implementation date, which almost never turns out to be accurate unless they’re extraordinarily experienced. The key advantage and uniqueness of this approach is that we can predict a range of dates and the probability of falling into them.

Moreover, with each iteration and changes to the data provided, these values change themselves, more accurately reflecting this new reality with the help of statistics. Of course, the tool is not a cure-all for project timing problems, but it is a good initial indicator and planning aid to assist timely decisions.

At Cubic Games, we used this tool for the first time to develop a project from scratch. Before that, we used a standard Gant chart. The enhanced burn-down chart provided us with greater transparency in terms of deadlines, so we will use it again when implementing new projects.