Agile Metrics: It's Not All That Complicated
Download as PPTX, PDF•26 likes•32,680 views
This document discusses agile metrics and reporting. It begins by contrasting traditional metrics like percent complete with agile metrics that focus on whether work is done or not. Key agile metrics include burndowns, velocity, work item counts, team member load, and test reports. These metrics provide transparency and help teams maximize throughput. The document recommends metrics that affirm agile principles and provide data for meaningful conversations rather than just numbers.
![© 2011 VersionOne 17
Velocity
The rate at which a team can produce working software
More accurately stated, it is measured in terms of the stabilized
number of [estimation units] a team can deliver per sprint of a
given length, and with a given definition of Done.](https://image.slidesharecdn.com/agilemetricskatia-130531134222-phpapp02/85/Agile-Metrics-It-s-Not-All-That-Complicated-17-320.jpg)
Agile Metrics: It's Not All That Complicated
- 1. Agile Metrics It‟s Not All That Complicated
- 2. © 2011 VersionOne 2 Welcome – About your Trainer, Katia Sullivan • VersionOne Product Trainer and Agile Coach • 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 across multiple projects • United States Marine Corps [email protected] http://www.linkedin.com/in/agilekatia @katiasul2
- 3. © 2011 VersionOne 3 Traditional Metrics Traditional Metrics typically look at: Percent Complete Lines of Code “Earned Value” Effort expended Number of test cases written/executed Etc.
- 4. © 2011 VersionOne 4 Why 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 a meaningful manner “Embracing Change” requires insight on those changes Automation is encouraged
- 5. © 2011 VersionOne 5 Agile 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 is being measured Agile Metrics are used to deliver better software Agile metrics are not the end…they are the beginning of a discussion or a decision You can still produce typical Project Management / Software Metrics, but they won‟t be as valuable.
- 6. © 2011 VersionOne 6 Why Go Agile? Survey‟s Top 5
- 7. © 2011 VersionOne 7 What Benefits are they Realizing? Survey‟s Top 5
- 8. © 2011 VersionOne 8 A Different Perspective With plan-driven approach, we have a plan going into a project, but we quickly lose sight of what‟s going on So we create surrogate measures that we hope are representative of the true health of the project. Near the end of the project, the true state of the project emerges – were we right?
- 9. © 2011 VersionOne 9 Agile Projects Deliver Value Every Iteration/Release Analysis Design Code Test Deploy Doc $$ Analysis Design Code Test Deploy Doc Analysis Design Code Test Deploy Doc Analysis Design Code Test Deploy Doc $$$$$$
- 10. © 2011 VersionOne 10 The Business Dilemma Return 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. © 2011 VersionOne 11 Throughput Accounting: The Heart of the Business Case for Agile Idea Develop Test Valuable, Working Features Investment (-$) Operating Expense (-$) Throughput +$ Operating Expense (-$) Rework Maximize Throughput by removing system constraints while limiting Investment and Operating Expenses.
- 12. © 2011 VersionOne 12 Planning: A Comparison Iterative AND Incremental!
- 13. © 2011 VersionOne 13 Agile Roles in General http://kanemar.files.wordpress.com/ Most Agile Methods profess the use of 3-5 different roles Many teams adopting Agile struggle to determine where their traditional role fits in an Agile landscape Every role fits into 3 Classes: Customer Facilitator Implementer
- 14. © 2011 VersionOne 14 Key metrics/reporting Some key Agile Metrics include: • Burndowns • Velocity Trend • Counts and statuses of work items and defects • Team Member Load, Effort • Test Reports
- 15. © 2011 VersionOne 15 Burndown • Burndown charts show the rate at which features are being completed (burned down) • Burndown charts are completed at iteration as well as release level (and look the same) • Point in time measurement of amount of work left to be done Will fluctuate as work is added / removed
- 16. © 2011 VersionOne 16 Burndown
- 17. © 2011 VersionOne 17 Velocity The rate at which a team can produce working software More accurately stated, it is measured in terms of the stabilized number of [estimation units] a team can deliver per sprint of a given length, and with a given definition of Done.
- 18. © 2011 VersionOne 18 Work Item Counts Offer insight to Capitalized Costs vs. Overhead Visualization of type of product releases or in progress Transparency to help with prioritization
- 19. © 2011 VersionOne 19 Team Member Load/Effort Transparency into a members’ load across all projects Helps limit risk Visibility for teams to plan ad hoc depending on capacity adjustments Projections for people allocation Helps with budgeting
- 20. © 2011 VersionOne 20 Trend Analysis Trend reports display general trends and changes over the course of time. Use trend reports to understand the differences 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. © 2011 VersionOne 21 Burnup • Burnup charts are similar to burndown charts but with total work and completion as separate data points • Burnup charts are completed at iteration as well as release level (and look the same) • Point in time measurement of amount of work left to be done Will fluctuate as work is added / removed
- 22. © 2011 VersionOne 22 Burnup (Estimate Trend) • Use trend lines to show total work and delivery projections • Used by product owners to help with scope / date decisions as well as delivery team to see if they need cut items in a sprint
- 23. © 2011 VersionOne 23 Cumulative Flow • The Cumulative Flow trend breaks out story and defect estimate by status and tracks that over the course of time within the selected project. • Use this graph to track the amount of estimate that is in each status as teams work.
- 24. © 2011 VersionOne 24 Tests 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. © 2011 VersionOne 25 Metrics Good metrics affirm & reinforce Agile principles Metrics are to measure outcome, not output Reporting should measure trends, not numbers Reports should provide fuel for meaningful conversations This data should be easy to collect Good data is useful in gathering feedback on a more frequent basis Metrics should help define excellence vs. good enough production
Editor's Notes
- #4: 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
- #8: 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
- #10: There’s no earned value until a) there’s value, and b) somebody pays for it.
- #11: What does this tell us, comparatively speaking, about risk? quality? value in the eyes of the customer? change control? ROI
- #16: Burndown charts are more ‘real’ than gant charts as they show, in real-time, the affect of scope add / removal