Agile teams often focus mainly on one, two or sometimes up to three sprints ahead. Anything further than that is likely to change so there’s no point putting in much additional effort beyond that point. I’m going to describe why this is not always the case and agile teams should in fact be aware of the wider context of what they are producing, the direction they need to be heading and where forecasting comes in.
What do you mean by ‘Forecast’?
By forecast I simply mean knowing how things may look in the future. Just as we want to know if it’s going to rain later so we can decide to dress accordingly, we want to know where the project is heading so we can make decisions before action is needed. Forecasting allows us to make a concious descision before something happens.
This doesn’t just have to be for a project. It can be for anything in development where there are boundries, for example a Program Increment in Scaled Agile.
We’re agile! Why Should We Forecast?
The main idea of being agile is so that scope can change depending on what’s important at the time and value can be released quickly. In contradiction to this, stakeholders are usually deeply interested in how long something is going to take and importantly how much it’s going to cost to ensure there’s a return on investment. If this is the case, it makes it difficult to let developers work at a pace they feel is sustainable, have unbiased estimates or have space to innovate and produce the best possible product.
However, it is understandable that often there is only a certain budget or time available, meaning that there’s a need to strike a balance between both fixed scope and costs vs being agile. The key to this is forecasting, and transparency with that forecast so everyone knows the direction we’re heading.
A good analogy is when you’re driving at night you can only see as far as your headlights shine, but you still know the end destination you are heading to even though you can’t see the whole way there.
We should aim to forecast the outcome of the project in terms of scope, time and budget. Being always concious of where we stand with with these three things allows us to make important decsions that influence the project.
For example – a Product Owner knows what the goals of the next two sprints are and that’s been relayed clearly to the team. One sprint in, a new item of scope comes to light, but the overall project deadline or available budget does not change. Being able to plug this new requirement into the forecast can show clearly the impact on budget and timescales this may have which can therefore be relayed to stakeholders.
A decision can now be made on what the next steps are before any action has been taken or there has been any impact on the team. Without the knowledge of a forecast this requirement may well have been accepted but the real impact of time and budget will not have been measured. On the other hand, the forecast may show that there is time available for it to be brought in.
Using this approach means we are still agile and accept change even when it’s late – but we are now aware of the impact of that change.
How Do I Produce a Forecast?
Before going any further it’s important to ask whose responsibility is it to maintain a project forecast?
In summary, it’s the entire team who need to contribute and be aware of it. However, it is mostly concerned with the Product Owner, who is responsible for the value of what is produced and liases with stakeholders or sponsors. This could also be facilitated and guided by the Scrum Master and must be influenced by the whole team. A good time to stop and reflect on the forecast is during the sprint review, with adjustments taking place during refinement.
In order to produce a forecast we need to know how much scope, time and budget are remaining
1. Scope – is the scope mostly known for the duration of the project, or are requirements likely to change?
2. Time – do we know the estimates of the remaining scope at an Epic or Feature level?
3. Budget – how much budget do we have to complete the project?
It’s important to highlight we don’t need a full answer to any of the 3 above, but we should have an indication. Scope, time and budget all go hand-in-hand and are interchangeable. For example, if a new item of scope is added, either
– More time and budget needs to be added
– An equivelant item needs to be removed
It’s perfectly normal and acceptable to not know all of the details. However usually teams are able to estimate items in the near future which contain the most detail, with not as specific estimates for work a few sprints away. This follows the ice-berg rule for a product backlog.
It’s best practice to revist the remaining estimates every one or two sprints and refine them accodingly, making the forecast more accurate.
Once we have the three items; scope, time and budget, we are able to plot a timeline of effort available per sprint, therefore what can be brought into the sprint and how long it may take to achieve everything in scope.
This should constantly be changing as we learn more about the project. If an estimate has increased, this should increase on the forecast and we are able to see the wider impact before the project falls behind. Therefore it’s good practice to revist the remaining estimates every one or two sprints and refine them accordingly, making the forecast more accurate.Summary
It’s very easy to loose sight of business context when the team are concentrating on building something on a sprint by sprint basis. However if we loose sight of the impact of costs and time on the overall business we are probably not producing the best product we could be. The best products are delivered on time and on budget as well as exceeding consumer expectations.
If you have any questions surrounding this blog or would like to know more, please get in touch.