This post is a continuation of my efforts to identify metrics that could possibly reveal or capture if and to what degree an organization is delivering value in terms of each of the 12 agile principles.
So here’s principle #2:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The potential metrics for this principle got the most discussion – and disagreement – when I did this exercise with a group. The general takeaway was that the metrics you prioritize really depends on the maturity of the teams and organizations you’re exposed to.
When I worked with teams that were on the learning curve, about 80% of my efforts were in managing the sprint backlog, with the remaining on the release backlog. Most of our issues could be traced to requirements that were being included in sprint backlog even though weren’t fully articulated.
So I’ve used the following to track our effectiveness in addressing that issue. First, ensure that there is a clearly defined and agreed-upon process for adding scope to the sprint backlog. Then ensure that the process is strictly followed:
- % of the sprint backlog that is ready for the teams to start developing
- % of urgent mid-sprint requests that the team reviews and understands the impact on sprint delivery before accepting into the sprint, including the impact on velocity and burn-up charts
- Backlog flux – # of stories and total story points in the backlog at the start and end of each sprint
In instances where the teams and organizations are more mature in their agility, the following metrics could be revealing:
- % of stories that are reviewed and estimated by the team within one sprint of being placed into the backlog – indicates active grooming of the backlog
- Teams have multi-sprint burnup chart that shows total scope through the delivery of at least one entire project / slice (minimum of 4 sprints)
- % of epics that specify expected success metrics and where effectiveness is reviewed every sprint.
For teams that are working towards Dev Ops, the following could be a leading indicator of organizational dismantling of ingrained silo mentality:
- % of stories deployed to production with an ability to enable/disable at will (example by using a dormancy flag)
If anyone has used or is using these metrics and could provide additional insight, I’d love to hear about it.