© 2019 Simply Agile Australia

Velocity, Stories and Systems Thinking!

“So, what is your team’s velocity?” As velocity is a commonly used metric to determine the workload of which a team is capable, you can expect the answer to this question to be of interest to those who control the funds and direct programs in organisations.

Let’s look at a definition -

“Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum.

Velocity is calculated at the end of the Sprint by totalling the Points for all fully completed User Stories.” https://www.scruminc.com/velocity/ In a world consumed (maybe even a little obsessed) with KPI’s, metrics and productivity – a high ‘velocity’ must be a sure sign of a productive team….?

Or is it…..?

A metric is often a great indicator that helps understand how progress is made in one specific dimension. However, any metric used in isolation without understanding its impact in the broader system can cause imbalances in the successful function of the system by impairing the benefits of synergy. This is where systems thinking techniques pay extra dividends, because it encourages balance to manage several parts of a broader system. (Agile teams are part of broader systems, and optimising a component doesn’t optimise the system).

Let’s use an example to look more closely at velocity as a metric.

Velocity works well as a key metric for the Product Owner and in many cases, a Project Manager, to determine the work a team can complete.

Looking at the table below, Team A and B, each complete 4 sprints, with their work measured in story points (sp). If you were to use velocity as a performance measure – which team would you say is performing better? Maybe even more importantly – which team is most effective?

Which team is performing better?

Clearly, Team A is getting through more work – more stories are in the “Done” box.

But….. How predictably is the work being completed? Can you rely on Team A to complete an important Feature? Would you give it to Team B instead who have not achieved the same volume but are very consistently delivering. Which is the better performing team? Remember, those funding projects love metrics!

This is a common situation….many organisations have this scenario right now in their teams.

If the metric is velocity and the answer is Team A is better as they are faster! Right? Hmmm…

But isn’t Team B better as they are more reliable and consistent – if you give them a 10 point story you can rely on them to complete it in the sprint! 

What velocity does best here, is not serve as a performance metric, but as a indicator that we need delve deeper across a range of other metrics which form the synergy of delivery. For example, is either team producing the right thing? How do elements of a system influence each other, in this case, velocity and value?

Enter causality……a core and fundamental systems thinking concept.

Value? “…value is only created when the product (increment) reaches the customers, it is useful to them and they start obtaining benefits from using it.” Scrum.org

So, value relates to a useful product. A product consisting of features which contain stories. But does a high velocity equal value? Does Team A produce more value than Team B? Well, Team A does have a higher velocity, but this does not automatically translate to higher value delivery – in fact, chasing velocity is a well-known anti-pattern –fast delivery can be at the expense of value creation!

Absolute velocity is a poor singular metric and is best used in conjunction with a focus on creating value. It is best used to achieve predictable delivery of value.

How then do both teams improve value delivery, predictably?  

One the most effect ways to achieve this is by INVESTING (Agile Alliance) in the creation of features and stories. Ensuring the work is independent, fits into an iteration and is created in vertical increments are the best ways to improve both velocity and value delivery.

We need to look to systems thinking principles to achieve this. Feedback loops are required to ensure the team is in synch with the product owner and organisation objectives.

A simple way is through the daily stand-up.

Ensure the stand-up discussion revolves around objectives and what the impediments (and their removal) are to achieve the goals.

·        What are the other drivers on the sizing of features and stories?

·        Are there multiple product owners the team is delivering for?

·        What does the system of creating features in your organisation look like?

·        How can you adjust these systems, thinking about what are the items that impact your agile teams…..

To drive value, optimise the system (all the teams in your organisation) - in SAFe terms the Agile Release Train....