Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  • about the Velocity and BurndownChart
  • that we can chose any type of metrics as long as they are team based and not individual, they do not push people to act awkwardly / counter productive (as you get what you reward)

Is there any other thing I can provide them in this regards? Have you got metrics other than velocity?

share|improve this question

closed as not constructive by gnat, Martijn Pieters, MichaelT, GlenH7, Jimmy Hoffa Mar 12 '13 at 17:40

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.

7  
Customer satisfaction? –  JeffO Sep 30 '11 at 16:22
    
yeah I told them about that too, but how do you mesure it? –  xsace Sep 30 '11 at 16:46
2  
On a scale of 1 to 10, 1 being very bad and 10 being very good... –  JeffO Sep 30 '11 at 17:32
    
These metrics are very relative in nature. Here is another blog. josephvargheese.wordpress.com/2013/02/17/… We started measuring some of them. Many of the above metrcis will not reflect complexity rather deals with size of the task. –  user84089 Mar 12 '13 at 15:43
add comment

4 Answers

up vote 2 down vote accepted

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

share|improve this answer
    
thanks, lot of good insights. About the Risk board, can you describe a bit how you estimate the severity or the impact on a project? For example, if say we are only 3 people in the team and I want to display our small size as a risk –  xsace Nov 9 '11 at 8:37
add comment

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.

share|improve this answer
1  
thanks for those inputs. I understand the Agile philosophy and that we need less emphasize on numbers. But management is formated to take decisions based on numbers. I don't blame them, this is the food they need to work. And I want to provide them some while sticking as much as possible to this Agile philosophy –  xsace Oct 1 '11 at 8:39
add comment

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.]

share|improve this answer
    
That's actually an intresting answer. I'm gonna set up a way to check that. thanks –  xsace Oct 1 '11 at 8:42
    
I upvoted because I think it's a valuable answer, though I'd make the (hopefully) obvious comment that tests should be good tests. Otherwise you just end out with a metric that's just as useful as Lines of Code. –  Wayne Werner Feb 29 '12 at 17:49
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.