CAMS Metrics Based on Roles

Role	CAMS Activities (Embedded in Process Maps)	Focus of the Metric	CAMS Metrics (Examples)
Project manager	Planning-requirement prioritization (scope)	Size of system	*The number of users in the system (includes the overall users and the number of concurrent users logging in at a given time) *The number of subsystems/components/packages in an overall solution. This provides the overall size of the system *The number of dependencies among subsystems/components/packages (indicating the complexity of the system)
	Planning-requirement prioritization (time)	Length of time	*The time schedule of the project—based on agreement on the scope and functionality of the project, number of iterations required, and the past project velocity number
	Planning-requirement prioritization (budget)	Budget or amount invested	*The sum total of investment in the project. The figure is extended further for returns on investment as well as risks associated with the project
	Monitoring team (performance)	Team Velocity	*The speed of delivery of a feature (user story) or, at a higher granularity, the use cases
			*The average efficiency of response to changes by the user (can also be extended to ascertain the defect removal rate)
	Risk management—collaborative(risk)	Qualitative	*The average potential impact of risks based on changes, user stories, etc.
		Quantitative	*The number of identified risks per user story
	Requirements—collaborative(requirement)	Complexity	*The number of user stories or features to be developed and the way in which they are related to higher granularity (e.g., use cases) *The number of dependencies among user stories
	Change Management—negotiable requirement (change)	Volatility	*The change frequency over unit period—this metric can be applied to many project situations including changes to the requirements (stories), changes to a piece of code (development), changes to designs, and changes in testing
Architect	Design-user feedback (architect)	Reusability	*Tolerance to change—this can be measured as the changes required to design as a result of changes in the requirements
Programmer	Coding/implementation-pair programming (code)	Complexity	The level of coupling between classes and the extent of dependencies among them. This metric has been popular in the object-oriented development approaches *The number of layers within an architecture/design solution. While a larger number of layers can indicate complexity, this is also an indication of the approach to manage such complexity
		Readability	*The compliance with standards and frameworks being used in a project
		Ownership	*The number of owners/contributors to a requirement, a feature, a design, a package, or a piece of code
Tester	Testing—continuous (deliverable)	Defect rate	*The number of defect per test run
		Performance	*The loss or gain in performance comparing the previous integration with the current one
	Quality assurance—user feedback (deliverable)	Acceptance	The level of user satisfaction in user acceptance testing
Customer	Change management—negotiable requirement (change)	Certainty	The number of TBD (to be decided) issues per user story (or use case)
All Roles	Communication—verbal communication	Understandable	The ease of expression and understanding of a feature or a solution
		Granularity	The details of documentation for a deliverable covering requirements, architecture, design, and testing associated with a piece of development
		Collaboration	The frequency of communication among team members and across teams The outcomes from each communication effort The ratio of time for communication to overall working time in a project

Taken from : The Art of Agile Practice: A Composite Approach for Projects and Organizations