As I start to write this blog post, it is approaching the end of February and a colder spell of weather is on the horizon. This is exciting for my daughter as it brings with it the possibility of snow, but I also had to explain to her that sometimes the weather forecast is wrong and it is not a ‘weather commitment’.
One of the mast famous instances of the weather forecast being less than accurate occurred on 15th October 1987 when Michael Fish started his forecast with the words,
“Earlier on today apparently a woman rung the BBC and said that she heard a hurricane was on the way, well if your watching, don’t worry, there isn’t.”
People have been trying to predict the weather for thousands of years. The Babylonians used cloud formations as well as astrology to predict the weather in 650 BC, while in 350 BC Aristotle described weather patterns in Meterorologica. Let’s fast forward two millennia and the invention of the electric telegraph allowed for reports of weather conditions to be shared almost instantaneously, but it was not until their twentieth century where the advances in science and technology led to weather forecasts.
Today, multiple computer models use algorithms with thousands upon thousands of live and historical data points in order to predict what the weather will be like in the next hour, the next 24 hours, the day after tomorrow and beyond. But even with all this data and years of experience, guess what, they still get it wrong and forecasts are not 100% accurate.
The predictions that are made are more accurate than they were last year, the year before that, and I am sure they are more accurate than 1987. This will be down to learning what has gone before. Understanding the patterns and impact of events allows us to better understand what the future will hold, although I’m not sure if weather forecastsing will ever be as accurate as portrayed in Back to the Future Part II.
Given that my blog is Scrum/Agile related, you have probably already guessed where this is heading, yes the good old Sprint forecast.
During every Sprint Planning session we use empirical evidence to try and forecast the amount of work that we believe can be completed during the next Sprint. We will look at the amount of work that we were able to achieve in the last Sprint (and maybe the two or three Sprints before that). We will consider if the upcoming work is or the same size and/or complexity and/or requires the use of the same skill set or technology. We will consider if anyone has any planned leave or training. We will look at dependencies that there may be on other teams. We may even consider environment availability. The list is by no means everything that could be considered and there is the potential for it to be endless.
At the end of the Sprint Planning session we have our best guess at what could be achieved if all things remain equal, but as you know, and quoting Robert Burns,
“The best laid plans of mice and men often go awry.”
But why do things go awry? Well, during that Sprint Planning session a Scrum Team will be looking to plan activities for up to four weeks. It doesn’t matter how much time you spend planning, how much historical data and evidence you use, things will change. As and when they change the team may need to adapt the plan, which is what you should do as an agile team. However, that may mean you only deliver a proportion of what you originally thought possible.
In 1952 the Met Office started using computer models to generate a weather forecast. At that time a 24 hour forecast took four hours of computing time. Trials for operational forecasting began in the early 1960’s, but it was concluded that a more powerful and reliable computer was required. In 1965 a new computer using transistors was installed at a cost of £500,000, which was capable to 60,000 arithmetic operations per second, with a memory of 12,000 numbers. Installation started of the current Met Office supercomputer in 2015, with installation completed in 2017. This computer has 460,000 cores, 2 petabytes of memory, 24 petabytes of space for storing data, delivering a peak performance of 16 petaflops.
To date, no-one has been able to create a computer model or algorithm to allow us to more accurately forecast what a Scrum Team will be able to deliver in a Sprint, although if they did, I’m not sure if a Sprint forecasting model would need as much computing power as the Met Office’s supercomputer.
One thing to remember is that the further ahead that you forecast, the higher the probability that things will change and therefore accuracy may be affected. Hindsight is a wonderful thing, but you can use what you learn in this Sprint during your next and future Sprint Planning sessions. You always have the opportunity to get it right next time.
If nothing else, the one thing that you should always remember and communicate is that a weather forecast is not a ‘weather commitment, so why should a Sprint forecast be a ‘Sprint Commitment’?
So am I Michael Fish? I think that I am. There are Sprints where my Scrum Team has accurately predicted the amount of work that they were going to complete, but there have been other Sprints where we have been less than accurate. The thing that is important is that we learn more from these experiences in order to give us a better chance of being accurate next time.