Does Planning Poker Work for Kanban Teams?
Planning poker grew up alongside Scrum, and a lot of its assumptions (a sprint boundary, a velocity target, a fixed team pulling from one backlog) come from that world. Kanban teams don't have most of those, which raises a fair question: is estimation even worth doing without a sprint to plan?
What changes without a sprint
In Scrum, points feed directly into a sprint commitment: how much can the team pull in over the next two weeks. In Kanban, work moves continuously, so there's no equivalent commitment to size against. That removes the main reason teams historically ran planning poker, but it doesn't remove every reason.
What still holds
Even without sprint planning, sizing has two uses that survive the switch to flow:
- Prioritization input. A story map or backlog review still benefits from a rough sense of effort, the same way it would in Scrum. See using story maps to prioritize before you estimate.
- Spotting oversized work before it enters the flow. In Kanban, a story that's too big doesn't blow up a sprint, it blows up your cycle time and sits in "in progress" for weeks, dragging down every flow metric you track. Catching an "infinity" story before it enters the board matters just as much here, arguably more.
A lighter version that fits flow
Most Kanban teams that keep estimation drop the ceremony around it rather than the practice itself:
- Estimate at intake, not in a dedicated session. Size a story when it's refined and ready to enter the board, rather than batching a backlog's worth of stories into one planning poker session.
- Use size to flag risk, not to forecast capacity. A large estimate is a signal to split the story or investigate further, not an input to a sprint commitment that doesn't exist.
- Track cycle time by size band, not velocity. Instead of asking "how many points did we deliver," ask "how long do our 'large' stories actually take compared to our 'small' ones." That comparison tells you whether your sizing is meaningful, and it maps naturally onto flow metrics the team is likely tracking anyway.
When to skip it entirely
If your team's stories are already small and similarly sized by the time they're ready for the board, formal estimation adds overhead without adding information. That's consistent with the broader case for skipping story points altogether once a team's throughput is predictable enough that sizing stops changing any decisions.
Planning poker isn't inherently a Scrum-only tool. What it's really doing is surfacing disagreement and catching oversized work before it costs you time. Kanban teams that keep that part and drop the sprint-shaped ceremony around it tend to get the most value out of it.
