We are starting a new project and the board/stakeholders are asking for metrics to check the team performance.
As a junior ScrumMaster I told them:
Is there any other thing I can provide them in this regards? Have you got metrics other than velocity?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
Not all necessarily "Scrum Specific" but keep in mind Scrum is a framework, and not a substitute for good Project Management practice :-) I'd suggest:
Features added/demo'ed since last report - Very compelling to tell stakeholders what is already part of the product!
Defects that "slip" out of the iteration - this is the rate of defects that get added to the system. Ideally, it will be zero, indicating that both testing is happening before existing the iteration boundary and any tech debt that either the product owner has accepted as part of the iteration or has crept into the system as tech debt. Hard to measure this and "fake it"
Team's definition of done - report any changes the team makes as they progress the sprint. This is less "number-y" but is a good indication that a Scrum team is learning as they develop the product and are adjusting their way of working. Less "intrusive" than asking for a report of "what went well/what needs to change"
Burndown against backlog for the release - Picture a stacked area chart (in Excel) the number of points the release starts with might be 100, and each sprint 10 (for example) get closed and maybe 5 get added. I like about 5-6 stacked areas : Accepted (closed), Removed (closed), Original (open), New-missed (open), New-from customers (open). Show this each iteration and you'll rapidly see how the team is doing.
Risk board - always always always report on the top risks the team identifies. I like showing the Top 5 risks in a quadrant view - http://yfrog.com/g0qy8p
Projected ship date - Prep the stakeholders that the first 2-3 iterations are going to have wide swings until the team settles on a velocity.
hth
Velocity is a poor metric for use by anyone outside the scrum team, because a story point is not a fixed unit. It's useful for estimating how much you can take on in the next sprint, and for calculating burndown, but if team members are chided for a low velocity, they will just make their story point estimates higher. Even if you're not trying to manipulate it, velocity can vary significantly for a host of other reasons, such as uncertainty, estimating skills improving over time, or estimating skills decreasing temporarily when working with unfamiliar technology.
In my opinion, burndown should be all they need. What better metric is there than to know if your team is on track to deliver the features the business values most, by the time those features are expected? They also have the opportunity to sit down with you every sprint and have those features demonstrated to them in person. If quality is starting to suffer, they will know it then if they take the demo seriously.
Remember, part of the agile manifesto is "Customer collaboration over contract negotiation." If you're doing it right, they won't need as many raw numbers to evaluate your performance, because they can evaluate your progress with their own eyes.
Is there any other thing I can provide them in this regards? Have you got metrics other than velocity?
Tests written/tests passed.
Both lines are (usually) non-decreasing.
The change in slope indicates a change in focus. More tests should be written early in a sprint. More tests should be passed in the middle of the sprint. A few resist solving and last until close to the end. Some never pass and are deferred.
When the number of tests rises late in a sprint it indicates things are being discovered. Either user stories were incomplete (or misleading) or new technology (and new API's) are introducing new test scenarios.
Tests the persistently won't pass (or won't stay passed) indicate fragile code or a poorly-defined used case.
There's a lot that can be learned from the tests-written-tests-passed counts.
[If you found this "dismissive" in any way, please flag it. Apparently, my answers are "dismissive." I've been warned and you should feel free to flag my dismissive answers.]
From a customer perspective, there's only one productivity metric that counts: business value delivered over time. Presumably, the Product Owner is already evaluating the relative business value of each backlog item when the backlog is prioritized. So it should be relatively easy to have a numeric value assigned to each backlog item representing its business value.
