Going with the flow

Two people are having a conversation about team productivity. Let’s call them A and B.

A: “How come your team is only delivering this number of Story Points?”
B: “The team delivered what they committed to in their Sprint Goal. Do you want the team to deliver more Story Points?”
A: “Yes, other teams are delivering way more Story Points at the same time. What is failing here?”
B: “What is the problem you are trying to solve?”
A: “I just know that, in your planning, you committed to far more Story Points than the ones your team is delivering!”
B: “So you would be happy if the team delivered more Story Points? Consider it done.”

So, A wants more Story Points delivered. Now, three possible thoughts might be stuck in your head right now:

This would never happen in any conversation.
I would just increase the number of Story Points and the situation would be solved.
I would coach person A and would try to help on understanding that Story Points are an indicator.

Sadly, this happens more commonly than you might think. So, the question is: what is out there that could help us with this type of discussion?

At the end of 2022, I stumbled upon Flow Metrics for Scrum Teams, by Daniel Vacanti and Will Seele. It explains Flow Metrics, and how they can fuel Monte Carlo Simulations (MCS), thus ditching Story Points. And what are MCS, do you ask? They allow you to forecast future scenarios with the data from your board, so Story Points would no longer be required to predict how much work can be placed inside a Sprint. Sounds cool, right?

However, Story Points are comfortable: everyone knows them, and everyone uses them. Story Points and Velocity are visible on boards and charts. But, if seen by people who do not understand the underlying concept behind it, we can easily land on a conversation such as the one above between A and B.

This raises two problems:

We are mixing time, an absolute estimation, with Story Points, a relative estimation. It is something that must not be done because it can lead to misalignment and poor expectations about timelines.
It raises a thought process where we want to maximize the number of Story Points when its main purpose is to see how much the team can commit to. Then the teams would estimate everything with 100 and the world would be a happier place.

Product teams need to focus on a product and the environment where it belongs, and the goal is to live up to its vision and mission, by bringing as much value as possible to those who use it, not necessarily the amount of Story Points that are completed per Sprint.

With all of this in mind, I started to question:

Why are we using Story Points?
What value are we getting from estimating a ticket with a number that we are not using for anything at all?
Is velocity something we should address to check performance?

I got excited with the discovery of this new approach and decided to suggest it to one of the teams where I’m a Scrum Master. The value I saw in this was to allow the team to focus more on the value of what they were delivering, rather than focusing on a number that wasn’t either being used nor would it be useful in any context of the work model that was defined.

My recommendation for this change is that you ensure that your Scrum team has the following pre-conditions:

Maturity – being a process that provides ownership, it requires a team that feels confident and has the maturity to embrace the process.
PBI slicing – it requires that the team embraces PBI slicing, to be able to fit them into their respective flows. It’s not about making it as granular as possible, but rather making them all as equal in terms of effort and complexity as possible, while making them fit your Sprint.
Team stability – it is important that the team has been stable for a while, both in people and roles, as well as in the scope of the product. Without that stability, the MCS results might be misleading you from the current reality, since they use historical data.
Safe environment – if we don’t foster safety in our working environment, no one will be willing to go away from their path to try something they are unfamiliar with.
Trust - if it weren’t for the trust that the whole team had in each other and on the change, this wouldn’t have been possible to try.
Willing to change - it’s not easy to change, especially when we are comfortable with something. The willingness to change to something new and see the associated value was vital for the experiment.
Knowledge – changing to Flow Metrics, associating it with MCS, was something that needed the full awareness of basic concepts from both topics.

We have been working like this for some months now and there are some outcomes that I would like to share:

We are more value-driven: We are aiming towards achievable Sprint Goals, and adding to the Sprints all the PBIs that will be able to fulfill it, thus being focused on the value and not on the amount of PBIs we deliver per Sprint.
We have more effective Refinement sessions: the team focuses more on why they are doing a certain PBI, rather than discussing it to have an estimation.
We have narrowed down PBIs: The team focuses on narrowing down PBIs so that they can fit into a Sprint, narrowing them down to their simplest form, while delivering value whenever possible.
We have more focused Sprint Plannings: We can choose a percentile of confidence for our Sprint, and based on the MCS, we forecast that we can deliver a certain amount of PBIs during our Sprint. This gives us the power to choose the PBIs we need to tackle while also knowing that we have a maximum number that is forecasted and backed up by the data of our own PBIs history.
People feel empowered to bring their vision of value: Since this started, people have been more empowered to bring the PBIs they feel are needed to fulfill the Sprint Goal. There’s a clear sense of focus and direction towards value and not numbers.

Regarding the theory of it all, namely what are the Flow Metrics and how does the algorithm of the Monte Carlo Simulation work, I can suggest reading the book that inspired this to become a reality - here

This approach might not fit your team, your ART, your portfolio, the reports you need to deliver, or even your way of working because as mentioned before, there are other ways of making it happen. But you can always question yourself and think about it.

You could improve the forecasts for all the PBIs, giving you a more realistic perception of when it is expected to have them completed, by using probabilistic approaches.

You could reduce the amount of time you spend in deciding between 3 or 5 Story Points and allow the team to focus on delivering value.

You could be using Flow Metrics with Monte Carlo Simulations.