FAST Forecasting is not actually part of the FAST framework, just as there is no concrete estimation method included the Scrum framework. It is here as a suggestion/option for forecasting in a FAST Agile environment.
We believe it to be the quickest and most lightweight forecasting tool/process and thus in keeping with the rest of FAST.
Here are the steps to FAST forecasting
- FAST Product Director will start a forecasting phase during the FAST meeting
- Only large items are estimated in FAST e.g. features
- The Product Director will describe the feature (or what they feel is remaining in the feature if it is already under way)
- The Product Director can take and answer a handful of questions from the tribe if more clarity is needed
- Developers are very careful not to anchor their size estimate to the room or their neighbours (i.e. they have been trained in FAST forecasting)
- Using the FAST Forecasting app on their mobile devices, each developer enters their estimate (rounded to an agreed amount e.g. in units of 50 or 20 man days)
- The FAST Forecasting tool merely averages the estimates and Voilà - you have sized the remaining work in your backlog in a matter of minutes
Of course, you can do this all manually using pieces of paper and a ballot system...
Ron Quartel came up with this idea when looking for a light weight forecasting method. He was first inspired by a method taught by Ash Maurya in his Lean Startup two day class and then again when reading Thinking, Fast and Slow by Daniel Kahnema. FAST Forecasting also has much in common with the spirit of Blink Estimation.
FAST estimation can't be any worse than anything else currently used by the agile community today and has the benefit of only taking a fraction of the time!
All estimates are lies in any case, so we don't recommend spending large amounts of time making them. Better to use something quick and then repeat as necessary during the release to refine the forecast.
#NoEstimates is a popular topic in the agile community today, but there a few reasons you still may need to use some forecasting model:
- as an indicator of the amount of remaining work
- to decide whether or not to include a feature or not (the Investment estimate in Return On Investment - ROI)
A lot of whether you need estimates or not depends on what release model your company and product/project has. If it is important to have an indicator of completion date or likelihood of hitting a promised date, then you may well need a way to forecast and track progress. Otherwise, I would recommend no-estimates. No-estimates can work well if you have a heartbeat release model or the release is feature based and not date driven.
Estimating and velocity (or flow rate) are inextricably linked. Read Sizing and Flow Rate to see how FAST recommends approaching these topics.