What Scrum is - honestly
Scrum is a framework for work that requires regular inspect & adapt - regular stopping, evaluating, and course-correcting.
A Sprint has a start and an end. Bounded iterations - closed learning loops. The Sprint Backlog is a commitment for this sprint: this we do, that we don't take. Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective - each event has a purpose and a structure.
Why do closed iterations make sense? Because they force prioritization. Not everything can be "in the sprint." You have to choose. And that choice - what matters now and what can wait - is the fundamental decision-making work in Scrum.
A Sprint starts clean. A Sprint ends with something that can be shown and evaluated. Then a retro: what went well, what didn't, what we do differently. And again.
Scrum doesn't ask "what's in the queue?" Scrum asks "what do we choose for this bounded period to deliver value - and what will we learn from it?"
Both frameworks are good. For different questions.
Four collision points
When a Kanban board appears in a Scrum project, it's not just "an additional tool." It's a change in the question the team is asking itself. And that change has specific, predictable consequences.
Collision one: clean start/end vs. continuous flow.
A Sprint starts clean and ends clean. Kanban has no "closure" - everything is in motion, everything is "in progress" at some stage.
If you have a Kanban board in a Scrum project, the sprint is never really "done." Cards are always in some column - "In Review," "Waiting for QA," "Waiting for Deploy." What does that mean? The Sprint Review happens against a backdrop of "work in progress" - and nobody knows exactly what's done and what's "almost done."
"Almost done" is not done. In Scrum.
Collision two: column silos vs. cross-functionality.
Five columns: "Design," "Backend," "Frontend," "QA," "Deploy." Looks clear. But what does this board actually visualize? Handover. The card travels from specialist to specialist like a production line.
Scrum assumes that Developers work together - not that they pass tasks to each other like a relay baton. Cross-functionality means problems get solved collaboratively, not sequentially. A board with columns per specialty visualizes - and reinforces - exactly what Scrum wants to avoid.
I saw a team that had "Problem with collaboration between frontend and backend" on every retro for a year. When we removed the per-role columns - it disappeared.
Collision three: extending sprints "because it's in progress."
"We can't close the sprint because that's still in the Testing column." "We'll extend the sprint by three days to finish this."
A sprint that doesn't end is not a sprint. It's a waterfall project with a colorful board.
Scrum doesn't exist without a closed loop. Inspect & adapt requires a moment of stopping - not continuous motion. If the Kanban board gives an argument for not closing the sprint, the Kanban board is destroying one of the framework's fundamental values.
Collision four: WIP without limits destroys sprint focus.
Kanban has WIP limits - and that's one of its smart principles. Restrict the amount of work in progress, because multitasking is an illusion.
But when the Kanban board is a visualization rather than a real system - WIP limits don't exist. Everyone has five cards "in progress" at once. Columns are full. Nobody finishes anything, everyone is busy.
"We're busy" and "we're delivering value" are not the same sentence.
When Kanban in software development makes sense
I'm not saying Kanban doesn't work in IT. I'm saying it doesn't work in the same project as Scrum - because they answer different questions.
When is Kanban the right choice in software development?
- Maintenance teams - work consists of a continuous stream of small, varied tasks. Bug fix, minor configuration change, dependency update. Response time matters more than iteration.
- Support and operations - incidents, requests, patches. Priority is time from report to resolution.
- Infrastructure and DevOps - continuous flow of changes, no product discovery cycles.
- Post-launch projects - the product lives, but isn't evolving intensively. Maintenance, minor improvements, monitoring.
In those contexts, Kanban is exactly what you need. And that's precisely why it's worth knowing and respecting - rather than using it everywhere as a "clear visualization tool."
What to do with the fifteen-column board
The Tech Lead looked at the board for a moment. Counted the columns.
"Actually, I don't know why we have five columns between 'in progress' and 'done'."
That's a good starting point.
Questions to bring to the next retro:
- Why do we have this board? What decisions do we make based on it?
- Does the board help us inspect & adapt, or does it obscure what's really "done"?
- How many columns represent "workflow" and how many are "because it looked good on the demo"?
- Does each column have an owner and a cycle time? Or do cards just... sit there and wait?
- Who decides when a card moves - and is that decision a conscious one?
A board that answers these questions sensibly - stays, or gets simplified. A board that's a visualization of chaos - gets rebuilt.
Kanban and Scrum can coexist in one organization - in different contexts, for different teams, with different questions. They can't coexist in the same project, if nobody asked: which framework answers the question we actually need to ask?
For those who genuinely want to combine elements of both: there's the Kanban Guide for Scrum Teams - an official resource describing how to deliberately and intentionally bring Kanban practices into Scrum. Or Scrumban - a more evolutionary approach to transitioning gradually between frameworks. Neither is the same as bolting a Kanban board onto Scrum "because it's clearer that way." That's a thoughtful integration with clearly defined questions.
Does your team have a Kanban board and a sprint in the same project? And has anyone ever asked - why do we have both, and what does each one actually contribute?