Skip to content

Metrics & Monitoring

EmeSoft runs on a simple belief: what you can measure, you can improve. This section defines the metrics we track, how we monitor them, and how the numbers feed back into how we work. It does not repeat the responsibilities or workflow covered in Roles and Methodology - it focuses only on measurement.

Three layers of measurement

We measure quality at three distinct layers, each owned by a different part of the team and answering a different question.

flowchart TB
    subgraph L1[Development - 'How fast & predictably?']
        A[Story points · Velocity · Burndown]
    end
    subgraph L2[Code - 'How good is the code?']
        B[SonarQube quality gate: coverage,<br/>complexity, duplication, security]
    end
    subgraph L3[Delivery - 'How good is the product?']
        C[QC scorecard: defect detection,<br/>test design, ticket rejection]
    end
    L1 --> L2 --> L3
    L3 -->|trends inform| L1

    classDef m fill:#eef6ff,stroke:#3b82f6,color:#1e3a8a;
    class A,B,C m;

Layer	Question	Primary owner	Page
Development velocity	Are we delivering predictably, and getting faster?	Developers + PM	Development Velocity
Code quality	Is the code we ship sound, tested, and secure?	Developers + AI + Quality Engineer	Code Quality
Delivery quality	Are we catching defects and shipping the right thing?	Quality Engineer (QC) team	Delivery Quality

The measure → improve loop

Every metric exists to drive a decision, not to decorate a dashboard. Each sprint we close the loop:

flowchart LR
    M[Measure] --> R[Review at Retro]
    R --> D[Decide 1-3 actions]
    D --> I[Improve next sprint]
    I --> M

Metrics are reviewed in the Retrospective, where AI clusters the numbers into themes so the team starts from data, not opinion.

Principles for healthy metrics