Feature Ageing: The simplest delivery signal you’re probably not using

In the previous article, I argued that product managers are often the last to know when something starts going wrong. And just to be clear, I’d much prefer if this wasn’t the case but my experience and recent conversations with a dozen or so product managers confirm that it most certainly is.

In many of these conversations we explored transparency but not even a single product manager thought that is the case. Quite the opposite, most have as much visibility and access to the delivery team as one can wish for. So this is not about delivery teams hiding information.

And neither is because status reporting is deliberately misleading.

However we found out that there is a gap between seeing activity and understanding risk. And this gap leads to a rather interesting question.

If product managers are responsible for outcomes, how can they spot delivery risk earlier?

The answer, I think, starts with a simple signal we’ve called Feature ageing.


The difference between knowing and being told

Most product managers I’ve worked with are very helpful people. They will go way beyond the call of duty to remove blockers, facilitate conversations, fill in endless forms, you name it. But they can’t do any of that unless they are told by their teams - “Here is a problem we’d like help with”.

In short they don’t discover delivery risks when the risks appears but only when someone tells them. And most have accepted that there is no better way but nonetheless this creates a somewhat uncomfortable feeling.

Here is a common scenario. A new feature enters delivery. The initial updates sound positive and stay positive for some time. Then a dependency appears, “We’ll shout if we need help” the engineers say.
Then an urgent requirement appears, it can’t wait, and so you agree to park the work. Eventually the team is back on the new feature.  Then somebody mentions that things are taking a little longer than expected. Not too long later, the updates change.

“We’ve uncovered some additional complexity.” or “We’re still working through a few issues.” or perhaps “It’s mostly done.”

And somehow now everyone agrees the feature is at risk. But the interesting question is whether the risk appeared at this point or whether we only noticed it now.

In many cases, the warning signs were there much earlier but we just didn’t have a simple and clear way of seeing them.


What Is Feature Ageing?

Ageing of work is a simple concept that has existed for many years in various fields. It is simply the amount of time a feature has been actively in progress. That’s all.

To make use of feature aging you don’t need to track how much effort has been spent or how many story points remain (eye-roll) or how confident people feel about delivery.

Just how long the feature has been moving through the system. Most product managers already know roughly when a feature started. And they surely know when it eventually finishes.

The information already exists, you just need to collect it and use it to produce a signal that is otherwise hidden in plain sight.

A word of warning. The important part isn’t the Age and this is where people sometimes misunderstand the idea. A feature does not become risky because it is old however it becomes interesting when it is getting older than similar features normally are.


Imagine one feature has been in progress for thirty days.
Is that good? Is it bad? Impossible to say with just that bit of information.


However if you know that most of your features of similar complexity take sixty days, then thirty days is around 50% which is perhaps too early to start worrying about it.


But if most of your features of similar complexity take forty days, then you’ve gone past the 75% mark and I’d suggest this is something that deserves your attention.


So in short, the age itself is not the signal but the deviation from what’s normal is.


Why Status Reporting Struggles

Status reporting tends to answer one question very well “What are people doing?”. Yes, in theory it should also highlight any risks but I think, since our default position is to be optimistic, that it mostly fails at that task.


Product managers, being responsible for delivery of outcomes are usually more interested in
“Should I be concerned?” or “What can I help with?”.


Perhaps calling something a risk is putting people off? Perhaps we need a different question.


While a feature can have plenty of activity around it , it may still be taking longer than it should. There is no direct correlation to how hard people work or how busy they seem. In fact, some of the riskiest work often looks surprisingly busy.


And for that reason we need a signal that abstracts away from the busyness and the subjectivity of raising a risk. One such signal is feature ageing.


Aging of work doesn’t care how busy people are, it simply highlights when something is taking longer than expected.


Just how much data do you need?

Wouldn’t it be nice if you could just manage your features in your preferred way in a tool that also automatically can give you aging signals?


Well, yes, it would. But while such a tool doesn’t really exist yet, at least not out of the box, there is some minimal data collection that can help you identify aging signals fast.


I’d imagine you already have a simple list (spreadsheet?) with your features. For simplicity let’s assume that all you features are very similar in size (in reality they aren’t but that’s a more complicated case we can discuss later). All you need to record  in addition is when does a feature start and when does it finish.

Some features consistently finish fast and others take longer and over time, you will develop a rough sense of what normal looks like in your environment.


You can even capture feature dates historically if you have the data. This will provide you with a more realistic “normal” faster.

When you know what normal looks like, unusual things become easy to spot. Yes, being able to back this up with a proper calculation would be very useful but you could get value out of this data collection even without it.


Do product managers really need delivery metrics?

This is a bit like asking, do you really need a drill to hang a picture on the wall. There are of course more than one ways of achieving your goal. If you really want to see delivery metrics and you are comfortable with that then you probably should.


But I don’t think product managers need delivery metrics to get good delivery signals like when a feature needs more attention.


Metrics are useful and any signal should be able to demonstrate why it is signalling. But even if some product managers choose to look at the calculations as they gain more confidence in the signals they may skip the details.


What I am trying to say is that those product managers who are not comfortable with Kanban metrics, forecasts and formulas won’t need to worry about them if a good feature planning tool with built in signals existed.


Let’s assume for a minute that such a tool does exist. It only needs to answer a simple question:


“Does this feature deserve my attention?”


If you use feature ageing with appropriate signals you can answer this question easily.


The next step is up to you. You need to find out how to help. Because it is almost impossible for a tool to uncover exactly why something is taking longer or to identify the root cause or to prescribe an appropriate solution.


Would you like a free spreadsheet?

The obvious problem of all this is that (I assume) nobody wants to maintain yet another spreadsheet.


I think that most product managers already have more systems than they need. So wouldn’t it be nice if good product tools should have the capability to surface these signals automatically?


Of course ideally, you’d want one system perfectly connected and traceable from idea to production. I don’t want to go into the details (yet!) of why that isn’t happening. It’s not for the lack of attempts but at present no system seems capable to make it work for everyone.


Failing to have it all connected, you could use the simple logic this article describers. It is not particularly complicated and it doesn’t require product managers to necessarily know or care about probabilistic forecasting.


But it could provide that simple signal “This feature deserves attention.”


On the limitation of feature ageing​

Feature ageing is a simple and useful concept but it is not a silver bullet. It tells you which of your work items or features deserve investigation but it does not tell you why.

And I don’t believe it should because the answer is usually complicated and nuanced. A feature may be blocked but uncovering what’s blocking it can be very convoluted. There might be dependencies but the intricacies of how it should work cannot be known without extensive investigation.

So is there anything more we can do about it?
I think so, and I will cover that in the next article.