Software Engineering Metrics: Part 1 — Start With Why
A six-part series on the why how and what of software engineering metrics.
This six-part series of articles looks at a metric strategy you can apply to a software engineering function throughout the entire delivery lifecycle, from the backlog through to production:
- Part 1: Start with why
- Part 2: Define your audiences
- Part 3: Understanding stocks and flows
- Part 4: Define your metrics
- Part 5: Monitor and observe
- Part 6: What to do with your data
Part 1: Start with why
As Simon Sinek very famously said, “Start With Why”. He was talking about company purpose, but the idea is entirely applicable to many other things.
Metrics is a great example. It’s super easy to start at the wrong end; to identify a set of metrics to track and then decide what to do with them. As Simon would say, that’s like starting with ‘what’.
I think it makes more sense to think about why you need metrics at all. How are you going to use the collected data? What are you going to change once you have the results in your hands? If you cannot identify a clear purpose, you could be wasting your time collecting them. It’s better to start lean.
Place metrics into categories
It helps to begin by looking at the high-level categories that metrics could fall into. This will help identify why you are going to track metrics at all. Categories will help you identify why you need them, how you can record them, and what you can do with them.
Metric categories give you the ‘why.’
Starting with high-level categories helps identify useful metrics, grouping and combining data into valuable reports that your various audiences can consume and to understand the purpose of collecting them. Further in the process, it helps you build a narrative around why you need specific metrics, making it easier to get engagement.
You’ll come up with your own set of categories, but here’s my suggestion.
Velocity
Velocity is anything to do with backlogs, throughput and delivery. Done well, you’ll have an insight into the type of work your teams are doing, how quickly they are delivering and even the state of your production environment.
Understanding velocity helps you identify workflow constraints, shape teams and control work demands.
Quality
Quality measures the quality of code and features put into production. It can also extend to value delivered to customers. It also influences what type of work the team do.
Understanding quality helps you deliver a better product.
Performance
Performance measures how the code, apps or services behave in production. I suggest four main areas to monitor:
- Speed
- Stability
- Scalability
- Security
Performance metrics help you respond to system weaknesses by driving optimisation.
Finance
Finance measures anything to do with budgets, headcount and funding.
Understanding your finances helps you innovate and to stop you going out of business.
Objectives
Everything you deliver (or pretty much everything) should contribute to one or more of the company’s published goals. They could take the form of OKRs, KPIs or simple missions.
Having a set of metrics around objectives helps communicate with the executives how well they are being achieved and gives purpose to the work individual contributors are doing.
Next — Part 2: Identify your audience
Once you understand your categories, you can begin to think about the audiences that will consume your data, why they need it and help pad out the actual metrics you need.
