Goal-Question-Metric: Measure What Matters, Not What's Easy
GQM is a top-down framework for defining metrics. You start with a Goal, ask Questions to clarify it, then define Metrics to answer them. This avoids the common trap of collecting vanity metrics that don't reflect true software quality or business goals.
WHY IT EXISTS: Teams often drown in data while thirsting for wisdom. We collect metrics that are easy to gather (lines of code, tickets closed) but fail to measure what actually matters, leading to "vanity metrics" and misguided efforts. GQM was created to stop this by linking every measurement directly to a strategic goal.
THE MENTAL MODEL: GQM is a chain of justification that flows from top to bottom. You cannot define a useful Metric without a clear Question. You cannot ask a relevant Question without a well-defined Goal. It forces you to justify why you are measuring something before you decide what to measure.
HOW IT WORKS: The process follows three steps in order. First, define the Goal from a specific viewpoint, identifying the object of measurement and its purpose. For example, "Improve code maintainability for the development team." Second, from this goal, generate Questions that, if answered, would indicate progress. For example, "Is our code becoming less complex?" and "Can we fix bugs faster?" Third, identify the Metrics that can concretely answer each question. For the questions above, the metrics could be "average cyclomatic complexity" and "mean time to resolve production bugs."
WHEN TO USE IT: Use GQM when you need to establish a new software measurement program, evaluate the quality of a product, or assess the impact of a new process or tool. It's ideal for creating dashboards and reports that leadership can trust because every number has a clear "why" behind it.
WHEN NOT TO USE IT: GQM is not ideal for pure, undirected exploratory data analysis where you don't have a predefined goal. It's a framework for goal-oriented measurement, not for open-ended discovery. It can also be overkill for small, short-lived projects where the overhead of defining the GQM tree is too high.
ONE CANONICAL EXAMPLE: A team wants to improve its new CI/CD pipeline. GOAL: Increase deployment velocity and stability for the platform team. QUESTIONS: Are we deploying more often? Are our deployments failing less? Is the pipeline faster? METRICS: Deployment frequency (deploys per week), change fail rate (percentage of deployments causing a failure), and lead time for changes (from commit to production).
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.