This is a composite drawn from more than one engagement. Company details are removed and figures are rounded. The problems and the order of the fixes are real.
The starting point
The business ran several consumer-facing web products on a shared platform. Around twelve engineers, two testers, one designer and a product function that was really one overloaded person. Revenue was healthy, which is partly why the problems had been tolerated for so long.
Within the first week, a few things were obvious.
There was no single backlog. Work lived in the ticketing tool, in a spreadsheet owned by marketing, in chat threads and in the CEO’s notes. Engineers picked up whatever the last person to message them had asked for.
Five people set priorities: the CEO, the heads of marketing and operations, the compliance lead and the CTO. All of them could put work into the team, and all of them did. Nobody could say no, so everything was urgent.
Nothing finished. At any given moment there were more than forty tickets in progress. An ordinary feature took months from start to release.
Everyone was busy and nobody was happy. Leadership’s conclusion was that the team was too slow and probably needed more people.
Step one: one list
We didn’t start with Scrum. We started by putting every piece of work, from every source, into one list. That took most of a week and surfaced about 280 items. Around a third were duplicates, already done or no longer relevant, so they were closed.
Then a simple board went up, with every item currently in progress on it. Seeing more than forty cards in one column did more to convince leadership than any presentation could have.
Step two: one owner for priorities
This was the hard part, and only the CEO could make the call.
The proposal to the CEO was simple. One product owner orders the backlog. Everyone else can request, argue and escalate in a weekly prioritisation session, but the order is decided in one place. Genuine emergencies, meaning production incidents and regulatory deadlines, get a fast lane.
The concern was that one person would become a bottleneck. What changed the CEO’s mind was an exercise: we listed the top ten urgent items from each of the five stakeholders and asked him which ones should come first. He couldn’t answer without a long conversation, which was exactly the point.
Step three: finish things
With one ordered list, we set a hard limit of eight items in progress across the team. New work could start only when something finished.
The first two weeks were uncomfortable. Testing became a visible bottleneck, code reviews that had sat for weeks suddenly mattered, and engineers had to work together on stuck items. But cycle time dropped almost immediately, and for the first time in months work was actually reaching customers.
Step four: a light rhythm
Only then did we add the Scrum skeleton: two-week sprints, a short daily standup, and a planning session capped at an hour. We reserved about a fifth of capacity for unplanned work, based on what the previous month had actually looked like.
We deliberately didn’t add much else. No fixed release train either. Releases went out when a piece of work was tested and ready, sometimes twice a week, sometimes once in two weeks. Forcing everything onto a fixed date would have meant either holding back finished work or rushing unfinished work, and neither helps the business.
The team was trusted to run its own day-to-day. In return, the product owner expected clear weekly reporting and stepped in only when something was actually off track.
After one quarter
Compared with the month before we started, and rounded:
- work in progress went from over 40 items to under 10
- a standard feature went from roughly ten weeks to under three
- unplanned work settled at about a fifth of capacity, and it was now visible and planned for
The bigger change was harder to measure. Arguments about priority moved out of private messages and into one weekly meeting. The business could finally see what was being built and why. The question of hiring more engineers went away, because the existing team turned out to be fast enough once it stopped being pulled in five directions.
What we’d do differently
Bring testing into the redesign earlier. Limiting work in progress exposed testing as the bottleneck straight away, and the testers felt blamed for a problem the old process had hidden.
Agree what “done” means on day one. For the first few sprints it meant merged to some people, released to others, and verified in production to a few. A one-paragraph definition would have saved several awkward conversations.
If your product organisation feels chaotic, resist rolling out a framework on day one. In this case the team never needed more people or more process. It needed one list and one person deciding the order, and the sprint rhythm only worked because that was already in place.
