6. Big corporations seem to die…
Source: The Shift Index – Deloitte Centre for the Edge, 2011
7. Why Do We Measure?
To take action when deviating from what
we expect or desire.
Where there is no standard there can be no Kaizen.
–Taiichi Ohno
8. The Perfect Mix
Metrics are a key aspect of every
(software) improvement process.
The iterative foundation of Scrum makes
collecting measurements and responding
to them extremely straightforward.
9. Which metrics?
Goals
• What do we
want to
achief?
Questions
• Why?
Metrics
• Metrics
should be
able to show
results
An approach commonly used in software is the GQM (quality)
approach.
10. GQM approach
Improve the results of our Scrum implementation
from the business point of view
How satisfied is our Scrum Team and Stakeholder?
Happiness Metric, Net Promoter Score
Are we constantly improving our team maturity?
Ratio of Successful Sprints, Focus Factor, Estimation Accuracy,
Reliability
Is our development effort aligned with the business?
Return on Investment, Total Business Value Earned
Are we increasing the quantity of work delivered?
Velocity, Process Efficiency, Sprint Burn down, Release Burn up
Is the quality of the work compliant to the norm?
Defect Count, Severity of Faults
11. How satisfied is our Scrum Team and Stakeholder?
For stakeholders:
For the team
12. Are we constantly improving our team maturity?
The percentage of
time the team
spends on
committed work
Number of
succesfull sprints /
Total number of
sprints
13. Is our development effort aligned with the business?
Return on Investment & Total Business Value
Earned
500
600
700
800
900
1000
1100
0
5
10
15
20
25
30
35
40
45
50
1 2 3 4 5 6 7 8
StoryPoints Velocity vs. Total Business Value Earned
Velocity
Total Business Value Earned
20. Metric Comment Desired
Release Planning
Plan is available Release plan is made with PO and stakeholders Yes
Tracking is done?
Release plan need to be updated after every
sprint release Yes
Visibility to all stakeholders
Updated release plan is communicated with PO
and all stakeholders Yes
Sprint Planning
Time required for planning
How much time team spent to close on sprint
goals. 4 hours
Lead time from sprint start When did sprint start? 0
% of Stories complied to DOR How many sprint goals 100%
# of in sprint changes
Number of changes to sprint goals during
execution 0
SCRUM events
Stand ups done in right way?
Followed all guidelines of a standup , “Every
day” Yes
Refinement/Grooming done? Refined backlog w/ atlease 2 sprints visibility Yes
Pre demos for all demo able stories? Ideal Case : This should be part of DoD Yes
Demo done in right way? As per guidelines Yes
Retrospective done in right way? Outcome - prioritized list of impediments Yes
Communication
Demo Script Sent one day in advance Yes
Sprint delivery email w/Quality
numbers
- Code metrics
- Resolved impediments
- Key refactored items To be sent after demo / deployment Yes
Impediments
Open
Closed in last sprint
# of new things tried Atleast 1
SCRUM
21. Metric Desired
Unit Test coverage
Over all Above 85%
Last sprint Above 85%
Automated functional test coverage
Over all Above 85%
Last sprint Above 85%
CI
Automated deployments Yes
Build time Less than 10 mins
Programming basics
Pair programming %
Code reviews 100%
TDD TBD
Design improvements/Refactoring As much as required
Engineering practices
22. Metric Desired
Open Bugs 0
Last sprint bugs 0
Code metrics As per guidelines
Quality
Metric Desired
Average lead time to close impediments
Estimation efficiency of stories 100%
Execution efficiency of stories 100%
Process efficiency
