Explaining velocity to the team

Looks reasonable enough to me, and probably not worth a damn given the situation you're in. From what you describe, the Product Owner is not being held to account for value.

If and when the wheels fall off, value is not delivered, and the PO is left clutching a bag of points, who will care? That's the line you need to connect, preferably before the fingers of blame are pointed.

The following is my opinion and others will have different views. 

The issue as I see it is that the measurement is being made based upon story points.  Story points are estimates (i.e. guesses) made at a point in time based upon the information that is available.  As new information is gained, those original estimates become worthless.  So consider that the Developers have assigned story points to a story during a refinement session on March 14th.  The Developers decide to pull the story into a Sprint that starts on April 14th.  That means the estimate is already 31 days old.  Then, as the Developers start working on the problem from the story description, they discover that work they did last Sprint impacts the work that is needed to implement this story.  It actually makes the work more difficult.  This means the original estimate is no longer accurate and is irrelevant. 

Now, consider the opposite.  The work done last Sprint makes that story easier to implement.  The same situation exists, the original estimate is no longer relevant. 

Using guesses to measure the teams ability to deliver consistent increments of value is inherently flawed. Velocity measured in this way is a leading indicator. 

You might suggest that using Flow Metrics like cycle time and throughput would provide a better option.  Flow metrics are trailing indicators that use actual work as the measure.  It is not uncommon for a 5 point story to take as long as a 3 point or an 8 point story to implement once work begins.  So that is not a completely accurate representation of the work performed.  However, if you measure the number of Sprint Backlog items completed during a Sprint or the time it takes to move a Product Backlog item from creation to completion, you get actual measurement of work. 

People tend to use Story Points as the measurement of Velocity because it is easy.  But it provides a false sense of improvement. It is easy for Developers to subconsciously change the way they "award points" when they see that they are being measured by them.  A small increase of points can make them look like they are doing more work. It is not as easy to do that with actual completion of problem statements (i.e. User Stories).

Hey there! Let me first start by saying that your concern is valid. It's essential to measure the value delivered by the team, not just the velocity.

Your definition of velocity is on point. Velocity is the measure of work completed by the team in a Sprint that can be used as an indicator for the future. It helps the team and the Product Owner to gauge how much work they can commit to in upcoming Sprints.

However, velocity shouldn't be considered the sole metric of success. The primary focus must be on delivering value to the customers. The team should prioritize work based on the intended value and implement the high-value items first. The value delivered must be considered the primary metric for success.

It's important to understand that velocity depends on several factors, such as the stability of the team, the knowledge of the product or technology, etc. Hence, it can vary from team to team and should not be used as a comparison between teams.

In summary, the velocity is a useful tool for the team to plan their work and for the Product Owner to forecast potential release. However, it should not be the only metric for success. The delivery of value to customers must be the primary focus.

I have just posted a question to this forum on whether the whole "sprint velocity" term in misleading. Unlike velocity in physics, that is a direction and a magnitude, sprint velocity is, in the best case, a pure magnitude.

What is this magnitude and why we should care about it so much? We should care about the direction we're following and the ability to regularly stop and review our current position to adjust our route.

It is actually rather easy to run fast in a wrong direction. How long would it take to hit the fence if the only thing product owner cares about is the speed? And is product owner's main concern to hit that fence as quickly as they can really?

I would agree with Iain - the problem is most probably that product owner is covering lack of understanding of the actual product improvements they managed to deliver with artificial metrics. In this case, I would switch to t-short sizes estimation or any other non-numeric estimation approach.

Thanks all for your answers!

@Ian & @Stanislav you're totally spot-on, I'd even add that the issue regarding value delivery is, to me, bigger than the PO. Digressing a bit from my initial post and adding a bit more context, the organization has decided to initiate an agile transformation, yet the reasons behind this transformation are unclear (is it to deliver value faster? To improve customer satisfaction? Because the agile mindset is pretty cool?). The team I'm working with was the pilot for this transformation, the first one to implement Scrum, the experiment to see if "agile and Scrum works". To me, one of the many issues is that the PO doesn't have a clear vision from the organization from which he can build product goals, which makes it hard (I'd even say impossible) to focus on delivering value...I'm currently working on two fronts : I've had workshops with the management to make the organization vision more transparent, and on the team level I'm trying to improve the Scrum theorical knowledge, hence my initial post.

@Daniel totally agree with your opinion, that's why in my definition is say that velocity depends on many factors, knowledge at the given moment being one, and that it can be used to forecast how much work can be done. When choosing a unit, if people want to go for story points I try to make it crystal clear that story points are just a relative measurement unit, just meaning that a 3pts item is less complex than a 8pts item; and that as you said, as we learn more throughout the life of the product, 8pts won't mean the same thing.