Horizen Grocery Chain - eCommerce Platform Launch
Running a 20-week Scrum delivery as Scrum Master and Project Manager to take a UK grocery retailer from zero digital channel to a full B2C eCommerce platform, on schedule, on budget, and ahead of every launch-month target.
Client
Horizen Grocery Chain (UK)
Role
Scrum Master / Project Manager
Timeline
20 weeks, 10 sprints
Team
9, dev, design, QA, DevOps
3,400
Customers registered in 30 days (target: 3,000)
£42K
GMV in first 30 days post-launch
68%
Checkout completion (target: 65%)
Zero
P1 incidents through launch month
The brief
Horizen Grocery Chain is an established UK grocery retailer with the brand, supply chain, and customer base to compete online, but no digital channel. UK online grocery represents roughly 12% of total grocery spend and growing, and every quarter without a platform meant ceding more of that share to pure-play competitors.
My mandate as Scrum Master and Project Manager: deliver a full B2C eCommerce platform, accounts, catalogue, cart, checkout, payments, order tracking, promotions, and inventory integration with the in-store ERP, in 20 weeks, on a fixed £220,000 budget, with a launch date locked to a seasonal marketing campaign that could not slip.
"The cost of doing nothing compounds every quarter competitors capture online share we don't have a way to fight for."
Initiation & planning
Charter and governance
Sprint 0 was spent entirely on setup rather than delivery: Jira and Confluence configuration, board design, ceremony templates, and a fully refined product backlog split across seven functional epics. That investment compounded across the whole project, by Sprint 1 the team had a working board and clear acceptance criteria on every story, instead of improvising process mid-delivery.
Governance ran through a CEO-sponsored Steering Committee (CEO, COO, Head of IT, Marketing Director) with fortnightly reviews, weekly sponsor 1:1s, and a RACI matrix that gave me sole accountability for sprint ceremonies, stakeholder communication, and the RAID log.
Jira sprint board and backlog structure set up in Sprint 0, before any delivery work began.
Delivery strategy
Ten two-week sprints, structured around three checkpoints that de-risked the fixed launch date:
MVP by Sprint 2
Real, working software demoed to stakeholders four weeks in, the moment the project stopped being theoretical to the sponsor.
Beta 5 weeks out
80 real customers in Sprint 8, early enough that anything they surfaced could still be fixed before launch.
Compliance from Sprint 1
Payment provider contracts (Stripe, PayPal) and PCI-DSS scope work started on day one, the single highest-risk external dependency.
How the sprints ran
Sprint 1–7 · Feature build
Each functional epic, registration, catalogue, cart, checkout, order tracking, promotions, inventory, moved through the backlog in ranked order, refined weekly with the Product Owner and estimated by the team using Planning Poker. Every Daily Scrum was anchored on the Jira board itself, working back from "In Review" and "Testing" rather than a status round-robin.
Sprint 0, setup
Jira board, Confluence space, backlog of 7 epics fully refined and story-pointed before delivery started.
Sprints 1–2, foundations & MVP
Registration, catalogue, cart and checkout review shipped; MVP demoed live to the Steering Committee at end of Sprint 2.
Sprints 3–5, promotions, inventory, payments
In-store ERP inventory feed integrated (with a fallback admin override after stale-data issues in Sprint 4); Stripe and PayPal live by Sprint 5.
Sprints 6–7, polish & hardening
Search and catalogue polish, mobile-responsive design, and load testing at 3x expected launch traffic. All 7 epics complete on schedule.
Sprints 8–10, beta, UAT, launch
Closed beta with 80 customers surfaced two UX issues internal QA missed; both fixed before UAT sign-off and public launch with two weeks of hypercare.
Launch-day war room: full team on an open video bridge, issues triaged live against the Jira launch checklist.
Key decisions
Beta five weeks before launch, not two
Running the closed beta in Sprint 8, five weeks ahead of public launch, rather than a token beta the week before, gave the team room to actually act on what customers found. Two real UX issues surfaced this way (an overly aggressive low-stock warning, and a mobile checkout button placement) that internal QA had missed entirely, and both were fixed in Sprint 9 before UAT.
Absorbing the Sprint 7 velocity dip
Cross-browser work during the mobile-responsive sprint was underestimated, and velocity dipped. Rather than adding scope back or slipping the date, we absorbed the dip and protected the fixed launch window, a call made possible by holding backlog discipline earlier in the project.
Results
The platform launched at the end of Sprint 10, exactly on the Week 20 target.
- Registered customers (30 days): 3,400 vs a target of 3,000
- GMV (30 days): £42,000
- Checkout completion rate: 68% vs a target of 65%
- P1 production incidents in launch month: zero
- Functional epics delivered on schedule: 7 of 7 by Sprint 7
- Retrospective action items shipped: 23 of 27 across the project
"Nchedochukwu got our migration back on schedule within weeks. Clear timelines, proactive updates, and infrastructure that just works."
Reflections
The biggest lesson from this project: compliance work (PCI-DSS documentation, in this case) needs its own sub-epic from Sprint 1, not a line item bundled into the sprint that triggers it. We absorbed the cost when it lagged into Sprint 5, but it was avoidable with better upfront scoping.
The other lesson that will carry into every future delivery: retrospective action items only ship when they're logged as real issues with an owner and a date, not bullet points in a meeting doc. That discipline alone took our action-item completion rate well above the team's previous project.
Interested in a similar engagement? Get in touch, I'm available for new projects.
