Agile dashboard
19 likes6,783 views
The document discusses various metrics that can be used to measure performance on Agile teams. It begins by explaining common metrics like velocity, running tested features, and bugs. It then covers metrics for each principle of the Agile manifesto, including customer satisfaction surveys to measure value, test coverage for quality, and burn up/down charts for delivery. Other metrics discussed include collaboration metrics like cumulative flow diagrams and team surveys, as well as continuous improvement metrics like team radar assessments. The document provides examples and references for further information.
Agile dashboard
- 1. The Agile Dashboard By Fadi Stephan
- 2. While we are waiting for the session to start, chat with your neighbors: – Are you on an Agile team? – How many members are on the team? – How long are your iterations? – What’s your team’s velocity? Chat with your Neighbors
- 3. ◊ Team’s capacity to complete work per iteration ◊ An Empirical observation ◊ A leading indicator ◊ For the entire team and not the individual member ◊ Different for each team ◊ Great for planning purposes ◊ Not an estimate ◊ Not a target Velocity
- 4. Fadi Stephan ◊ 15+ years of experience in software development ◊ Focused on Agile and Scrum since 2006 – Agile readiness & maturity assessments – Scrum coaching & mentoring – Scrum and Agile Engineering training ◊ Founder of the DC Software Craftsmanship User Group ◊ Organizer of the DC Scrum User Group
- 5. Why Measure?
- 7. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Principles
- 8. ◊ Read the principles behind the Agile manifesto ◊ For each principle determine – What should be measured? – How do we measure it? Agile Metrics
- 9. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11.The best architectures, requirements, and designs emerge from self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Principles
- 12. Value Quality Delivery Collaboration Continuous Improvement Dashboard Valuable Software Early and Continuous Welcome changing requirements Frequently Working together Motivated Face to face Constant pace Self organizing teams Technical Excellence Simplicity Working Software
- 13. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 7. Working software is the primary measure of progress. Value
- 14. Customer Satisfaction Survey ◊ How satisfied are you with the latest release? ◊ How likely are you to recommend the product to others?
- 15. ◊ Kano analysis ◊ Relative weighting ◊ Theme screening ◊ Theme scoring ◊ Financial (NPV, IRR, Discounted Payback Period) ◊ Relative Business Value Points ◊ Not at the Story level Business Value
- 16. Running Tested Features 0 5 10 15 20 25 30 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 RunningTestedFeatures Sprint Running Tested Features http://xprogramming.com/articles/jatrtsmetric/
- 17. Value Quality Delivery Collaboration Continuous Improvement Dashboard Customer Survey Business Value Velocity Running Tested Features
- 18. 7. Working software is the primary measure of progress. 9. Continuous attention to technical excellence and good design enhances agility. Quality
- 19. Bugs 0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 11 NumberofBugs Sprint Production Bugs High Meduim Low
- 23. Test Coverage 0 2 4 6 8 10 12 14 1 2 3 4 5 6 7 8 9 10 11 12 TestCoverage Sprint % Test Coverage
- 24. Passing Tests 0 200 400 600 800 1000 1200 1 2 3 4 5 6 7 8 9 10 11 12 Tests Sprint Total # of Passing Tests
- 25. Technical Debt
- 26. Value Quality Delivery Collaboration Continuous Improvement Dashboard Customer Survey Business Value Velocity Running Tested Features Production Bugs Quality Code Metrics Technical Debt
- 27. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 7. Working software is the primary measure of progress. Delivery
- 28. Velocity 0 10 20 30 40 50 60 70 80 1 2 3 4 5 6 7 8 9 10 11 12 StoryPoints Sprint Team Velocity
- 29. Story vs. Bug 0 2 4 6 8 10 12 14 16 18 20 1 2 3 4 5 6 7 8 9 10 Story Sprint Bug Story
- 30. Burndown Chart 0 50 100 150 200 250 300 0 1 2 3 4 5 6 7 8 9 10 11 Points Sprint Release Burndown Remaining Scope
- 31. Burnup Chart 0 50 100 150 200 250 300 0 1 2 3 4 5 6 7 8 9 10 11 12 Points Sprint Release Burnup Completed Scope
- 32. Value Quality Delivery Collaboration Continuous Improvement Dashboard Customer Survey Business Value Velocity Running Tested Features Production Bugs Quality Code Metrics Technical Debt Burnup Burndown
- 33. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to- face conversation. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 11. The best architectures, requirements, and designs emerge from self-organizing teams. Collaboration
- 34. Cumulative Flow diagram 0 50 100 150 200 250 300 1 2 3 4 5 6 7 8 9 10 Cumulative Flow Diagram Done QA In Progress Backlog WIP Lead Time
- 37. Value Quality Delivery Collaboration Continuous Improvement Dashboard Customer Survey Business Value Velocity Running Tested Features Production Bugs Quality Code Metrics Technical Debt Burnup Burndown CFD Niko-niko Calendar Team survey Adapted from http://www.slideshare.net/petebehrens/measuring-agility-top-5-metrics-and-myths
- 38. ◊ Focus on building features (not measuring) ◊ Take few actionable metrics ◊ A metric should lead to changing behavior ◊ Monitor trends Continuous Improvement
- 39. Team Radar Delivering Business Value Asking & Receiving Feedback Responding to Change Understanding Vision & Goal Planning Applying Technical Practices Working as a Team Continuously Improving Sprint 1 Team Self Assessment
- 40. Team Radar Delivering Business Value Asking & Receiving Feedback Responding to Change Understanding Vision & Goal Planning Applying Technical Practices Working as a Team Continuously Improving Sprint 5 Team Self Assessment
- 41. Reinforces Agile principles Measures outcome not output Follow trends not numbers Provides feedback regularly Fuels meaningful conversation Is easy to collect Heuristics http://www.innovel.net/wp-content/uploads/2007/07/appropriateagilemeasurementagilemetrics.pdf
- 43. Checklist
- 44. Velocity Checklist Question: How much software can my team deliver per iteration? Basis of Measurement: Story points or “ideal engineering hours” Assumptions: The team is delivering software every iteration Level and Usage: Forecasting amount of work team can complete Expected Trend: Affected by changing team members, obstacles, toolsets. Stabilizes with a dedicated team working together for a couple of iterations When to Use It: Track after each iteration When to Stop Using It: Team is stable and velocity is “known” How to Game It: Teams changes point estimates to meet target Warnings: Velocity is not the same as value http://www.innovel.net/wp- content/uploads/2007/07/appropriateagilemeasurementagilemetrics.pdf
- 45. Example 1 0 50 100 150 200 250 300 350 400 1 2 3 4 5 6 7 8 9 10 Hours Day Example 1: Burn Down http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf
- 46. Example 2 0 50 100 150 200 250 300 350 400 1 2 3 4 5 6 7 8 9 10 Hours Day Example 2: Sprint Burn Down http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf
- 47. Example 3 0 50 100 150 200 250 300 350 400 1 2 3 4 5 6 7 8 9 10 Hours Day Example 3: Sprint Burn Down http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf
- 48. Example 4 0 50 100 150 200 250 300 350 400 450 500 0 1 2 3 4 5 6 7 8 9 10 11 12 Points Sprint Example 4: Release Burndown Remaining Scope
- 49. Example 5 0 2 4 6 8 10 12 14 16 18 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 RTF Sprint Example 5: RTF http://xprogramming.com/articles/jatrtsmetric/
- 50. Example 6 0 50 100 150 200 250 1 2 3 4 5 6 7 8 9 10 Example 7: CFD Done QA In Progress Backlog
- 51. Example 7 0 50 100 150 200 250 1 2 3 4 5 6 7 8 9 10 Example 8: CFD Done QA In Progress Backlog
- 52. Contact
- 53. ◊ http://www.mountaingoatsoftware.com/blog/the-key-to-success-in-agile-metrics ◊ http://www.mountaingoatsoftware.com/articles/metrics-you-can-bet-on ◊ http://www.mountaingoatsoftware.com/blog/should-companies-measure-productivity-in- story-points-ideal-days ◊ http://xprogramming.com/xpmag/BigVisibleCharts ◊ http://xprogramming.com/articles/jatrtsmetric ◊ http://www.slideshare.net/petebehrens/measuring-agility-top-5-metrics-and-myths ◊ http://www.scrumsense.com/wp-content/uploads/2009/10/Measuring-for-Results-2- small.pdf ◊ http://jimhighsmith.com/beyond-scope-schedule-and-cost-the-agile-triangle ◊ http://agiletrail.com/2011/09/12/how-to-track-the-teams-mood-with-a-niko-niko-calendar ◊ http://www.innovel.net/wp- content/uploads/2007/07/appropriateagilemeasurementagilemetrics.pdf ◊ http://edn.embarcadero.com/article/32410 ◊ http://www.geocities.jp/nikonikocalendar/index_en.html ◊ http://www.agilejourneyman.com/2009/11/agile-project-metrics.html ◊ http://www.agilejourneyman.com/2009/10/metrics-in-agile-world.html ◊ http://www.agilejourneyman.com/2010/08/project-vital-signs.html References