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.

A team estimation session in action

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.

Previous
Previous

Scaling Multi Team Scrum Delivery with Jira

Next
Next

Running the Perth Code Dojo