Software Engineering Metrics: Part 3 — Understanding Stocks And Flows
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 3: Understanding stocks and flows
Flows (trends) are more enlightening than stocks (counts)
I’ve recently been reading about Systems Thinking. It gets quite complicated but is interesting even at a simple level.
Briefly put, the measurement of the state of something is static at a point in time (a stock). Flows change the value of that stock. You only change the state or value of the stock by influencing the flows.
For example, let’s consider a bank account. Money flows in, increasing the account balance. Money also flows out, decreasing the account balance. The account balance is the total of all money flowing in less the sum of all money flowing out. You cannot change the account balance directly. To improve your balance, you have to earn more or spend less. It follows, therefore, that tracking income and expenses is more meaningful than just looking at the account balance.
A more relevant example might be the size of a team’s backlog:
As you add tickets, the size of the backlog (measured in story points) rises, and decreases as cards move to ‘done’. You can track the size of the backlog over time, but by looking at flows you get a better understanding of why it is changing. Is it increasing because the business is asking the team to do more work, because they are facing constraints or because they are losing efficiency? The opposites are also true.
Stocks and flows are relevant to metrics because you cannot change the value of the stock (e.g. the backlog) directly. You change it by identifying and altering the inbound and outbound flows. So if the backlog is too large or constantly growing, you can control it by working with the business to reduce the number of stories added to it or by increasing efficiency and thereby move more tickets to ‘done’.
Classification is illuminating
Where this concept becomes increasingly useful is by looking at the type of tickets flowing in and out of the backlog. If each ticket is labelled as ‘innovation’, ‘optimisation’ or ‘maintenance’ (see below), you can see the sort of work that is raised, the state of the backlog (and therefore an indication of product quality and level of technical debt) and the type of work the team are doing.
In this example, there are lots of maintenance tickets being raised (bugs) and plenty of innovation too (new product features). The backlog holds a lot of maintenance and some optimisation tasks (which, when combined, indicate technical debt) but by examing the outflow it’s evident that it’s mostly innovation work that’s moving to ‘done’.
By looking at stocks and flows, you get a better idea of the state of your backlog and how you can make changes. By understanding the types of tickets flowing in, in the backlog and flowing out, you can hold an informed discussion about slowing down innovation and allocating time and resource to technical debt.
You can apply this theory to most of the metrics you will identify, helping you understand how you can bring about positive change.
Most often, metrics reports show the value of something changing over time. To extract more value, your metrics suite should include data around flows as well as stocks.
Next — Part 4: Define your metrics
By now you will have a sense of the metric categories and the level of detailed each audience needs. You’re in a good position to start defining the metrics to track.
