What AUTOSAR Taught Me About Backlog Management
Most of what goes wrong in Agile doesn’t happen inside teams. It happens between them.
Examples in this article are illustrative composites and do not describe any specific project, product, or employer. The views expressed are my own.
Most Agile conversations about backlog management focus on prioritisation. What gets done first. What can wait. How to balance stakeholder demand with team capacity.
That is not where most systems fail.
Before I ever ran a PI Planning, I spent years on safety-critical software. Automotive and industrial systems, where failure had physical consequences, and where a good share of the work sat inside AUTOSAR-based architectures.
AUTOSAR forces you to define every signal, every interface, every timing constraint before you write anything that does real work. It is not a popular standard. I complained about it at the time. Then I moved into scaled Agile environments and started missing it.
I remember being frustrated by AUTOSAR because it forced conversations that felt painfully premature. We wanted to build. The standard kept pulling us back to interfaces, timing, signal meaning, and failure behaviour. Only later, when I was looking at dependencies between teams rather than components, did I realise that the irritation had been useful, because it had forced the system boundary into the open.
The problems do not disappear when you stop writing code. They get larger and harder to see.
A defect inside a component shows up in a debugger. A misalignment between teams shows up weeks later, after other teams have already built on top of it.
AUTOSAR assumes the most dangerous part of a system is not the components. It is the boundary between them.
Most Agile setups do not treat it that way. They assume the boundary will sort itself out.
Interfaces are the real system
Picture two components that differ by a single bit in how they interpret the same signal. Both implementations are internally correct. The interface is wrong.
Issues like that can take days to locate and minutes to fix once found. The pattern is common enough that anyone who has integrated across component boundaries will recognise it. It is rarely about individual mistakes. It is about how the system is defined.
That changes how you think about dependencies.
The story in your backlog is the implementation. The dependency is the interface.
Most teams treat the interface as a coordination problem rather than an engineering problem. Then they are surprised when integration turns into negotiation.
Dependencies are not coordination
When teams talk about dependencies, the conversation usually sounds like planning. Who needs what, when, from whom.
It looks structured. It is missing something fundamental.
An interface is not an agreement between people. It is a specification of how a system behaves under constraints. It has failure modes. It has edge cases. It has timing implications. It can be correct or incorrect, independent of the people working on it.
When dependencies are treated as coordination, those properties disappear. The conversation moves from engineering to scheduling.
That works until it does not.
Timing lives outside the backlog
Timing is the other blind spot.
Knowing that one team needs something from another is not enough. You also need to know when, and under what conditions.
That rarely lives in the backlog. It lives in someone’s head, usually someone who is not on the team.
As long as that person is available and attentive, the system works. When they are not, things slip in ways that are hard to explain after the fact.
By the time it shows up in metrics, it is already expensive.
Taking boundaries seriously
This is not an argument for AUTOSAR-style ceremony in software that does not need it. It is an argument for taking boundaries seriously.
Most Agile systems focus on the work inside teams. That is the visible part. The boards, the stories, the commitments.
The failures rarely start there.
