This document discusses various metrics that can be used to measure performance on agile projects. It describes metrics in three main categories: work progress metrics like completed features and velocity, value metrics like financial value and earned business value, and process metrics like code analysis and test-driven development. Common metrics include the number of features delivered, story points completed per iteration, burn down/up charts, cycle time and test coverage. Metrics should provide information on trends, outcomes, business value, user needs and operational excellence.

1. Metrics for Agile projets

2. Agile I deas / Concepts + Product Mgr Release Mgt Team Product Backlog Release Backlog Iteration – Story Backlog Release Release Iteration – Story Backlog Agile Team Product Owner Agile Coach Product Features Stories Iterations Portfolio Program Project Feature 1 Arch 1 Feature 2 Arch 2 Feature 3 Arch 3

3. The Agile Package Iterative development Common coding standards Continuous integration Test driven development Team ownership Collaborative modeling Co-located teams Retrospectives Sustainable pace of development Daily stand-ups

4. Feature v/s Story Feature Feature is something about the product which may be sold to the end user; it may have a license attached or sold as bundle with the entire product. Example: PDF generation in MS word Story Story is the smallest unit of value/ requirement/ work which is visible to both project team and product owner. A story may have a description, validation criteria, complexity and business value.

5. A metric is a standard for measuring or evaluating something. A measure is a quantity, a proportion, or a qualitative comparison of some kind. Quantity : There are five items remaining out of ten in this iteration Proportion : This release required 20% less effort than last one Qualitative comparison : The new version of the software is easier to use than the old version. A metric can: Provide information on trends (Leads) Provides information on outcomes (Lags) Metrics Copyright © 2007-2009 Dave Nicolette

6. Selecting Metrics Future orientation How will changes to development processes affect the organization’s ability to deliver value and quality in the future? Business value How do application development projects contribute (directly or indirectly) to quantitative business benefits? User orientation How effective is the team in meeting the users’ needs? Operational excellence How does management measure development teams’ effectiveness? Velocity Features delivered vs. planned Post-iteration feedback/working demo Surveys, Customer-filed defects Earned business value Agile scorecard

7. Completed Features Objective : Goal of the project is to deliver a working software Measure : Easily measurable from the product backlog. Team can measure the running & tested features Trend: The number of features should increase with time When to measure: This is a continuous measure

8. Financial Value Objective : Attach a profitability value in monetary terms to every release/ iteration Measure : Profit = Income – Costs Trend: A steady or upward trend is desirable When to measure: Post release

9. Earned Business Value

10. Earned Business Value Objective : To measure the earned value to business with each delivery Measure : BV of Services  Issue  Book  Issue Book is calculated as: (1/1) * (4/10) * (8/13) * (5/5) * (2/10) ~= 5% BV (bucket) = BV (parent) * [Wt (bucket) / Wt (bucket) + ∑Wt (sibling) ] EBV is the summation of BV of all stories that have been coded and are up and running Trend: A steady or upward trend is desirable When to measure: Post release When the list of stories and features is finalized else BV may change

11. Velocity Velocity is The sum of the estimates of the stories that were completed in an iteration. It is an empirical observation of the team’s capacity to complete work per iteration. It is based on the team’s own sizing of work items It is comparable across different iterations for a given team on a given project Not: an estimate a target to aim for based on estimated or actual time dictated or imposed by anyone other than team members It is not comparable across teams & projects

12. Velocity Objective : Customer satisfaction Measure : Stories delivered/ Story points delivered or even ideal hours delivered; the key fact is that only completed items count Trend: Upward or stable trend is expected When to measure: This is a continuous measure

13. Burn Charts Burn Up chart How much work has been completed Burn Up chart How much work is left or still remains With each iteration remaining work should decrease and completed work should increase Normally iterations are plotted on X axis and Stories/ story points on the Y axis

14. Other Metrics Code Analysis : The use of tools to perform static code analysis can uncover many details like: Test coverage Primary areas of focus (eg JSPs or controllers) Method complexity Lines of code Documentation v/s code TDD : TDD compilation or execution of tests at build time can provide an inference on the current state of development Story Cycle Time: Number of iterations it takes to complete a story Cycle Time: Average time between delivery of completed work items

15. Earned Value Management Measuring actual value of integrated cost, schedule and scope against a baseline plan using Earned Value Management (EVM) metrics It compares the earned value (EV) with the planned value (PV)

16. EVM - Metrics

17. EVM - Agile Story points are seen as a measure of work planned v/s completed

18. Velocity Report Card

19. Thank You A lot of material is available over the Internet this presentation is a summarized view and probably presents a set of metrics which can be used in a project following the Agile principles; many thanks to all the people who have shared similar content