Three teams, four vendors, and a six-week integration window
A government agency is migrating benefit claims from a 20-year-old mainframe to a new platform. Three Scrum Teams of six, plus a platform team, work alongside four vendors. Eleven releases are planned over 24 months; after 14 months, three have been integrated. The integration environment is available only in a six-week window, and defects are usually found there. A separate enterprise architecture board approves design decisions with a median lead time of five weeks. Each team keeps its own backlog; the programme manager owns the 'master backlog' and allocates work to teams. There is no shared Definition of Done: one vendor counts a feature done when it compiles, another after system testing. Two teams are blocked on an identity-service dependency owned by a vendor whose contract ends in four months. The agency's audit office requires traceability from each requirement to a test result, which teams currently maintain in four different tools.
1. Who should own the backlog across three teams and four vendors, and what coordination mechanisms would you put in place?
Read the worked answer
The default should be one product, one backlog, one Product Owner. Here, a programme manager owning a master backlog and allocating work to teams contradicts both PO authority and team pull, and it guarantees that the teams optimise for allocation rather than for flow.
Ownership. Define the product, or a small number of genuinely separate products, and give each one accountable PO. Where scale demands more, use a chief PO or area PO structure with explicit decision rights written down, not implied. There should be one ordered backlog per product, and teams should pull from it.
Mechanisms.
- A shared roadmap expressed as outcomes, not as allocations.
- Joint refinement every two weeks with a representative from each team, to expose dependencies early.
- A visible dependency board with owners and dates, and dependencies tracked as backlog items.
- One shared Definition of Done covering code, tests, documentation, security, and audit evidence. Four vendors with four definitions will always produce an integration surprise.
- The platform team should serve the product teams through its own ordered backlog with a service-level agreement.
Contracts. Vendor incentives must align with the shared Definition of Done and shared acceptance criteria; otherwise each vendor is optimising its own exit criteria. Coordination is not a meeting - it is a shared artefact and unambiguous ownership.
2. Integration happens only every six weeks and defects are found there. The identity-service vendor's contract ends in four months. How do you handle both?
Read the worked answer
A six-week integration window is a constraint that must be designed around, not a schedule to hope against. Move integration left:
- Continuous integration across teams, not a big-bang merge every six weeks.
- Contract tests between services, so interface breakage is caught in hours.
- Test doubles or stubs for the identity service so teams can develop and test before it is available.
- A walking skeleton that runs end-to-end early, then thickens.
- A release train that targets the integration windows with a hardening buffer, rather than pretending every sprint is releasable.
For the identity service, the contract ending in four months is a top programme risk. Quantify it, escalate it, and force a decision now: extend the contract, build an adapter, or take ownership in-house. Waiting until month four turns a risk into a blocker.
Track dependencies as first-class items with an owner and a date, and limit work in progress so teams finish before starting. Most integration defects are a symptom of too much unfinished work in flight, not of insufficient testing at the end.
3. The architecture board takes five weeks to approve decisions, and audit traceability is spread across four tools. What should the PO do?
Read the worked answer
Five weeks is a flow problem, not a law of nature, but the PO cannot simply demand it change. Bring data: how many releases are blocked, how much work is redone after a late decision, what the cost of delay is. Then negotiate specifics:
- Pre-approved patterns for recurring decisions, so teams are not queueing for the same approval.
- Delegated thresholds - decisions below a defined impact or cost are made by the team or the embedded architect.
- An architecture runway - decisions made ahead of need, in the release cadence rather than the sprint cadence.
- Architects embedded with teams, so the board reviews rather than discovers.
If the board cannot change, plan around it: batch submissions, align the roadmap to the board's cadence, and keep a buffer. Complaining without a workaround is not a plan.
On traceability, audit compliance is a genuine constraint and should be designed into the Definition of Done, not bolted on at the end. Pick one tool as the system of record, automate requirement-to-test links, and generate audit evidence as a by-product. Four tools means four versions of the truth, and the audit office will find the gaps at the worst possible moment. Automating this also removes a recurring manual cost from every sprint.