Agile Metrics: It's Not All That Complicated


Published on

Presentation on agile reporting given by Katia Sullivan, VersionOne

Published in: Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Metrics/reporting pretty important in all project types.But Agile projects are a bit unique in some of the following perspectives(listed in slide)Automation around integration, builds, testing, etc is advocated in the Agile approachBecause it is one of the best ways to encourage agility - courage/confidence to make changes to support the business - if you don’t integrate and build it often it won’t ship - regression testing key since features are delivered completed in a sprint and automated regression on subsequent sprints to ensure nothing broke
  • Visibility: continuous, vs. at specific milestones or at the end of the project Adaptability: embraces change, vs. change-resistant Business Value: delivered every sprint, vs. at the end (hopefully) of the project Risk: driven out early, vs. deferred to the end of the project
  • There’s no earned value until a) there’s value, and b) somebody pays for it.
  • What does this tell us, comparatively speaking, about risk? quality? value in the eyes of the customer? change control? ROI
  • Burndown charts are more ‘real’ than gant charts as they show, in real-time, the affect of scope add / removal
  • Agile Metrics: It's Not All That Complicated

    1. 1. Agile MetricsIt‟s Not All That Complicated
    2. 2. © 2011 VersionOne 2Welcome – About your Trainer, Katia Sullivan• VersionOne Product Trainer and AgileCoach• Certified Scrum Master• Certified Scrum Product Owner• Led teams/Org‟s to agile adoption• 12 years experience in Project management– Requirements Management– Enterprise Architecture– Project Lead– Project Manager• Scrum Master for multiple teams acrossmultiple projects• United States Marine CorpsKatia.sullivan@versionone.com
    3. 3. © 2011 VersionOne 3Traditional MetricsTraditional Metrics typically look at: Percent Complete Lines of Code “Earned Value” Effort expended Number of test cases written/executed Etc.
    4. 4. © 2011 VersionOne 4Why are metrics/reporting essential to Agile projects? A constant evaluation of progress is used to redirect priorities Delivering on commitment to stakeholders to keep them informed in ameaningful manner “Embracing Change” requires insight on those changes Automation is encouraged
    5. 5. © 2011 VersionOne 5Agile Metrics differ from typical PM / SW Metrics Empirical – items are measurable. „Done or not done‟ – not „62.3% complete‟ Team understanding and acceptance of what isbeing measured Agile Metrics are used to deliver better software Agile metrics are not the end…they are thebeginning of a discussion or a decisionYou can still produce typical Project Management /Software Metrics, but they won‟t be as valuable.
    6. 6. © 2011 VersionOne 6Why Go Agile?Survey‟s Top 5
    7. 7. © 2011 VersionOne 7What Benefits are they Realizing?Survey‟s Top 5
    8. 8. © 2011 VersionOne 8A Different PerspectiveWith plan-driven approach, we have a plan going into a project, but wequickly lose sight of what‟s going onSo we create surrogate measures that we hope are representative of the truehealth of the project.Near the end of the project, the true state of the project emerges – were weright?
    9. 9. © 2011 VersionOne 9Agile Projects Deliver Value Every Iteration/ReleaseAnalysisDesignCodeTestDeployDoc$$AnalysisDesignCodeTestDeployDocAnalysisDesignCodeTestDeployDocAnalysisDesignCodeTestDeployDoc$$$$$$
    10. 10. © 2011 VersionOne 10The Business DilemmaReturn on Investment– What do we build?– How do we maximize return while limiting the investment?In order to have any Return,– Something of Value must be produced, plus– There must be an Opportunity to sell it
    11. 11. © 2011 VersionOne 11Throughput Accounting: The Heart of the Business Case for AgileIdea Develop TestValuable,WorkingFeaturesInvestment(-$)Operating Expense(-$)Throughput+$Operating Expense(-$)ReworkMaximize Throughput by removing system constraints whilelimiting Investment and Operating Expenses.
    12. 12. © 2011 VersionOne 12Planning: A ComparisonIterative AND Incremental!
    13. 13. © 2011 VersionOne 13Agile Roles in General Most Agile Methods professthe use of 3-5 different roles Many teams adopting Agilestruggle to determine wheretheir traditional role fits in anAgile landscape Every role fits into 3 Classes: Customer Facilitator Implementer
    14. 14. © 2011 VersionOne 14Key metrics/reportingSome key Agile Metrics include:• Burndowns• Velocity Trend• Counts and statuses of work items and defects• Team Member Load, Effort• Test Reports
    15. 15. © 2011 VersionOne 15Burndown• Burndown charts show the rate at which features are being completed(burned down)• Burndown charts are completed at iteration as well as release level (andlook the same)• Point in time measurement of amount of work left to be doneWill fluctuate as work is added / removed
    16. 16. © 2011 VersionOne 16Burndown
    17. 17. © 2011 VersionOne 17Velocity The rate at which a team can produce working software More accurately stated, it is measured in terms of the stabilizednumber of [estimation units] a team can deliver per sprint of agiven length, and with a given definition of Done.
    18. 18. © 2011 VersionOne 18Work Item Counts Offer insight to Capitalized Costs vs.Overhead Visualization of type of product releases orin progress Transparency to help with prioritization
    19. 19. © 2011 VersionOne 19Team Member Load/Effort Transparency into a members’ loadacross all projects Helps limit risk Visibility for teams to plan ad hocdepending on capacity adjustments Projections for peopleallocation Helps with budgeting
    20. 20. © 2011 VersionOne 20Trend Analysis Trend reports display general trends and changes over thecourse of time. Use trend reports to understand thedifferences introduced over the course of time Trend Reports Include: Estimate Trend Cumulative Flow Detail Estimate Test Status Issues Request Status Defect Status Velocity Trend Member Load
    21. 21. © 2011 VersionOne 21Burnup• Burnup charts are similar to burndown charts butwith total work and completion as separate datapoints• Burnup charts are completed at iteration as well asrelease level (and look the same)• Point in time measurement of amount of work leftto be doneWill fluctuate as work is added / removed
    22. 22. © 2011 VersionOne 22Burnup (Estimate Trend)• Use trend lines to show total work and deliveryprojections• Used by product owners to help with scope /date decisions as well as delivery team to see ifthey need cut items in a sprint
    23. 23. © 2011 VersionOne 23Cumulative Flow• The Cumulative Flow trend breaks out story and defect estimateby status and tracks that over the course of time within theselected project.• Use this graph to track the amount of estimate that is in eachstatus as teams work.
    24. 24. © 2011 VersionOne 24Tests and Defects How good is the quality we are developing? Do we need help in testing? Are we automating enough? Is it EVER Enough? Do we need to ask for testing help?
    25. 25. © 2011 VersionOne 25Metrics Good metrics affirm & reinforce Agileprinciples Metrics are to measure outcome, not output Reporting should measure trends, notnumbers Reports should provide fuel for meaningfulconversations This data should be easy to collect Good data is useful in gathering feedback on amore frequent basis Metrics should help define excellence vs. goodenough production