Archive for Agile Metrics

Agile Metrics – Technical/ Code Quality Measures

Posted in Agile Metrics with tags on April 1, 2008 by vikramadhiman
I have been discussing with a few friends about their favorite Agile Metrics. The metrics can be divided into following categories:
  • Technical/ Code related measures
  • Business Perspective
  • Process Perspective
Here is a list we have come up with to measure Code Quality:
  • Code Coverage : Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing
  • Cohesion¬†: In computer programming, cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as “high cohesion” or “low cohesion” when being discussed. Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability whereas low cohesion is associated with undesirable traits such as being difficult to maintain, difficult to test, difficult to reuse, and even difficult to understand.
  • Low Coupling: In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.
  • Cyclomatic Complexity: Cyclomatic complexity is a software metric (measurement). It is used to measure the complexity of a program. It directly measures the number of linearly independent paths through a program’s source code.
  • Number of unit test cases per feature or method or class. Minimum 4 test cases per feature ( +ve, -ve and stress, system interaction)
  • Defect Density : Number of defects per lines of code
Here are some tools you can explore further:
  • .Net – nDepend
  • Java – jDepend
Advertisement

Agile Metrics – Part I

Posted in Agile Metrics with tags on July 26, 2007 by vikramadhiman

In the recent past we have wondering about what metrics to track. Our aim from the metrics study is to:
a. Improve the process by which things get done
b. Foster project collaboration practices and environment
c. Create an energized and informative workspace

Our current thinking is that we must track the following metrics:

a. Project Backlog – exists, when was it updated, reflects current realities, everyone has access to it, everyone contributes to it, are changes in different versions recorded?
b. Sprint Backlog – mostly the above but is it accompanied with sprint retrospectives for previous sprints and sprint plans for previous as well current sprints?
c. Sprint Plans – developer availability [hours] and total work output documented and communicated to the management and the client
d. Retrospectives – how often are they done, who attend the same and what actions are taken on identified items
e. Engineering Practices – how does the team actually build software, how much of it is automated workspace, how does information flow, what percentage of code is unit test code driven
f. Trainings – how often the team is trained in new soft and hard skills
g. Innovation – what did and how did the team innovate
h. Knowledge Management – how did the learning translate into knowledge, was this knowledge available and used

We have tried to keep it simple and not unnecessarily complicated. However, even the above seem like quite handful to measure. A team member also pointed out that “How to measure” is an interesting aspect of debate as well.

Part I is rarely a destination, its just a start of a journey. Here is hoping for an exciting and adventure filled journey.