Why Sizing Epics Is Not Much Different Than Predicting Snowfall Accumulation
18 February 2016
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
As an Agile coach, I am always looking for analogies to better explain Agile practices. As I recently listened to the forecast of a severe winter storm approaching Philadelphia, I couldn't help but notice the similarities between predicting winter storm snow accumulations and estimating epics.
Unfortunately, most folks find it difficult to trust winter storm predictions by meteorologists. It seems everyone remembers when they were wrong and not when they were right. But let's be fair: Predicting Mother Nature is just as complex as is estimating in software development. After all, this is why they call it a "forecast."
I first heard of the latest winter storm exactly one week before its anticipated arrival. Meteorologists warned of its potential magnitude but hedged their bets by emphasizing the uncertainty of its path. They predicted the storm could bring anywhere from 6 to 24 inches of snow. My initial reaction was a smirking laugh, but given my experience with Agile development, I totally got it! The storm was a week away and there were many unknowns.
During the airing of the forecast, the meteorologists compared the characteristics of the storm to other major storms in the past, using the data as an input to determine the estimated snowfall. Sound familiar? This is no different from what Agile teams should do when estimating an epic — a large piece of work planned for the future. The team compares the new epic relative to other epics completed in the past. This relative sizing technique enables the team to use historical data and past experiences to better predict the effort necessary to deliver the new epic.
When predicting a winter storm, estimated snowfall is provided in a range. Ranges are needed in meteorology because there are many factors that contribute to a storm's strength that are unknown in advance. The further out a storm's predicted arrival, the more variability. Hence the 18-inch gap between the high and low boundaries for the winter storm snow accumulations that were a week away. A forecasted range of snow allows stakeholders, the impacted area's population, to get a sense of what to expect in terms of the storm's arrival and impact.
As this particular storm approached, the details became clearer, enabling meteorologists to tighten the range boundaries. Two days before the storm, the forecast was revised to a snow accumulation of 18 to 24 inches. As the snow arrived and more questions were answered, the meteorologists confidently committed to a total of 20 to 24 inches. Things could change during the course of the storm, so certainty of the total would not be known until the storm was over. The data they accumulated could be leveraged to better estimate future storms.
The approach should be no different when Agile teams estimate epics. When we start planning for future work, we need to consider the unknowns. This should be reflected in our estimates. I encourage teams to provide initial epic estimates in a range much like those that a meteorologist would use to predict snow accumulation. This allows stakeholders, including business, executives, and other support areas to gain a sense of what to expect in terms of time frames and cost, without the team putting in much effort.
As time passes, requirements, staffing needs, and necessary skill sets are clarified, resulting in the narrowing of the range of effort, just as happens when predicting snow accumulation. The team should wait until they are confident that all sources of variability have been addressed before they commit to the estimate. Given the complex nature of software development, we unfortunately cannot be certain of the effort until the task is complete. Teams should then use the data and learning experience to assist them in making better estimates in the future.
The phenomenon of narrowing your estimation range as more details become clear is known as the cone of uncertainty. This concept recognizes that initial estimates are more likely to be error prone due to variability of factors that are unknown at that point in time. According to the cone of uncertainty, estimates done at the initiation phase of a project are subject to inaccuracy at levels up to four times that of the original estimate. As time progresses, decisions are made that reduce variability, thus improving the accuracy of the revised estimate.
In summary, the complex nature of software development estimating and predicting a winter storm snow accumulation are rather similar. Agile teams should use the same approach as meteorologists when sizing an epic. By considering the variability of many factors within a software project, the Agile team should provide an estimate in a range that will narrow over time as more details are known. This will enable stakeholders to get a sense of the delivery time frame and cost, much as those expecting a winter storm snowfall will begin to get a sense of onset and impact.
Current rating: 4.5 (2 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.