Prioritizing the Architecture Backlog Across Value Streams
A healthcare provider has 14 value streams, nine product teams, and an architecture backlog of 85 items. Quarterly PI planning is used, but architecture enablers compete with feature work and often lose. The CIO has mandated a 15% architecture capacity allocation, but teams report it is borrowed back to features by mid-quarter. A key EHR vendor integration is delayed, blocking three value streams. Two architects support the whole portfolio. The enterprise architecture team produces reference architectures that teams ignore. The audit committee wants evidence that architecture work delivers value. There is no explicit architecture runway or fitness function. You are asked to make the architecture backlog a real, prioritized portfolio. The next PI planning is in six weeks. Product owners are measured on feature throughput.
1. How would you structure and prioritize the 85-item architecture backlog? What criteria and cadence?
Read the worked answer
Split the backlog into three visible classes: architecture runway for enablers that unblock teams, architecture debt for recurring cost or risk, and standards or reference architecture for adoption work. For each item, record which value streams and teams are blocked, dependency chains, cost of delay, and risk. The delayed EHR integration is likely a runway item because it blocks three value streams; sequence it first with an explicit dependency map. Use WSJF at quarterly PI planning, but apply a portfolio risk override for audit or regulatory items. Retire or merge low-value items because 85 is too many to manage. Publish a rolling 12-week view with owners. The reasoning is that an architecture backlog must be a portfolio instrument, not a wish list; otherwise product owners cannot see why it matters and capacity gets borrowed.
2. How do you prevent the 15% architecture capacity from being borrowed back to features mid-quarter?
Read the worked answer
Make the allocation explicit in team backlogs as work items with acceptance criteria and a named architect sponsor. At portfolio level, treat the 15% as a guardrail: if a team borrows it back, the trade-off is recorded as new architecture debt and escalated to the product manager and architect, not silently absorbed. Tie a portion of product-owner incentives to architecture outcomes, such as reducing blocked value streams or adopting fitness functions. Use a mid-quarter review that shows actual allocation versus plan. The reasoning is that capacity is borrowed because features have visible deadlines and architecture work does not. Visibility, consequence, and shared ownership change the incentive. Do not rely on a mandate alone; the CIO's 15% needs an operating mechanism.
3. What evidence should the audit committee see that architecture work delivers value?
Read the worked answer
Show a value dashboard that links architecture items to business and risk outcomes: number of value streams unblocked, EHR integration lead time, reduction in architecture exceptions, fitness-function coverage for critical services, and reduction in incidents or manual reconciliation. Include leading indicators such as teams using the reference architecture, runway items completed with acceptance evidence, and capacity actually spent. The audit committee cares about risk and value, not activity counts. Baseline before the next PI and report a small set of causal metrics, for example that three value streams were blocked by EHR integration and the completed runway item reduced expected delay by four weeks. This is more credible than claiming architecture ROI in general. It also protects the 15% allocation because the value is visible.