Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

How we forecast in Mingle Plus

Mingle Plus includes a useful tool - the forecast chart to help teams gain more insight into when they may be done. By highlighting different scope change scenarios, the chart helps teams better understand likely delivery dates based on how scope may change.

The Mingle team have found the forecasting chart a useful tool, as have some of our customers. That said, it's worth discussing how we generate the chart, both to better understand the logic behind what is being communicated, and to collect feedback on how to improve the way we calculate forecasts.

Our forecast macro is produced in three general steps: 1) we first look at the actual scope line and the actual burn-up; 2) we then calculate a projected burn-up based on actual data and a few simplifying assumptions (discussed in detail below); and 3) we simulate three scope change scenarios to forecast when we may be done.

1: Start with your actual burn-up


2: Determine your projected burn-up

First let's call out our simplifying assumptions: our previous blogpost described how we use a linear regression to calculate our projected burn-up line. The linear regression represents our average velocity and since we want to project into the future we shift the regression line to begin at the last known actual completion point. This method ignores sources of variability that affect velocity such as technical debt, customer availability and sick days. Practically speaking then, the trend line used to project the rate at which we complete work is more reliable for teams with a relatively stable velocity.

That we use an average velocity instead of the most recent velocity or some average of the most recent 'n' iterations/sprints is one of the more common comments we receive. We know that teams can stabilize at a new velocity over time and so being able to look at the most recent velocity or the velocity for the most recent 'n' iterations may be more accurate in some scenarios. We've had the opportunity to test this hypothesis against real data from past projects, and while our sample set is far from statistically significant, we didn't see compelling evidence to switch how we produce a projected burn-up line...yet.


3. How do different scope change scenarios affect the done date?

The final step in producing our forecast chart is looking at how scope changes may affect our done date. For the forecast chart we default to looking at no change in remaining scope, a 50% increase in remaining scope and a 150% increase in remaining scope.

In the figure below, the remaining scope is two points so a 50% increase in remaining scope is one and a 150% increase in remaining scope is three points. These different scope scenarios are plotted to yield three different forecast dates. Teams can then pick a date range that represents their best estimate on how scope may change.

For example, early on in the project we may anticipate that a lot of scope may be added to the project, in which case we may choose a date range between the 50% and 150% dates. Conversely (and hopefully), as we move further on in the project we may expect that there should be little to no changes in remaining scope, in which case we may choose to look at the date range between no scope change and a 50% increase in scope.



Why 0%, 50% and 150%?

When deciding on the ranges we’d use for the different scope scenarios we started with notes from DeMarco and Lister. When referencing the window of probable delivery they mentioned that “For the software industry as a whole, window size is in the range of 150 to 200 percent of (the not-before date)” [1]. While this reference is meant to address all contributors to schedule risk we made a simplifying assumption to add all schedule risk to changes in scope. We tested these numbers against a sample of known historical projects and got reasonable results with our sample set. While we were satisfied that our treatment of remaining scope was reasonable for our sample set, it should be noted that this method is based primarily on anecdotal evidence so team members should still use a good dose of judgement when using the forecast chart.

Want more?

Mingle Plus also includes other tools to enable you to flexibly manage your programs such as alerts, timelines and progress bars.

[1] Waltzing with Bears - DeMarco & Lister - Dorset House - 2003

Discover more about Mingle Plus features and try it today.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights