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!

Losing your way with scaling

I was working with a very Agile experienced business unit recently, they were having some issues with “momentum” in building a new product offering.

Within the business unit, there were 5 teams working on the minimum viable product offering, and 2 teams working on other products. The teams had all participated in incepting the work, and by all accounts it was a successful inception. Each team consisted of established team members, who together were high-performing and agile knowledgeable. There was one product backlog where features were defined. Each team was capable of delivering all the way to production. All the elements for success, it seemed was there.

They were tackling a brand new build, new technology and 5 teams all working on the same product. They launched into their sprints full of energy and enthusiasm. However, after several sprints, no business value was delivered, and their enthusiasm was replaced by stress.

Continue reading “Losing your way with scaling”

Delivering Goal Orientated Scope

shutterstock_62162533-300x225

Abstract

My last blog was focused on what I learnt about the Scaled Agile Framework (SAFe). The theme quote for that blog was:

“If you’ve lost the ability to do small things then you’ve not scaled, you’ve just gotten big and slow!!!”

So what are the small things we should do well at the team level or at scale? Breaking the work up, avoiding big batches, and letting the work flow was one of the recommendations.

This blog will focus on the integration of techniques to deliver goal-orientated scope (that breaks up the work) and take a look at how you might start to visualise and manage the flow at the portfolio level.

Continue reading “Delivering Goal Orientated Scope”