Velocity of the team

Who do you think might use velocity data, and when might they calculate it and for what purpose?

Thank you for Your answer,

In my personal opinion it is PO responsibilities, because he need this data.

But I was confused with this question from "mplaza"

• Which two of the following are correct about the Development Team role?

And one of the answer for this question was "Calculates the velocity of the team"

So that is why I wrote my question about PO and Development team.

Velocity: an optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.

Now I got it, thanks for help Ian.

Perhaps the Development Team might use their latest velocity measurements to help them forecast how much work they should plan into a Sprint.

Velocity: an optional, but often used, indication of the average amount of Product Backlog

I find velocity really crucial in forecasting and billing. Without it such is very hard to do if company/stakeholders really requiring it. Velocity with combination of capacity does wonders.

Other usefulness of velocity is to see how your team improves over time and if there are problems as veloctiy is decreasing. On the end we are building self organized high performing teams.

If i am wrong please correct me.

Other usefulness of velocity is to see how your team improves over time and if there are problems as veloctiy is decreasing

Velocity is not a good measure of productivity, value or whether or not a Development Team is improving, in my opinion.  It simply helps a Development Team in Sprint Planning, as well as a Product Owner in forecasting a release.

I also don't believe that one metric ever tells the complete story.  What if velocity is improving by 10 percent, Sprint over Sprint?  Seems good, right?  Without other metrics that may not tell us everything.  Perhaps it turns out the team is under pressure to improve velocity, so they start cutting corners, such as leaving out unit tests.  Technical debt starts to rage out of control (which will eventually slow down the team, and create unhappy developers who have to work in sloppy code), and quality decreases as defects escape into production.  

Chris Belknap thank you for correcting me. Then end of the day the value that team brings each sprint is only measure we can use.

Denis - Measuring value is good.  Product Owners may come up with key performance indicators (KPIs), backed by metrics.  Scrum Teams may also measure flow (cycle time, throughput, work in progress), quality, and team health.  Development Teams may decide to dive even deeper in engineering metrics, such as cyclomatic complexity.  The important point is that the measurements are being used within the team in the spirit of continuous improvement.

I've chimed in on similar discussions about how I use Velocity for forecasting but I pair it with throughput (i.e. the number of stories that are actually being completed during a sprint).  I have worked with multiple teams where their velocity decreases over time because the team gets better at estimating as a group.  They all start to understand each other's "measurements" and come together to a more cohesive method of estimating.  But in every one of those cases their throughput has been relatively the same. I honestly can't explain it but I have theories based on subconscious that I'd be willing to share if anyone is interested. 

I have also seen how throughput will start to settle into a consistent value long before velocity.  Again I attribute it to the intangible "guessing" part of estimates. 

I do think velocity is a good tool for forecasting but not by itself.  I also do not advocate using velocity as a measurement of the team's value delivery or for predicting their ability to deliver in the future.  Velocity is a leading metric, you need some trailing metrics to help balance it. 

Hi All, does somebody know which one is NOT a responsibility of the Dev Team?