The old Farmer Almanac was published in the year 1972, and the author of this book wanted it to be a little bit humorous while being highly useful. But most of the followers of the author thought that this book was around 80% accurate with its project forecasting.
This claim was tested in 1816 when the book mistakenly forecasted snow in July and August. This simple mistake turned the author of this book into a living legend when Mount Tambora erupted in 1815, and the global temperature dropped as much as 3 degrees celsius. Because of all these changes, it started snowing in July and August.
Well, it’s true that since then, project forecasting has improved a lot, and new technologies are being used to make forecasting as accurate as possible instead of relying on accidental mistakes. Not to mention, now everybody believes that agile software development is now ready to thrive on new forecasting techniques for narrowing down the decision-making power.
The current project forecasting techniques are not based on any estimates but are based on historical data. This helps the developers to save time and focus on what they do best.
Understanding forecasting
According to chapter 14 of Daniel Vacanti, forecasting calculates the future completion of items comprising both date range and an accurate probability. So, we can say that forecasting is made up of calculations that lead to a date range and an accurate probability of reaching this particular date range.
Since the future is unpredictable, we can never be 100% sure about it, even with the best forecasting technology. Hence the factor of probability has been included in forecasting. If you keep tabs on the weather forecast, you must have seen that the probability is attached to the weather condition on some days. Well, we can use the exact definition in the case of agile software development.
Instead of using the case of weather conditions, we use numbers and dates of completed PBIs in software development. And whenever we talk about probability in the case of agile software, we are talking about calculating value with probability.
Forecasting in agile software development
If you are thinking about understanding forecasting in agile software development in a much better way, you must prefer the ‘Agile Planning Onion’ that Mike Cohn proposed in 2009.
Every layer of the planning onion includes a different set of agile practices. You can take the example of the iteration layer. You can take advantage of the user story practice for keeping tabs on work at the Day layer. In addition to this, you can use tasks with estimates of hours to keep track of work. On both the ‘Day and the Iteration layers’, you will find the sprint burndown as the most used chart for keeping tabs on the progress of the task and forecasting the completion of work.
The Release and Product layer
Now, let’s move on to the Release or Product layer. People have used the prevalent impact mapping practice in the form of activity to get PBIs for all the upcoming releases and also for keeping tabs on work that ranges a few iterations. And in many cases, the Sunset graph is used as a means of forecasting the actual release.
The type of tool and practices you use for tracking and forecasting work entirely depends on where you stand on the onion layer. But most of the agile tools mentioned above are confining the overall decision-making process because they all run on deterministic dates. These tools point towards a specific date in the future, and there is no probability of showing an expression of confidence in these forecasts.
We already have seen that the future is unpredictable, and therefore, including the factor of probability is crucial for narrowing down our decision-making power.
During most agile forecasting conversations, the main topic keeps dangling between Day and Product layers of the onion. And in most of the cases, we have been using some of the most common estimation techniques like velocity, story points, and tasks with hours for forecasting at these layers.
There are many reasons why we have fallen short on even Day and Product Layers of onions. For example, all the tools that we use are based on estimates, not on historical data, all of them are deterministic, and in most cases, the forecasts are based on averages.
Indeed, we can never be 100% accurate with project forecasting. Still, by thriving on modern-day technologies and using the power of agile software development, we can narrow down our decision-making power based on predicting and being prepared for the future.