Do you need to forecast a new piece of work or the velocity of a new team?

This is a simple and quick exercise we ran through because we needed to help the PO collaborate with the team to provide a forecast for key stakeholders. This approach allowed us to forecast our velocity, which meant we could put a rough release plan together, and have an idea about what we might deliver, by when. The plan that will be refined as we get more empirical data on actual team velocity.

Using cards to forecast

We 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 its ‘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). 

To avoid anchoring, where one person pre-seeds with a suggest 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 members 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 options for ordering the backlog with the Product Owner. 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.  A single sprint can be done if short of time. Doing a couple will give you a better forecast and flesh out an ‘first pancake’ anomalies.

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!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s