Tuesday, September 22, 2015

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

No comments: