Explore

Establish UX metrics for Agile

We all say “what gets measured gets done”. And “done” in Agile means “the moment we know we can stop working on something and move on to the next thing”, ”what is the tangible change that’s happened in the world that tells us to move on”.

Measurement

A tangible observation of change.

Metrics

The measurements that we track. There are measures we don’t track (e.g. you don’t measure the length of the thumb of a kid growing, but rather his height).

Analytics

Measures that computers can track. Analytics are a subset of measurements, but the fact that they can be tracked by computers doesn’t make them useful by default. In fact, many data that come with analytics packages are not useful at all. Instead, we need to have control also over measurements that cannot be tracked by computers.

KPI

An important metric.

Internal metrics

Metrics internal to the business, e.g. subscription numbers, retention rates, churn, monthly active users, etc.

UX metrics

Metrics about the experience. Things we measure about the users’ actual experience. They’re not proxy measures.

UX metrics⁠

are based on

UX outcomes⁠

. We have UX outcomes because internal metrics don’t have any humanity baked in. They’re focused on the business, making sure that more money comes in, less money goes out, recurring revenues, etc. Of course we need internal metrics to makes sure that the business is running smoothly, but we also need UX metrics to make sure that there is humanity in what we’re trying to do: improving somebody’s life.

Therefore research capability is essential to be able to build any metrics that makes sense. You need qualitative research first to figure out the metrics.

UX outcomes happen at sprint, release, roadmap and experience vision level. At each of those levels you can have

success metrics⁠

Review

Persuasive metrics⁠

to check the other types of metrics.

⁠

OKRs (Objectives and Key Results)

Objectives are supposed to be aspirational goals.

Key results are metrics we use to tell whether we’re reaching the goals or not.

Therefore OKRs work really well with UX outcomes:

We use our success metrics as the objective

We use our progress metrics (which have to go up) and problem value metrics (which have to go down) as key results.

In Agile what we want to do is pick some of these metrics (not necessarily analytics, because we don’t want to restrict ourselves to things that only computers can measure):

start with the success metrics;

based on the success metrics, build progress metrics and problem value metrics.

When we have Agile teams measuring success in terms of what the users behaviours are, then we get better products and services. When they measure success based only on internal metrics, we don’t.

This is a UX driven approach to measuring success, progress and debt that we’re incurring in because of the obstacles we find.

All this have to come from research. Start from research and get the process working from there. Business outcomes are extremely important, but they’ll work better when we deliver something that really improves someone’s life, and to do that we need to focus on metrics that are derived from UX outcomes.

OKRs (Objectives and Key Results)

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.