Agile Project Management | By Prashant Ram | Read time minutes
Organisations today are increasingly recognising the advantages and benefits of using the agile project management approach in their projects. While most large corporations see definite advantages in using the agile approach in project development, organisations are lost when it comes to using a well defined set of metrics that can be applied to these agile projects. Many organisations continue to use traditional project metrics and struggle to adapt various traditional techniques to the agile approach.
With the overwhelming ubiquity of agile project management there is an increasing need for a well structured, relevant and comprehensive set of metrics that would assist project managers, senior executives and project sponsors alike not just simply to track agile projects, but over time improve the agile process.
The agile metrics in use today suffer from a variety of shortcomings and drawbacks. A common issue observed in the current set of agile metrics out there is that they tend to mix up project and process metrics. Some talk about quality metrics while others focus only on project metrics. Very few also talk about process metrics. All the suggested approaches and metrics are fragmented over different authors leading to confusion and there is no clear presentation of a comprehensive metrics set that clearly distinguishes and defines project, process and product metrics.
Another primary shortcoming is that most of these metrics not agile-centric, but adaptations of traditional metrics. Today the most widely used and recognised agile project metrics are the Agile EVM. However it too suffers from this inherent shortcoming in that it is an intelligent attempt to adapt traditional metrics to somehow "fit" the agile model.
The solution lies in examining the Agile Manifesto and building metrics based on the tenets of agile project management principles.
|Metric||Metric Description||Metric Type||Agile Tenet|
|Sprint effort factor||Sprint effort factor = (Items in current sprint/total feature list) +[ ∑ (change requests from previous sprints)].|
Sprint effort factor should be evenly spread through all sprints.
|Project Metric||Working software over comprehensive documentation.|
|Sprint complexity factor||Sprint effort factor = ƒ (modules it interacts with # of interface points with other modules.||Project Metric||Working software over comprehensive documentation.|
|Change request effort||Change request effort = ƒ (adding new features + changing previously defined features - deliberate elimination of features).||Project Metric||Customer collaboration over contract negotiation.|
|Customer expectation baseline||Customer expectation baseline = (minimal set of expectation features from the sprint).||Project Metric||Customer collaboration over contract negotiation.|
|Impact on budget||Impact on budget = ƒ (change request effort, customer expectation baseline.||Project Metric||Customer collaboration over contract negotiation.|
|Reusability Factor X||Identifying reusable components in system = # of components added to library.|
The general guideline is that higher is better. This metric aims to identify more reusable components within the system.
|Product Metric||Responding to change over following a plan.|
|Reusability Factor Y||Reuse of reusable components in system = # of components reused from library.|
The general guideline is that higher is better. The rational is that good system architecture makes more use of reusable components leading to a higher quality product.
|Product Metric||Responding to change over following a plan|
|Facetime||Facetime = ƒ (time each developer is with business person and with other developers on whom their work is dependant).||Process Metric||Individual and interactions over processes and tools.|
The idea is not to simply disregard the currently used agile metrics, but rather to learn from their shortcomings, improve on their drawbacks, collate the best ideas from the ones proposed and combine them with ideas of agile centric approach, to develop a comprehensive metrics for organisations. The complete set of metrics including customer satisfaction metrics, reliability metrics, Earned Value Metrics and more process metrics are presented and discussed in greater detail in the paper "Comprehensive Agile Metrics: A Seminal Approach for Calculating Metrics in Agile Projects"
It is important to recognise that comprehensive Agile Metrics is the first set of metrics of its kind derived from an agile-centric approach and specially suited to the needs of Agile project management.
These agile metrics have been used in over two dozen projects within different organisations with a high degree of success measured in terms of customer satisfaction, product quality improvement and organisational 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.
We foresee that comprehensive Agile Metrics as described above will increasingly be used within organisations using Agile Project development and will soon become the industry standard set of metrics for Agile projects.
Prashant Ram is a Senior IT Executive based in New York. He has over 10 years of diverse experience in IT consulting with extensive experience in Strategic IT Management and Business Development. His Strategic IT initiatives include Organisation Process improvement through Agile Methodology, Six Sigma and CMM Level 5 practices. He is the author of numerous articles and papers on Agile Methodology and related paradigms. Prashant has an MBA from University of Massachusetts Dartmouth, and a Masters in Computer Science from the University of Massachusetts Dartmouth. He has a Bachelors in Engineering (Computer Science) from the University of Mumbai (Bombay).