Agile metrics
•Download as PPTX, PDF•
2 likes•1,200 views
This document discusses various metrics that can be used for agile processes. It begins by defining common agile metrics like story points and velocity. It then discusses metrics for projects, iterations, team performance, business initiatives, and the enterprise. For projects, it recommends tracking metrics like baseline story points, story points completed, and story points remaining. For iterations, it suggests tracking actual versus projected velocity. For teams, goals include high completion rates, stabilizing velocity, and increasing velocity over time. The document also notes the limits of solely using velocity for measuring performance across multiple teams and at the executive level.
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Agile metrics
Similar to Agile metrics (20)
More from Richard Cheng
More from Richard Cheng (20)
Recently uploaded
Recently uploaded (20)
Agile metrics
- 1. Agile Metrics for Iterative Processes Agile Center of Excellence Richard K Cheng
- 2. Agenda Metrics for the project Metrics for the iteration Metrics for team performance Metrics for business initiatives and value Metrics for the enterprise 2
- 3. Common Agile Metrics Story points – Commonly used as a rough order of magnitude effort estimate for user stories (common in Scrum, other processes such as Kanban have metrics such as TTC) Projected velocity – Sum total of story points at the start of the iteration Actual velocity – The sum of completed stories points at the end of the iteration Hours? 3
- 4. Metrics for the project 4
- 5. Metrics for the project Baseline Story Point represent the remaining story points at the start of the iteration Story Point Updates represent story points that are added or removed to the overall project during the iteration Story Points Completed represent the story points completed for the iteration Cumulative Story Points Delivered represent total story points delivered to date Story Points Remaining represent the remaining story points at the end of the iteration Ideal Pace represent the pacing of the project based upon the story points remaining and estimated velocity of the team. In this example, I show it as it was at the start of the project, however, this should be updated often. Updating at the end of each iteration is ideal. 5
- 6. Metrics for the project 6 Project Burn Down / Burn Up Chart
- 7. Metrics for the iteration 7
- 8. Metrics for team performance For a Scrum team, key goals include: Achieving a high completion percentage (actual velocity / projected velocity) Stabilizing velocity Increasing velocity (after 1 and 2) 8
- 9. Metrics for team performance 9
- 10. Metrics for team performance 10
- 11. Metrics for team performance 11
- 12. Metrics for business initiatives 12 First Quarter Initiatives
- 13. Metrics for business value 13
- 14. Metrics across the enterprise Limits of velocity…. How do you measure teams against each other? What are the metrics for executives? 14
- 15. Contact Information 15 Richard K Cheng richard.cheng@excella.com http://www.excella.com http://www.Excella.com/blogs/richardcheng http://www.OneMoreAgileBlog.com http://www.onemoreagileblog.com/2009/07/common-agile-metrics.html
Editor's Notes
- For teams using an iterative Agile process, like Scrum, the most common metrics revolve around story points. Commonly, Scrum iterations (sprints) are comprised of a set of user stories with each user story given an estimate in story points. At the iteration level, the team commits to the stories they can complete in the iteration. The sum of the story points for these stories is the projected velocity for the iteration. Once the iteration is completed, the sum of the story points for all of the completed user stories is the team’s actual velocity for the iteration. Teams may also decompose stories into tasks and these tasks can be assigned estimates as well. These estimates may be hours to complete, due date, or any other applicable unit of measure. This decomposition and task level estimation is optional; I recommend this level of granularity to be based upon the needs of the team and project.Hours do it if it brings value without too much overhead
- Assumes your project has an end state
- displays the Project Burn Up and Project Burn Down chart for the same project. The Burn Up line displays the story points completed. The Burn Down line displays story points remaining. For organizations that are familiar with EVM type tracking, these Burn Up and Burn Down values can often be translated to EVM measures.Warning on burn down charts, does not give you whole picture
- The Iteration Burn Up and Iteration Burn Down chart is similar to the Project Burn Up and Project Burn Down charts, but the iteration chart tracks the work at an iteration level. In Figure 2 we are tracking the iteration based on hours completed and hours remaining. We can see that at the end of the iteration, there was 94 hours work of work that was not completed.
- Good for on-going teams without start and end
- Velocity good for team usage, bad for management usage
- Identify where the effort was spent