All too often, I come across projects where the scrum team has only made preparations for the current sprint and perhaps some rough estimates for the requirements of a few more sprints further down the line. Although this backlog of preparations can range anywhere from relatively small to very large, teams that don’t effectively extend their estimates to future sprints will often run into difficulty when it comes to setting out a clear timeline for each task to be completed by. Forecasting can be used to overcome this problem as it allows product owners to plot a complete roadmap and manage stakeholder expectations.
Let’s explore this in more detail.
Before gathering the data needed to accurately forecast, it’s important to mark a distinction between forecasting for an individual sprint vs. the project backlog. As mentioned before, I often see teams focus solely on forecasting against an upcoming sprint—which is understandable, given that its completion takes priority—whilst neglecting the long-term requirements of the project backlog. However, by separating the forecasts into sprint and project backlog items and holding separate meetings for each, teams will quickly come to realise that there is a lot of value in preparing for both current and future sprints.
Let’s start with sprint forecasting
Every scrum team should hold a sprint planning meeting to properly forecast resources and deadlines for an upcoming sprint. During these meetings, items are usually split into smaller tasks to make estimations easier as the human brain makes better sense of small tasks than larger ones. Breaking things up like this is also an effective way to increase the likelihood of actually finishing all the items that have been promised.
Bringing the whole team together for this meeting not only makes it easier to coordinate tasks, but also ensures that everybody is working towards the same schedule—establishing a critical path, if you will. These plans can then be reviewed by several team members to check that the proposed estimates are as accurate as possible.
Now let’s review forecasting for the project backlog
Most teams (including my own) like to do this during a so-called ‘refinement meeting’, where the complete backlog and even new listed items can be reviewed. As with the sprint planning meeting, the whole team attends so that everybody has a chance to familiarise themselves with the items in question and take part in roundtable discussions about the project’s requirements. The goal of this meeting is to keep things short and to the point, rather than diving into minute details or trying to set out the entire requirement. The main focus should instead be on making rough estimations in story points that will help with prioritisation. The scrum master has the important role of managing the discussion and keeping the team from becoming too entangled in specifics.
As sprint planning meetings are typically where the more in-depth discussions take place, holding the ‘refinement meeting’ separately instead and inviting the entire team allows members—alongside the scrum master—to keep each other focused far more effectively.
Prioritisation
Having estimates of all the backlog items will help the product owner and the team review their priorities. While other variables (like business value) are included for the prioritisation, the estimates themselves are invaluable. After all, development costs are a price that needs to be paid and (unfortunately for me) I’ve yet to come across a project with an unlimited budget.
Forecasting
With the estimates and prioritisation in place, the product owner and the team can start handling forecasting and managing expectations. Common questions that are related to these subjects are:
- When is a specific requirement done?
- What will we have ready by summertime?
- Can we get these features by Christmas?
Let’s review all three of these common questions surrounding forecasting:
When is a specific requirement done?
For this question we need to understand the velocity of the team, the estimates of the backlog and a preliminary prioritisation of the complete backlog. These variables come together in the burn up chart shown below which uses an optimistic and pessimistic estimation to answer the fixed scope, variable time question of when a certain requirement will be completed by.
Assuming the prioritisation doesn’t change heavily and our velocity stays within the average of previous sprints (a basic rule is to take the last 3 sprints but you could compare more), we can draw a horizontal line of where a particular requirement should be prioritised to where on the timeline it should be delivered according to the current velocity. From this information, a product owner (unforeseen obstacles permitting) can then give a window of when this requirement is likely to be delivered, for example: between May and June.
What will we have ready by summertime?
This is fixed time, variable scope question where we again look at the complete backlog and review work rate velocity. As the image below shows, a product owner can work with the pessimistic or optimistic velocity trendline to give an indication of which stories will be finished by, for example, summertime or in the month of June.
Can we get these features by Christmas?
This fixed time, fixed scope question is the most interesting but also the most complex to answer. I can also say from personal experience; this is also the most common question scrum teams will be asked. The fixed time and fixed scope meet at a certain point in the graph. If this point falls within the velocity trendlines, then the answer will be positive. If it falls outside of it however (as displayed in the graph below), it means there is too much still left to complete before the proposed timeframe ends. In this scenario, the product owner has 2 options:
1. Reduce the scope to meet the time delivery requested
2. Increase the time to deliver the complete scope
It’s usually best to go for option 1 because, at the very least, something will be delivered even if the rest of the stories have to wait until a later date. However, while option 2 does come with the drawback of having nothing to deliver immediately, this may actually be preferable to the first option depending on the type of work involved and its requirements.
Hopefully this gave you an idea of how to integrate forecasting into your agile workstream and help both product owner and team to manage stakeholder expectation, ensuring that your whole program works more efficiently.
If you need any help with digital project management or are interested in learning more, feel free to contact us via the button below.
