Forecasting New Work Exercise
This is a simple and quick exercise you can run through with your team and Product Owner to provide a quick forecast for stakeholders. This approach allows you to forecast velocity of a new team or piece of work. Using this you can produce a burn up, a rough release plan, and have a forecast on what the team might deliver, by when. These artefacts then can be refined as the team gets more empirical data on velocity, the rate in which the teams complete items.
I prefer to do this by using physical cards or printed backlogs items as it makes the exercise more interactive and collaborative. Teams tend to collaborate better when there is something to move and touch; we get the benefit of everyone’s participation.
Use a table or the floor. Layout rows for each of the three sprints. Ask the teams to forecast how much they might get done in each sprint by moving story cards into each sprint until the team agrees it's ‘full’. Once you have three sprints that team is happy with, total each row. Now calculate the average of the three rows - this is your forecast velocity. (Remember, it’s a forecast which means it’s based on the teams ‘best wrong guess’ in absence of empirical data).
Alternatively you can add items to a remote tool and add or import each item. You need space to move and sort the cards, so having them in a list format might not work so well.
To avoid anchoring, where one person pre-seeds with a suggested amount, you can do this exercise individually and then bring each person's forecast in for discussion to form a collective view.
It is always a good idea to produce an estimate range when dealing with complex work, agile adaptive planning will help you work with this uncertainty through short feedback loops. You can get a range by running the same exercise as above but asking the team to forecast for best and worst case, alternatively natural variances might emerge from each team member's individual forecast.
This will give you a ‘watermark’ to communicate to stakeholders. The lower estimate is work the team is confident they can achieve, the higher estimate is work they might achieve, and anything left over likely won’t be done.
A benefit we found of this approach was that it helped the team discuss the best way to order the backlog to achieve the goals set by the PO. We also refined and split some stories as our understanding grew.
It can be useful to hide the story points until after to avoid any pre-existing bias and then reveal the figures after for further discussion.
This should be a quick exercise - a timebox of an hour or two is appropriate and will keep the team ‘out of the weeds’ and at the appropriate level.
Always involve the whole team. You will have better estimates and collective ownership of the forecast.
This is one of several approaches to forecasting we use with teams, some we will share at a later date. What other tips or approaches do you use? - We’d love to hear from you!
If you need help with forecasting or agile delivery in general then please get in touch or subscribe to the mailing list.