[wirrbel]

I think there are a few red flags here with the way you are doing scrum:

I have never heard of individual velocity measurements, they are wrong and should not be measured. I also think that burndown charts and velocity are for the team, not the stakeholders. This is because story point estimation is volatile and turning it into a feedback loop would turn this estimation into a meaningless thing.

Thus, there is room for transparency with the stakeholders in the sprint review and the setup, all else should be in the team's responsibility.

Scrum guides are usually very specific about the fact that the daily scrum is not for reporting.

Devops work should be priced in as a story in the sprint. If the Product Owner does not want to give such a story the proper priority, you should transparently explain how lack of such work will decrease sprint velocity in future sprints.

[beckler]

Yes, I absolutely agree entirely.

The reason we had individual velocity measured, is because our management wanted to use it as a metric to determine our performance (Which I think is an awful method for measuring performance). I work in a digital agency, and our management tries to be very hands off, but then they do something like look at individual velocity and our amount of git commits to make sure we're working.

[wirrbel]

more red flags.

Taking commit counts as a measure (and line counts for the same reasons) is like evaluating a writer by the number of words they write without looking at the content. A writer could copy a phone book to get good reviews.

Individual velocities are bad for several reasons. (1) they discourage team work (2) they are inexact (story point estimates only work because we look at the sum of them for sprint planning, they work on average, not for individual stories). (3) there are better metrics available.

If your management wants you to do agile develoment, they should be there in the sprint review and look at last sprint's work.