Agile Metrics : A seminal approach for calculating Metrics in Agile Projects

6,583 views

Published on

A seminal approach for calculating Metrics in Agile Projects. Overview, Analysis and Detailed Description of a proposed set of comprehensive metrics for Agile Projects.

Published in: Technology
1 Comment
9 Likes
Statistics
Notes
  • Dear Prashant, Can we use these metrics to compare the performances of different agile projects so that we can baseline as well as benchmark the metrics periodically?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
6,583
On SlideShare
0
From Embeds
0
Number of Embeds
137
Actions
Shares
0
Downloads
390
Comments
1
Likes
9
Embeds 0
No embeds

No notes for slide

Agile Metrics : A seminal approach for calculating Metrics in Agile Projects

  1. 1. Agile Metrics A seminal approach for calculating Metrics in Agile Projects Overview, Analysis and Detailed Description of a proposed set of comprehensive metrics for Agile Projects. Ramm’s Agile Metrics
  2. 2. Rational for Agile Metrics • Organizations today are increasingly recognizing the advantages and benefits of using the agile project management • While most large corporations see definite advantages in using the agile approach in project development, organizations are lost when it comes to using a well defined set of metrics that can be applied to these Agile Projects
  3. 3. Rational for Agile Metrics The agile metrics in use today suffer from a variety of shortcomings and drawbacks. • Common issue observed in the current set of agile metrics out there is that they tend to mix up project and process metrics. • Proposed metrics are fragmented over different authors with no clear presentation of a comprehensive metrics • Most of these metrics not agile-centric but adaptations of traditional metrics.
  4. 4. Criteria for Comprehensive Agile Metrics The proposed set of Comprehensive Agile Metrics satisfy the following criteria • Practical, Easy to use, and implement in project. Easy to understand and present to project sponsors and upper management. • Relevant to Agile, not adapted or reworked from another method. • Agile Centric, Metrics are derived by keeping the tenets of Agile Manifesto in mind, instead bending to adapt traditional metrics to Agile framework. • Meaningful , provide data and metric that allows one to track projects, measure success of the process and quality of the product. • Comprehensive, in that it addresses all aspects of agile methodology project management, product and process
  5. 5. The Agile Metrics • RAMM’s Agile Metrics are built on the tenets of Agile Project management principles • The proposed Agile metrics learn from the shortcomings of previous metrics, improve on their drawbacks, collate the best ideas from the ones proposed and combine them with ideas of agile centric approach. • Will soon become the industry standard for metrics for Agile projects
  6. 6. The Agile Metrics These metrics are divided into separate metrics for projects, process and product and allow organizations not just simply to measure snapshots and status of individual projects but measure and improve their project processes and also satisfy customers and stakeholders by measurably improving the quality of the product. – Process Metrics: How well is the Agile Process being applied and managed across projects. – Project Metrics: Helps in tracking the progress of the project. Primarily indicator of project cost and schedule variance. – Product Metrics: How good is the inherent quality of the product developed. How can quality of the product be improved.
  7. 7. The Agile Metrics • The process metrics are meant for higher management and are meant to be indicative of how well the Agile processes are being run across the projects within an organization. It gives clear indications of the pain points and tracks the areas of improvements within the Agile process. • The process metrics are also helpful to the project manager in understanding what can be done better and in improving the agile processes applied to their project. • Product metrics give a good indication of the quality of the system being developed. Note that the concepts of Cyclomatic Complexity and KLOC are outdated and have not evolved for last decade to incorporate the rapid evolution in Project Management methodologies
  8. 8. Agile Process Metrics • Sprint Effort Factor • Sprint Complexity Factor • Sprint Complexity-Effort Matrix • Degree of Change Optional Metrics • Facetime • Customer Expectation Baseline
  9. 9. Agile Product Metrics • Reusability Factor X • Reusability Factor Y
  10. 10. Sprint Effort Factor Sprint Effort Factor measures the effort required in a Sprint Cycle as percentage of features targeted in current sprint versus the time allotted to accomplish these items. Sprint Effort Factor = [ (# of features in current Sprint) / (# of features in Release) / (# of weeks in Sprint) ]* 100 where, – (# of features in current Sprint) = [(# of features in previous sprint) + (# of change requests)] – (# of change request) = [(# of new features added) - (# of future features deliberately or consequently eliminated)] • Deliberate elimination means that the client removes that feature from the release list. • Consequential elimination means that feature becomes redundant and not necessary as a result of some new feature added or changed.
  11. 11. Sprint Effort Factor
  12. 12. Sprint Complexity Measures the complexity of the current sprint as a function of Number of interface points with parts of the system previously developed and a subjective Subject Complexity Factor. Sprint Complexity = [ (Reusability Factor X) + (Other interface points) ] *(SubjectComplexityFactor) • Subject Complexity factor attempts to integrate the inherent complexity of the subject matter being implemented. It may be assigned a value between 0 < and 1, with 1 being a Sprint cycle that deals with the most complex subject matter. • Note that the use of (Subject Complexity Factor) is optional and it may not be used in some projects. It is purely a subjective value assigned by the SMEs and the Project Manager to factor in the inherent complexity of the subject matter being implemented.
  13. 13. Sprint Complexity-Effort Matrix • The sprint complexity-effort matrix gives the project manager a clear indication of whether a proposed sprint in trying to accomplish too many items or too few items. • The Y-axis of the matrix plots the following for each sprint (Sprint Complexity Factor * Sprint Effort Factor). • The X-axis of the matrix plots the Durations of the Sprints. • The Project Managers’ objective should be to aim for an even distribution of the Sprint points in the green area of the graph.
  14. 14. Sprint Complexity-Effort Matrix The sprint complexity-effort matrix gives the project manager a clear indication of whether a proposed sprint in trying to accomplish too many items or too few items. • If the sprint lies in the Red area it indicates that too much is being tried to be accomplished in a short period of time, which may lead to team stress and missed deadlines. • If the sprint lies in the Yellow area it indicates that the sprint has a lot of lag built in and too few items are being accomplished. • The objective of the project manager is to keep the complexity- effort value in the Green area which indicates a good balance between the tasks intended in the Sprint and the time allotted to accomplish those tasks.
  15. 15. Degree of Change Measures and tracks requirements refinements made by client at the end of each Sprint. It is an indicator and measure of fine tuning of the requirements to create a product that better meets the customer expectations. Degree of Change = [new features added + existing features refined + deliberate (or consequential) removal of feature) ] / (# of features in Release (adjusted)) • Too low a number indicates that the client has not changed features through the sprint which might indicate that the end customer may not be giving sufficient feedback. • Too high a number indicates that the initial requirements need to be revisited since they are continuously being changed. The number should be too high or too low.
  16. 16. Degree of Change
  17. 17. Reusability Factor X Reusability Factor X measures how well the product is being developed. A higher number indicates that the system is well designed and the architect has identified patterns and functionalities that can be reused. This also indicates a modular approach and development of system libraries which in turn reduces the amount of rework that would need to be done in the later sprints. Reusability Factor X = (# of components added to the system library) The number is typically higher side specially during the initial Sprint cycles of a Release when the base modules of the system are being developed and base framework of reusable components are being identified. The number should significantly drop during the later Sprints of a release.
  18. 18. Reusability Factor Y Reusability Factor Y complements Reusability Factor X in that it attempts to reuse as much of the components from the libraries created in previous Sprints. Reusability Factor Y = (# of components reused from the system library) The number will follow the reverse trend of its counterpart and will be significantly lower during the initial Sprints of a Release, but will progressively rise in the later sprints as more and more components developed in the earlier sprints are being reused.
  19. 19. Relationship between Reusability Factor X and Reusability Factor Y The following graph shows the relation between the Reusability Factor X and Reusability Factor Y. Note that as previously mentioned as the Reusability Factor X drops its counterpart increases. Similarly Reusability Factor Y is higher in the later sprints that in the initial Sprints.
  20. 20. Facetime This metric is a direct result of the Agile Tenet “Business people and developers must work together daily throughout the project” and “Individuals and interactions over processes and tools”. Facetime metric = f(Clique Density) The facetime metrics is intended as a process metric to calculate the amount of interpersonal interaction between the team members and between the project stakeholders and the time.
  21. 21. Facetime Team members, Project manager, SMEs and other project stake holders are seen as individual points in a graph. The interaction time spent between the project members is indicated using numbers on the graph edges. Higher number indicates higher interaction between the associated members and groups. The graph gives a clear indication of cohesiveness of the various stakeholders. As indicated in the graph above there should be a higher clique density within the team and a sparse clique density between SMEs and individual team members. This is an optional metric that may be used in projects where the teams are co-located.
  22. 22. Customer Expectation Baseline Another optional process metric is how well the sprints meet the customers’ minimal expectations. It is indicative of how well the sprint meets and/or surpasses the base expectations of the customer in terms of the features promised for the sprint. Customer Expectation Baseline = (actual minimal features delivered / minimal features for the Sprint) • This simple metric plots the difference between the minimal number of features and the actual features delivered at the end of the sprint. Note that it is imperative that all the minimal features be met and even if there are additional features completed in the sprint but these additional features are not part of the identified minimal feature set, the metric goes into the negative. • The minimal feature set is identified at the beginning of the sprint.
  23. 23. Agile Project Metrics • Agile SPI (Schedule Performance Index) • Agile CPI (Cost Performance Index) • Agile EV (Earned Value) • Agile PV (Planned Value) • Agile AC (Actual Cost) • Burnup Chart • Burndown Chart Note that the Agile Project Metrics are adapted from the AgileEVM set of metrics which is currently the most widely used and recognized suite of metrics in Agile projects.
  24. 24. Agile Project Metrics AgileEV = [(Actual # of features completed in sprint) + ∑(# features completed from previous sprints – modified features)]/ [Total # of features in the release] AgilePV = [(Planned # of features completed in sprint) + ∑(# features completed from previous sprints – modified features)]/ [Total # of features in the release (adjusted)] AgileAC = Actual Cost incurred at end of the Sprint.
  25. 25. Agile Project Metrics • AgileSPI = AgileEV/AgilePV – The Agile Schedule Performance Index is similar to the SPI proposed in the AgileEVM metrics. – It is meant to provide a clear snapshot of the Schedule variance in Agile Projects. – A value of < 1, indicates that the project is currently behind schedule • AgileCPI = AgileEV/AgileAC – The Agile Cost Performance Index is similar to the CPI proposed in the AgileEVM metrics. – A value of < 1, indicates that the project is currently behind budget
  26. 26. Agile Project Metrics • BurnUp Chart BurnUp chart is a simply project metric that plots the number of features accomplished till date. • BurnDown Chart Burn down charts are classic sprint tracking charts that provide a snapshot of the features that have been completed or being worked on in the current sprint.
  27. 27. Afterword • The RAMM Agile Metrics have been used in over two dozen projects within different organizations with a high degree of success measured in terms of customer satisfaction, product quality improvement and organizational process improvement. • Projects consisted of team sizes varying from 5-7 member teams to 10-15 member teams using the Agile Scrum methodology. • Overall project timelines varied from projects having 3-4 month deliverable schedule to projects well over the 12-14 month mark.

×