Kanban to Scrum across three product teams

At IT Park I inherited three product teams — a loyalty system, marketplace + e-commerce platform, and a messenger/MLM stack — with a combined headcount north of 20. They were running Kanban with varying levels of discipline. I moved them to Scrum over a few months. This is what actually happened.

Why move at all

Kanban had been working, but it was hiding two specific things:

• Per-release bets. Continuous flow made it hard to ask "what's in the next release, and is that actually the right thing?" The answer was always "whatever's on top of the column."
• Team capacity. Without a sprint boundary it was difficult to have an honest conversation about capacity. We discovered capacity limits only when something shipped late, which is the expensive way to learn about them.

What broke in the first sprint

A lot. The honest list:

1. Estimation was bad. Teams estimated in hours, in points, in T-shirts, sometimes inside the same sprint.
2. The sprint review felt performative — nothing that had been built was really designed to be demo'd to a non-technical audience.
3. Retros were rushed. Everyone wanted the meeting to end.

None of this was a Scrum problem specifically. All of it was a "we haven't done these ceremonies before, of course they're bad at first" problem.

What I kept from Kanban

• WIP limits inside the sprint. Sprints don't mean you stop caring about work in progress. They just mean the discussion happens weekly instead of daily.
• Class-of-service thinking. Some work is expedited, some is normal, some is background. That framing carried over cleanly.
• Cycle-time visibility. Scrum metrics didn't replace cycle time; we tracked both.

What changed

Release cadence doubled: from every four weeks to every two. Upsell conversion into new services within existing products climbed from 1–5% to 15–20% in the same period. I won't claim the sprint cadence alone caused that — the onboarding redesign from the mobile team, done in parallel, deserves a lot of the credit. But shorter iterations meant we got to run those experiments more often.

What I'd tell anyone doing this

Don't roll it out to three teams simultaneously. Pick the team where the cost of a bad first sprint is lowest, run one proper cycle with them, fix the worst ten things, then roll out to the others. We did it in parallel and it worked — mostly because the people involved were patient. You can't assume you'll have that cushion.