What metrics would a great Scrum team want to generate and track the trend?
Is the necessary and sufficient set of metrics just velocity? No - I don't think that is enough. Can you help me define a short list of metrics, and the reasons for tracking them?
First let's lay out some ground rules. Who is responsible for generating the metrics? Are all metrics treated the same, e.g. should each metric have the same visibility? I'll state the the team is responsible for generating the metrics. This ensures that the metric has some minimun level of veracity. When the team believes that the metric does not tell the truth, they should make that visible and change how it is generated. This is process improvement. However not all metrics need be treated the same. Some should be published, some could stay internal to the team. As the level of trust and autonomy of the team increases the visibility of metrics should naturally become more transparent.
Here's a rough draft list - to get the conversation started. Add your comments and additional metrics. We will see if we can crowd source a great list.
Metrics for the Team
Metrics for the Program
Metrics for the Organization
See Also: a follow up post Metrics for the Scrum Team
Visualizing Agility: Agile Metrics that Matter by Jay Packlick
ODIM - a metric selection tool; by Larry Maccherone
Is the necessary and sufficient set of metrics just velocity? No - I don't think that is enough. Can you help me define a short list of metrics, and the reasons for tracking them?
First let's lay out some ground rules. Who is responsible for generating the metrics? Are all metrics treated the same, e.g. should each metric have the same visibility? I'll state the the team is responsible for generating the metrics. This ensures that the metric has some minimun level of veracity. When the team believes that the metric does not tell the truth, they should make that visible and change how it is generated. This is process improvement. However not all metrics need be treated the same. Some should be published, some could stay internal to the team. As the level of trust and autonomy of the team increases the visibility of metrics should naturally become more transparent.
Here's a rough draft list - to get the conversation started. Add your comments and additional metrics. We will see if we can crowd source a great list.
Metrics for the Team
- Story point velocity per sprint
- Projected capacity (in person-days) of next sprint
- Projected capability (in story points range) of next sprint
- Planned capability of the sprint (in story points)
- Story points done and accepted by PO of the sprint
- Story's started but not done (in story points and stories)
- Discovered work added to the backlog (in story points and stories)
- Scope increase/decrease during the sprint.
- Technical debt incurred this sprint (in story points)
- Cost of sprint
- Impediments discovered/removed/escalated
- Sprint - pass/fail
Metrics for the Program
- Release burn up (in story points)
- Scope increase/decrease (and reasons for change)
- Projected completion date range (optimistic & pessimistic)
- Impediments discovered/removed
- Risk mitigated, (unknown) risk realized
Metrics for the Organization
- Comparative Agility survey (compare your development organization against 7000+ others - where do you differ?)
See Also: a follow up post Metrics for the Scrum Team
Visualizing Agility: Agile Metrics that Matter by Jay Packlick
ODIM - a metric selection tool; by Larry Maccherone
Comments
1. Sprint - pass/fail
- What does it mean?
One or more (how many?) tasks of all in the iteration not accepted. OR
One or more (how many?) tasks were changed (proirity chage).
2. Metrics for the Program
- What does Program means?
Jan
Sprint - pass/fail. If project success is on time, on budget, with desired/planned features. Then could we not make that same statement about a sprint? Sprint success is within timebox, with existing team members, and planned stories delivered and accepted by the PO.
I typically distinguish a project from a program. There is quite a lot of vagueness around all the "P" words; project, program, portfolio, product, product line, etc. For me a project may be a one-off or a thing that lives inside a bigger program of projects; may be you call this a suite. Classic example is MS Office is a suite - or a program within MS to deliver desktop applications. Where as the whole MS portfolio contains Office and many other programs/suites.
- how team members are feeling about what they are doing - ok, mad, sad, tired
- features vs bug vs spikes cheets - to see how much work goes on non value adding stories
- definition of done - does it change and contain more details (more granulared)
- how customer feels about collaboration with the Team
% time the organization spends dealing with bugs (via support, sustaining, plain ole teams, management meetings, bug grooming sessions, and more). I have spent time with a couple of organizations where this number is greater than 50% of the capacity of the organization.
Happiness index (Henrick Kniberg is the first place I saw this). A simplified version that I came across a few months ago is to put a bin by the exit to the building. Beside the bin have two buckets of balls. One bucket red, the other green. On the way out the door at night people can grab which ever colour best matches their day and puts it into the bin. Bam. Big visible status about how people are feeling.