Which Product Owns the Decision?
On a financial-services project the team is confused about where things live. The Project Manager has been maintaining a single spreadsheet called 'Requirements and Risks' that contains: the prioritised requirements, the risk log, the assumptions, the acceptance criteria, and a list of 'issues we need to decide'. The Business Analyst keeps a separate 'design notes' document with the solution architecture. At the timebox 1 review the Business Sponsor asks why a Must requirement changed and who approved it; nobody can point to a record. The Technical Coordinator says the change was agreed 'in a conversation' and the developer has already implemented it. The next timebox plan is due tomorrow.
1. Map the information in the spreadsheet to the AgilePM products it should belong to, and explain why the conflation causes the sponsor's problem.
Read the worked answer
The spreadsheet is doing five jobs that AgilePM separates deliberately:
- Prioritised requirements + acceptance criteria → Prioritised Requirements List (PRL), owned by the Business Visionary/Ambassador, under change control.
- Risks, assumptions, issues, dependencies → Risk log (and the daily/decision records), owned by the Project Manager.
- 'Decisions needed' → Decision records / daily stand-up outputs, with an owner and a date.
- Design notes → the Solution Architecture Definition and supporting solution documents, owned by the Technical Coordinator.
The sponsor cannot trace the change because there is no single controlled PRL and no decision record. A change agreed 'in conversation' and implemented immediately bypasses the PRL's change control and the Business Visionary's authority. Conflating products means nobody owns any of them, and 'who approved this' becomes unanswerable - which is exactly the governance failure the sponsor is objecting to.
2. What would you put in place before tomorrow's timebox plan, and how is the already-implemented change handled?
Read the worked answer
Before planning: split the spreadsheet into the proper products, assign named owners, and establish a lightweight change control on the PRL - any change to a Must is recorded with who requested it, who approved it (Business Visionary/Ambassador), and the impact on the timebox. Introduce a decision log with owner and date, populated from the stand-ups.
The implemented change is handled as a retrospective formal change: record it in the PRL, have the Business Visionary explicitly accept or reject it, assess the impact on the timebox (what was displaced), and if rejected, add the rework to the timebox plan rather than pretending it did not happen. Then confirm at the timebox 2 planning meeting that the PRL is the single source of truth for scope. The point is not blame - it is restoring traceability so the sponsor's question can always be answered.