Case study
From Ticket Queue to Product Team: An Agile Turnaround in Web Production
Turning a reactive 12-person web production team into a sprint-based delivery unit — cutting turnaround time by half and rework by two-thirds.
- Client
- In-house digital production function
- Industry
- Financial Services — Digital
- Role
- Web Production Manager / Scrum Master
- Duration
- 9 months
Challenge
A 12-person web production team ran as a first-in-first-out ticket queue: no prioritisation beyond who shouted loudest, chronic rework from ambiguous briefs, stakeholder trust at a low point, and average request turnaround of 18 business days.
Approach
Introduced scrum incrementally — two-week sprints, a single prioritised backlog with acceptance criteria, and a brief-quality gate — while protecting 20% capacity for genuine urgencies so the sprint would not be destroyed by "emergencies".
Outcome
Average turnaround halved and rework fell by two-thirds within three quarters. Stakeholders shifted from escalating around the team to planning with it, booking work into upcoming sprints.
- 18d → 9d
- Avg. turnaround time
- −67%
- Rework rate
- 94%
- On-time delivery
- 12
- Team size
The queue that ate the team
The team was talented and permanently underwater. Work arrived as tickets from every direction, priority meant seniority of the requester, and half-formed briefs bounced between requester and producer for days. The metric that told the real story was rework: over a third of completed items came back for changes because nobody had agreed what “done” looked like before work started.
Why not a textbook rollout
A full scrum-by-the-book rollout on day one would have failed — the organisation around the team still thought in tickets and turnarounds. Instead the transformation ran in three deliberate moves, each solving the most painful problem visible at the time.
Move one: a single backlog. All intake funnelled into one prioritised list, ranked in a weekly session with the three biggest stakeholder groups in the same room. For the first time, priority became a shared decision with visible trade-offs rather than a private negotiation.
Move two: the brief gate. No item entered a sprint without acceptance criteria a producer could test against. Vague briefs were returned with a template, not resentment. Rework — the silent capacity killer — started falling within the first month.
Move three: sprints with a pressure valve. Two-week sprints, but with 20% of capacity explicitly reserved for genuine urgencies. That reservation was the political masterstroke the textbooks skip: stakeholders accepted sprint boundaries because the door for real emergencies visibly stayed open — and because “urgent” now consumed a budget, requesters began policing it themselves.
What changed
The numbers moved the way the summary says — turnaround from 18 business days to 9, rework down two-thirds, 94% of sprint commitments delivered on time. But the qualitative shift mattered more: stakeholders stopped escalating around the team and started booking capacity in upcoming sprints, which is the moment a service team becomes a partner.
What I took from it
- Change the system one pain at a time. Each move fixed the loudest current problem, which bought credibility for the next move.
- Reserve capacity for chaos openly. Pretending emergencies won’t happen discredits the process the first time one does.
- Measure rework, not just throughput. It was the single best indicator of process health — and the first metric to respond to the changes.