A few weeks ago I wrote about what happens when story points stop meaning much. The basic argument was that agentic coding is changing the unit by which we should measure software progress. If coding agents can work through implementation tasks much faster than human development teams traditionally could, then points completed, tasks closed and burn up/down charts start to tell us less about whether we are actually getting closer to delivering the thing the organisation wanted.
That left an obvious question - So what should we measure instead?
I have been thinking about this while developing using spec-driven development. I think I am starting to see a useful pattern emerging: measure progress at the point where Features converge into a recognisable business capability, rather than measuring the individual pieces of work underneath it. For me, that appears to be what I think of as the Level 3 System Area.
What is it?
The approach I am currently taking is broken down into several levels.
At the bottom are individual Requirements.
Requirements roll up into Functional Areas - groups of related functionality that collectively do something useful. This might include the usual create, read, update and delete functions, together with the rules and processing around them.
Those Functional Areas then roll up into larger System Areas - things like Customer Management, Supplier Management or Contract Management. Depending on the architecture, these may have their own data models and be isolated from the rest of the system behind APIs.
Finally, the System Areas collectively make up the complete System.
So roughly:
- Level 1 - Requirement
- Level 2 - Functional Area
- Level 3 - System Area / Business Capability
- Level 4 - System
There is another sub-layer that has become important in practice: Features. Some of the Level 3 System Areas are simply too large to treat as one piece of development work. They are broken down into Features and each Feature runs independently through the GitHub Spec-Kit lifecycle.
Those Features can themselves be substantial - can more than 100 individual tasks, broken down into multiple phases. The specification drives the plan. The plan drives the tasks. The agent works through the tasks and the implementation is then brought back against the specification until they converge.
There is still plenty of detailed work being managed. What I am increasingly questioning is whether any of that detail is actually the right thing to report as project progress - I don’t think it is.
The Feature is useful as a development unit. The Requirements and tasks are useful for the coding agents and for traceability. But ultimately those Features have to converge into something, and that’s the Level 3 System Area, e.g. Supplier Management is something a business stakeholder can understand, task 84 of Feature 3 probably isn’t.
This is why I think Level 3 may be particularly interesting. It seems to be the level where a number of things converge - requirements, Functional Areas, Features, data, business rules, interfaces and ultimately a recognisable piece of business capability.
What does it mean from a business perspective?
I wonder if there are really three different kinds of progress being mixed together in a lot of software development reporting.
- There is execution progress.
- There is capability progress.
- And there is business value.
At the execution level, I may have a Feature with 120 tasks and the agent has completed 95 of them, which is useful information while managing the implementation. But I don’t think it means that the organisation has received 79% of the value of that Feature, or that the overall System Area is 79% complete.
The remaining tasks might include integration, security, testing or some of the functionality that makes the entire thing usable. This is the same problem I have with aggregating story points upwards and calling that project progress (which I guess in the strictest sense it is).
We are measuring the activity rather than the thing the activity is intended to produce and Spec-driven development actually helps to make the distinction clearer.
A Feature can move through something like:
Specified → Planned → Tasked → Implemented → Converged
Those are meaningful development milestones and, importantly, there is evidence behind them, but several Features may have to go through that lifecycle before the Level 3 capability actually exists. At that level the milestones might be more like:
In Development → Capability Complete → Integrated → Verified → Production
And then there is another step again. Just because something is in production doesn’t mean it has created any value. At the business level we might be interested in:
Available → Adopted → Value Demonstrated
Those are three quite different views. I think decision-makers should increasingly be focused on the second and third.
There is another reason why I think Level 3 might be the interesting convergence point.
Level 3 also looks like a useful architectural boundary for Agents.
Take a Supplier Management example, if Supplier Management is a coherent System Area with a defined data model, rules and API, I could expose that capability through an MCP wrapper.
A Supplier Management Agent could then be given tools to:
- find a supplier;
- create a supplier;
- update supplier information;
- approve a supplier;
- suspend a supplier;
- retrieve supplier status.
The Agent does not need to understand the implementation underneath Supplier Management and it does not need direct access to the database, it operates through the capability.
So Level 3 potentially becomes several things at once:
- a development boundary;
- a business capability boundary;
- an architectural boundary;
- a measurement boundary;
- and an Agent execution boundary.
That is why I am starting to think of it as a convergence layer, rather than simply another level in a system decomposition.
What do I do with it?
I don’t think the answer is to stop decomposing software into Requirements, Features and tasks. If anything, agentic development makes good decomposition and good specifications even more important. The change is in what we choose to roll upwards, call progress and ultimately measure and report on (I have a spreadsheet that captures my thinking - drop me a message and I’ll send it on).
A few things I am starting to apply:
- Keep the detailed execution model. Requirements, specifications, plans, phases and tasks are still needed by development teams and coding Agents. Spec-driven development provides a very useful structure for managing that work.
- Use Features as development increments. A large System Area does not need to be handed to an Agent as one enormous piece of work. Break it into Features and let each Feature move through its own specification, planning, implementation and convergence lifecycle.
- Measure delivery at the capability level or even milestone level. Features eventually converge into a Level 3 System Area. That is the point at which progress starts to become recognisable to the business (possibly even portions of the delivery being required to meet some other project milestone - it isn’t all needed at the same time).
- Use evidence-backed milestones. “75% complete” is difficult to defend. “Supplier Management has completed its Features, passed integration and is in verification” is much more meaningful.
- Think about the Agent boundary as well as the application boundary. If a System Area is sufficiently coherent to be exposed through an API or MCP interface, it may also become the natural capability boundary through which operational Agents interact with the system.
For the project sponsor or owner, the much more useful question is:
“Which business capabilities now exist, what state are they in, and are they producing the value we expected?”
The more coding becomes compressed, parallel and increasingly autonomous, the less useful it becomes to measure the amount of coding activity taking place. We need to move the measurement layer upwards. I think Level 3 - where the Features converge into an identifiable business capability - may be where it lands.