Target Velocity Achievement as Scrum Team Metrics

Storypoints are a planning aid. After planning, storypoints could just as well be removed from the stories (just a thought ;)). Next to that, storypoints can give some insights into increasing velocity, so, if teams become more self organazing and familiar with eachother and the product, an increase in number of storypoints executed per sprint can be seen.

Keep in mind that if SP are used as statistics, they can be tweaked to meet improvement criteria. Hypothetically, a team can double the amount of storypoints for the same amount of work, and show upper management they are twice as good, just saying ;) 

 

Also keep in mind that when people become ill, there is nothing wrong with the teams's ability to execute, only the capacity. Other factors may apply...

SP... its a planning  aid, not a real metric.

For me, I try to use two metrics for team performance: 1) Ability to meet the Sprint Goal within the Sprint timebox and 2) Team happiness.

1) Sprint goal is not the same as cramming the sprint full of stories, and all stories must be done at the end (common mistake), its all about setting the goal and making sure all the work needed to meeting the Sprint Goal is Done (according to the Definition of Done)

 2) Happiness is all about collaboration, trust, transparency, inspecting and adapting (improving)

 

Hi Xander Ladage. Thanks for your response.

There's really no pressure for the team to achieve a high velocity. The metrics measures if the team achieves their planned velocity every Sprint. Let's say, if the team said that will deliver 10 SPs at the start of the Sprint but only finished 5 SPs at the end of Sprint, the teams Target Velocity Achievement is 50%. If finished 10 SPs, then their Target Velocity Achievement is 100%.

So what I'm asking is is this a good way to measure the performance of our teams and why or why not?

The two metrics you mentioned is definitely worth a try, but not every team in the organization uses Sprint Goals so for now, not everyone on the organization will have a buy in to that. I know it is a vital practice in Scrum, and I personally try my best to influence the teams I'm working with to use it but some in some cases, I myself am having a hard time using it for some situations (especially for non-related items).

I´m currently using 2 metrics:

- Velocity, as a planning tool, nothing more (as mentioned before).

- Cycle time, for having an idea of the performance and the find bottlenecks easier. 

During the Dailys we are using a task burn down chart (with comments of disruptions) as well and together with the cycle time, we have a good approach of achieving the sprint commitment. If not, we also have an idea why. 

Hope that helps. 

So what I'm asking is is this a good way to measure the performance of our teams and why or why not?

Estimation itself means rough calculation , approximation or best guess. You can get better in estimations as your experience grows with the product. But at the end it still remains the rough calculation.

Story point is one of the technique used for estimation based on abstract number or number series to classify the size of the feature by comparing them. Only real entity which is delivered in the sprints is a feature or a story itself. If you agree on this , then how accurate do you think is your team's performance metric is which are based on these abstract numbers ? If they can not accurate then why you need this metric ? 

but not every team in the organization uses Sprint Goals

How is the purpose of the sprint and therefore the work done made transparent to the team and stakeholders?

How is Scrum followed and can progress be inspected and adapted during the sprint without it?

so for now, not everyone on the organization will have a buy in to that

How is making the progress of this team transparent, depending on how other teams are making their work transparent?

I personally try my best to influence the teams I'm working with to use it

Influencing? How does that work? What does the team feel about it? What would they say is the benefit for them?

I myself am having a hard time using it for some situations (especially for non-related items)

Did you ask yourself what the real problem is here? is it formulating a Sprint Goal? Or maybe is it your work is unrelated and therefore have no specific purpose? Or is it something else?

From my point of view, usage of velocity in that way looks like some kind of "Cargo Cult". Measure what matters, not everything that you possibly can.



The purpose of Sprint is directed by the Sprint Goal. Does it mean that every PBI has to contribute to it? No. Is it healthy? It depends.

Check out additional ways to measure with Evidence Based Management measurements: https://www.scrum.org/resources/evidence-based-management

 I can't seem to find the right argument that I can share to my colleagues so I can convince them to drop this metric and maybe find another way to measure success.

Clint,

Your Scrum Master 'senses' are correct in viewing velocity measurements as a poor team performance metric.

A few things to consider:

• You do not mention the Sprint Goal, and yet that is the most critical item that your team should be concerned about.   Are they consistently meeting their Sprint Goals?
• Measuring velocity in any manner is just an execution metric.   It's telling you how much "stuff" your team is producing each sprint, and judging their growth by whether they're able to generate more output sprint to sprint.   The bottom line is that it might all be just "stuff" (output), without an ability to determine the value of what they're producing, and whether they're delighting their customers/users (outcomes)
• Cycle Time, Lead Time, and Cumulative Flow metrics are all very good measurements around a Scrum Team's efficiency
• Determine how you can assign a value-based number to the items your Scrum Team is working on, to assess the actual value your team is creating.   Also, see if customer assessments/feedback can give you additional insights into the value you are producing and what you may want to focus on next

Hope this is helpful.   Good luck.

Currently, one way we measure success is if we consistently achieve our target velocity for the Sprint.

Let’s put “success” to one side for the moment. How does the Product Owner measure value?

I guess we can explore Lead Time, Cycle Time, and Cumulative Flow for our metrics.

I also want our metrics to reflect the value we are giving to our customers and their satisfaction, but I just don't know how we should measure that.

By the way, these metrics that we have right now are being used to check the performance of the team. This is also something that I think we as an organization would need to revisit.

Hey Ian Mitchell. That's a really interesting question I need to ask my Product Owners. I think I may have an idea why I need to ask it, but what do I do after knowing how they measure value?

With regards to using Sprint Goal, our organization is still probably on a mindset that a Sprint Goal means a list of items that is committed to be finished in the Sprint.

Having unrelated items within a Sprint can mean that a team is not focused on a single outcome. Or maybe they just don't know how to formulate a statement that can be used as a Sprint Goal. It is a challenge, but we are working on it. But what do we do especially when we understand that the business needs unrelated items to be delivered? Do we stop the delivery til we can't formulate a Sprint Goal? Or do we create a statement that goes like... "Satisfy the customer"?

I think I may have an idea why I need to ask it, but what do I do after knowing how they measure value?

Can success be measured without knowing what value is?