See also the Software Development Performance Index.
- Focus Factor - Ratio of Story Points accepted to the team's work capacity in the Sprint
- Adopted Work % - Ratio of work brought into the sprint after the original planning sessions to the work committed to in the original planning session.
- Found Work % - Ratio of incremental story points based on learning once in the sprint vs the original commitment for the Sprint.
- Commitment Accuracy % - Ratio of original commitment to total commitment
- Work Accepted % - Ratio of Accepted Story points at the end for the Sprint to the original commitment at the beginning of the Sprint.
- Contribute to team’s continuous improvement efforts to achieve higher levels of productivity
- Provide a normalized set of metrics for assessment of enterprise Agile performance
- At the beginning of the Sprint retrospective, summarize team performance and highlight areas of strong and weak performance. Specifically:
- Enter the value of work completed on User Stories In Progress and Completed (but not Accepted) at the end of the Sprint, in the Effort Not Accepted field
- *# Review Story Point estimates for all work (Accepted, Complete, In Progress) and re-estimate (revise up only, not down), if necessary, based on improved knowledge.
- Provides input in the the discussion portion of the Sprint Retrospective .
How can these metrics facilitate discussion in the Retrospective?
- Is the team trending in a certain direction over time for each metric?
- Are there good explanations for abnormal "spikes" for a given metric?
- Are stores not granular enough? How might they be able to be broken down into smaller, but still testable increments?
- Is the team trying to work too many separate things at once? Are there opportunities to "swarm" stories with more of the team's resources at once.
- Are items coming into the Sprint after the planning session agreed to by the entire team?
- Can the items coming into the Sprint after the planning session legitimately not wait until the next Sprint?
- For items that come into the Sprint after the planning session, are an equal number of Story Points removed from the Sprint to compensate for the added work?
- Is there anything that can be done to limit these disruptions?
- Do the stories that "grow" tend be of a certain size (typically on the large end of the spectrum)? If so, maybe they are too complex and need to be broken down into sub-Stories.
- Are the Stories appropriately groomed; meaning does the team really take the time to think through the requirements and high level steps necessary to properly assign a relative Story Point estimate?
- Is it your Done Criteria, or lack thereof, that is causing the team to underestimate what it will really take to complete a Story?
- Are you trying to equate story points to anticipated hours of effort rather than evaluating a story's complexity holistically against other "like" Stories?
- Is it Found Work, Adopted Work, or both that is throwing off your Commitment accuracy?