Applied PM Traineeship · AgilePM Framework
Bargains Extra
01 — The Brief
Bargains Extra — a multi-channel retail business — was mid-sprint on a mobile App Refresh when the traineeship brief began. The delivery goal: an MVP covering multiple payment methods, improved UI/UX, wider product range, store location features, finance reporting, and a robust backup process. My brief extended further: map the full project portfolio and determine delivery sequencing beyond the App Refresh.
Working across five stakeholder roadmaps — ecommerce, warehouse, customer, finance, and stores — I prioritised a 12-item feature list by MVP alignment and strategic objective. Each ranking was source-evidenced with direct quotes from the Ecommerce Roadmap, the Project Goal, and stakeholder emails cited against every decision.
For post-MVP sequencing, I identified three projects: Data Protection Process Improvements (P004 — regulatory risk, external audit incoming), CRM System (P005 — foundational for customer engagement), and Customer Loyalty Programme (P002 — highest strategic return once CRM was live).
"The Customer team are desperate for a way to communicate with customers on a personal level. Studies show that this increases customer retention and repeat purchases."
— Product Owner Email · Source for P005 / CRM prioritisation02 — Backlog Governance
The sprint backlog had accumulated items entirely unrelated to the project goal. Developers — as noted in standup — "don't always stick to the product roadmap," meaning the TO DO column had features like a BBC News live feed, in-app gaming, and social media widgets sitting alongside MVP-critical payment and security work.
I audited every Kanban item against the Project Goal's five MVP criteria, striking through six out-of-scope entries and documenting inclusion rationale for everything that remained. Sources cited ranged from the Ecommerce Roadmap to the Audit Lead's direct instruction, used to justify why security features moved into NEXT SPRINT rather than FUTURE WORK.
The result: a clean five-column board with a fully traceable backlog. Every item had a reason to be there. Every removed item had a documented reason for removal. This is the discipline that keeps sprint velocity aligned to stakeholder value.
03 — Risk Register
Three risks were active simultaneously entering Sprint 3. Developer licences missing (R001): two team members unable to work on payment features, directly threatening the highest-priority MVP deliverable. Information security incomplete (R002): an external audit arriving in two weeks, security work not yet started, Test Lead on leave for the entire sprint. UX/UI overallocation (R003): the Website PM consuming 75% of a shared design resource against an agreed 50% split.
Each risk was scored using the Impact × Likelihood matrix. R001 and R002 both returned a score of 20 (5 × 4) — the highest possible without maximum probability on both axes. R003 scored 12 (4 × 3). All three were owned by the PM, reflecting that blockers affecting sprint delivery sit within the PM's accountability boundary.
Escalation triggers were documented in advance. If the licence issue hadn't resolved within one week, the next action was already defined. Pre-defined escalation paths mean nothing gets stuck in the gap between "being monitored" and "becoming a crisis."
04 — Issue Management
The issue log captured the same three blockers as the risk register, but through a different lens. Where risks track probability and prevention, issues document active impact and live resolution ownership. The same problems — licence access, test cover, vendor SLA breach — read differently once they've already materialised in sprint.
I001 (licence access) was rated Red with a five-day resolution target and PM ownership. I002 (Test Lead on annual leave for all of Sprint 3) rated Amber — QA coverage was achievable if the Scrum Master reprioritised. I003 (third-party vendor SLA breach following a company acquisition) was Red, requiring direct vendor engagement and a pre-defined escalation path to the Chief of Staff.
Issue ownership rationale was documented explicitly: not just who would fix it, but why that role was the right one. That clarity prevents accountability gaps — the most common reason issues stay open a week longer than they should.
05 — Sprint Reporting
The End of Sprint Highlight Report for Sprint 2 rated Amber overall. Scope, Resources, and Timelines each scored Amber independently — and the RAG matrix rule was unambiguous: more than one Amber sub-category equals an Amber overall. Costs held at Green. An honest report, not a managed one.
The report carried two formal escalations: developer licence access (R001/I001) and UX/UI overallocation (R003), both requiring action outside the PM's direct control and cross-referenced to their risk and issue log entries. Information security readiness (R002) was documented with the external audit timeline as explicit justification for Sprint 3 urgency.
Next-period objectives were direct and fully source-evidenced — every objective traces back to a sprint note, stakeholder email, or risk log entry. The Highlight Report is a live governance document: every line points forward to the next decision that needs to be made.
06 — Performance Analysis
The Sprint 1 Planned vs Actual chart revealed sharp delivery variance across the team. Dev 4 completed 20 tasks against a plan of 10 — double. Dev 1 delivered 5 against a plan of 10 — half. These aren't minor rounding errors. They're signals of scope drift, untracked backlog additions, or a hidden blocker — and the PM's job is to determine which, before those patterns compound into Sprint 3.
I raised three targeted questions for the Scrum Master: Why did Dev 4 over-deliver — scope creep or unplanned items added mid-sprint? Why did Dev 1 under-deliver — was this one of the developers blocked by missing licences? Were any unplanned tasks formally reprioritised? Each question was linked to supporting evidence from the scenario notes.
On resources, I negotiated the UX/UI split in parallel — a prioritisation meeting with the Website PM, supported by a burndown chart and workload tracker — and scoped CRM discovery for Sprint 3 as requirements-gathering only, protecting MVP focus while building the foundation for the next phase.
Project Artefacts
What's inside
What's inside
Delivery Outcomes
| Area | Challenge | PM Response | Result |
|---|---|---|---|
| Payment Delivery | Two developers blocked by missing tool licences; payment features unable to progress | Escalated to procurement with 5-day target; leadership escalation trigger pre-defined in risk log | Sprint 3 payment backlog unblocked; escalation path documented |
| Audit Compliance | Security features not started; external audit in two weeks; Test Lead on leave | Fast-tracked into Sprint 3 goal; security consultant option documented; audit deadline used as hard sprint boundary | Compliance delivery path secured within the audit window |
| UX/UI Delivery | Website PM consuming 75% of shared design resource against agreed 50% | Prioritisation meeting with evidence — burndown chart and workload tracker; 50/50 split reconfirmed | Resource balance restored; Sprint 3 design progress resumed |
| Stakeholder Mgmt | Chief of Staff requesting ad hoc feature additions for Sprint 4 demo through informal channels | Structured reply with formal intake via PM/PO email; demo scope communicated proactively | Expectations set; requests formalised through backlog; scope creep controlled |
| Sprint Performance | Dev 4 at double planned output; Dev 1 at 50% — both unexplained in Sprint 2 | Three targeted Scrum Master questions raised with source evidence; variance linked to blockers and backlog gaps | Root causes identified; Sprint 3 planning informed by variance data |
| Backlog Discipline | Six off-roadmap items (gaming, news feed, social media) accumulating alongside MVP work | Full Kanban audit against Project Goal's five MVP criteria; every removal source-evidenced | Backlog aligned to MVP; scope creep made visible and removed before Sprint 3 |
PM Reflection
What I Got Right
Every decision — risk scoring, issue ownership, backlog curation, stakeholder reply — was grounded in a named source document with an exact quote. This isn't bureaucratic compliance; it's what separates structured PM thinking from reactive improvisation. When the rationale is built from the start, escalation decisions become cleaner and faster because the evidence chain is already there.
What I'd Sharpen
Sprint 1 showed significant delivery variance, but the data only surfaced once the sprint had closed. In a live project, I'd push for mid-sprint check-ins with the Scrum Master — not to micromanage, but to catch Dev 4's scope drift and Dev 1's blocker before they compound. Earlier visibility produces earlier correction.
What This Demonstrates
Three simultaneous blockers, an external audit deadline, a cross-project resource dispute, and a board-level demo commitment all lived in the same sprint window. Holding those threads in a coherent governance structure — knowing which to own, which to delegate, and which to escalate — is the core PM skill this project tested.
What I'd Build On Next
With four sprints in the cycle but only Sprint 1 data visible, the planned vs actual snapshot is one data point rather than a trend. A velocity chart across all four sprints would make the Sprint 4 demo commitment significantly more defensible, and would add compelling weight to the resource negotiation argument.
Closing Statement
This project was an exercise in managing the full width of the PM role simultaneously — not sequentially. The backlog needed curating. Three risks needed owning. Three issues needed escalating. A stakeholder email to the Chief of Staff needed a carefully structured reply. A sprint report needed to be honest about what Amber actually meant. All of this, in the same sprint window, with the same delivery deadline visible on the horizon.
The nine artefacts produced across this traineeship — each one grounded in source-evidenced rationale — demonstrate the kind of structured, document-first PM thinking that holds up to scrutiny in a real governance review. Not just completing tasks, but understanding why every decision was made, who should own it, and what happens next if it doesn't resolve on schedule. That is the standard I hold my PM work to.