Why Do You Need Metrics and KPI in Agile Product Development?

Tags:
2018 03 03 head

Why do we define metrics and KPI?

First, we want to find out how good the built-in quality of our software artifacts is.

Second, we want to improve the built-in quality through experiments and use the metrics to judge the success of these experiments.

And the Key Performance Indicators KPI provide plausibility checks by qualifying the intrinsic quality of software artifacts against quantifiable strategic objectives.

Measurements shall be cheap to gather and as much as possible generated automatically through the tooling landscape.

We provide two sets of measurements to find out how supportive the development process is for quality and how to evaluate the quality of the artifacts.

Definitions

A metric is a measure or a combination of measures for quantitatively assessing or improving a product, a process, or a team.

A key performance indicator is a metric that

  • Is tied to a strategic objective.

  • Has at least one defined time-bound target value such as a number, a trend, a variation, etc.

Therefore, you must define your strategic objectives before you can use KPIs.

Lean approaches have an imperative to reduce cycle-time, eliminate waste and tend to zero-defect products. The last one is a corollary because defects are waste. Please use this imperative to define your agile and lean KPIs.

If your tooling landscape does not support automatic gathering of a specific metric, you shall make it optional until you have solved your tooling weaknesses. Accurate and real-time automated measurements are of tremendous importance for acceptance and lasting success.

Process Aspects

The optimal lean software development process has a batch size of one, almost no waiting time, no superfluous stock, and no quality issues.

Cycle Time of defects

It shows the effectivity to resolve non-quality in product development,

Cumulative Flow Diagram for defects and for stories/Backlog Items

It shows how effectively resources are allocated,

Sprint and PI burndown planned stories and effort

versus completed stories and effective effort trends show the stability and adaptability of the development process,

Planned velocity and effective velocity trends

It is an indicator for the maturity of the agile product organization.

These metrics shall be automatically provided through the issue and product backlog system. For example, the “best of breed” JIRA tool has build-in reports for all the above metrics, so the tools you use should also have them.

Technical quality

A high-quality software artifact has no code smell issues, no compiler warnings, always compile, and all tests are successfully processed.

  • Code quality

    • Method length distribution,

    • Class size distribution,

    • Cyclomatic complexity distribution,

    • Code Smells,

  • Product quality

    • Continuous integration successful build trends,

    • Test coverage trends for unit tests, integration tests, and -ility tests. This metric implies the development team uses unit testing, TDD, ATDD, and automatic -ility testing.

  • Architecture

    • Separation of API and implementation can only be inferred on modern technology stacks.

  • Work techniques

    • Refactoring trends sometimes need to be evaluated manually in some projects.

    • Emergent Architecture documentation trends probably need to be evaluated manually in most projects.

These metrics shall be automatically provided through your quality tracking and continuous integration systems. For example, the "best of breed" tools SonarQube and Jenkins have build-in reports for these metrics, so the tools you use should also have them.

Remainder

The above metrics are tools to discover discrepancies and weaknesses in your product development process and generate artifacts. The inferred results shall be used to identify and implement corrective measures.

Agile emphasizes transparency. The above metrics and KPIs shall be visible anytime to all involved participants through dashboards.