How to do Kanban planning in absence of scheduled sprints

Short answer: Kanban teams don't have sprint planning, but they still plan. The four cadences that replace it: daily standup (what to pull next), weekly backlog grooming (refine and reorder), monthly throughput review (capacity check), quarterly roadmap (direction). The discipline that makes it work is WIP limits — explicit caps on how many items can be in any column. Without WIP limits, kanban is just to-do lists with extra steps.

Sprint planning is absent in Kanban teams. They maintain continuous flow through WIP limits, and planning takes place in smaller, frequent doses. The four new planning periodicities that take over from sprint planning: daily standup (what to pull next), weekly backlog grooming (refine and re-order), monthly throughput review (capacity check) quarterly roadmap (direction).

Teams that are new to kanban often skip planning altogether. The statement "We don't do sprints" is misinterpreted as the phrase "We don't plan".     As the queue lengthens, the speed with which the team brings things to market diminishes, no one knows when anything will ship, and the team has lost the predictability that planning creates. Kanban requires a different level of planning.

This guide describes the four cadences, the WIP discipline that makes them work, and the circumstances in which kanban planning needs to be reinforced with more structure. For those managing or considering the use of Kanban teams.

What kanban planning actually is

Iterative borders are absent in Kanban. Work continuously flows through columns, while the stories get pulled as capacity opens up. The planning occurs differently.

• Just-in-time, per story. Each story gets refined as it approaches the top of the queue. The team doesn't plan the next 10 stories at once.
• WIP-limited, not capacity-budgeted. The team controls flow with column-level WIP limits, not with a sprint-capacity budget.
• Continuous, not periodic. Backlog ordering changes when priorities shift, not on a sprint boundary.
• Throughput-based forecasting. "We'll have this done in 3 weeks" is computed from historical throughput, not from sprint count.

The doubt in reasoning: does that mean "no planning" It is not a planning project, it is a distributed one which occurs continuously  The following cadences help structure that distributed planning.

The four cadences that replace sprint planning

1. Daily standup — what to pull next.

10 to 15 minutes. Everyone on the team meets. They say what they’re working on, what they’ll pull next, and what’s blocking them. The PM or anchor notifies the team of any priority changes since yesterday.

The daily question, "what should we work on next?" is essentially the same as the "sprint planning" question, asked once every two weeks. Greater frequency, less facetime — closer to how a daily standup operates as a planning meeting rather than a status report.

2. Weekly backlog grooming — refine and reorder.

30 to 60 minutes. The team examines the 10-15 highest priority stories in the backlog, clarifying their acceptance criteria as necessary.

It is continuous instead of pre-sprint, equivalent to sprint refinement. The output consists of a backlog organized with bottom-up top stories that are ready to pull or implement. For depth on this practice, see grooming your backlog as a core PM skill.

3. Monthly throughput review — capacity check.

Thirty to forty-five minutes. Discussion with team and PM

• Throughput (stories per week) over the last 4 weeks.
• Cycle time distribution (median, 85th percentile).
• WIP and bottlenecks (which column is filling up).
• Whether the team's pace matches expectations.

At the team level, this is similar to a sprint retro, except the focus is on flow metrics, not process gripes. If throughput is falling, investigate; if it is stable, do nothing.

4. Quarterly roadmap — direction.

one to three hours The team and PM, along with stakeholders, assess the quarterly strategy and course.

• What themes is the team working toward?
• What's the rough sequence?
• Are there any major changes — new initiatives, scope cuts, team changes?

This is similar to quarterly planning for sprint-based teams. The output serves as a direction rather than a commitment; kanban teams do not commit to a quarterly scope like a sprint team does. The mechanics of tying roadmap strategy to agile planning translate cleanly here.

Planning-related time, across all cadences, works out to roughly 10% of the team’s total time (just like sprint-based teams).

The WIP discipline that makes kanban work

WIP limits are the most important Kanban discipline. Without WIP limits, kanban is merely a to-do list with extra columns.

Standard configuration for WIP limits.

• To Do — no limit (or a large soft limit).
• In Progress — 1–2 per engineer.
• In Review — 1–2 per engineer.
• Done — no limit (closed).

The count in the shape should be space related, depending on the size of the team and the shape of the work. The pattern, popularised in Martin Fowler's notes on the Kanban board, is: tight WIP limits on the active states (IP, IR), loose limits on the staging states (TD, DD).

The significance of WIP.

• Forces flow over batching. Without WIP, engineers start more stories than they finish; cycle times balloon.
• Surfaces bottlenecks. A full column reveals where work is stuck (e.g., In Review filling up = code review is the bottleneck).
• Forces collaboration over assignment. When the next column is full, the engineer can't start more work — they help unblock the bottleneck.
• Constrains scope at the team level. The total WIP across all columns is the team's effective scope at any moment.

WIP limits are kanban's core mechanism, according to The Kanban Guides. WIP limits are not utilized by most Kanban-implementing teams.

Smaller stories lead to significant drops in cycle times – from days to hours, while teams are able to reach their users up to 14 times faster – and the maths relies on WIP limits being respected. Through the absence of limits, the smaller stories do not help; the engineer merely starts more of them in parallel and hence finishes none of them.

What kanban planning is NOT

Frequently misunderstood.

• It's not "no planning". It's distributed planning with different cadences.
• It's not "no commitment". The team commits to WIP limits and to finishing what's in flow.
• It's not "no estimation". Stories can have estimates; the team uses throughput (stories/week) and cycle time as the predictability metric instead of velocity (points/sprint).
• It's not "no roadmap". Kanban teams have roadmaps too — they just commit to direction, not specific quarterly scope.
• It's not "agile lite". It's an alternative agile method, not a stripped-down Scrum.

Teams We See Struggling most Often Through Kanban Have One Of These Misunderstandings. The solution is an education on kanban’s actual requirements.

When kanban planning needs reinforcement

A truthful representation of where the 4 cadences aren't enough

• External commitments with hard dates. Regulated work, contract deliverables, marketing launches. Kanban can hit dates, but it needs an explicit milestone overlay — a "this needs to ship by X" annotation on specific stories.
• Mixed planned + reactive work. If 70% of the team's work is planned features and 30% is reactive bugs/incidents, the planning cadences need explicit allocation. "Reserve 30% of WIP capacity for reactive work" makes the split explicit.
• Multi-team coordination. If the team depends on another team's deliverables, the planning needs cross-team awareness. Standups grow to include the other team's representative weekly.
• Stakeholder cadence requests. Some stakeholders need quarterly commits. Kanban can give directional quarterly plans; commits to specific scope at quarter-end are harder. If the org demands commits, consider whether kanban is the right fit.

When NOT to use kanban (or kanban planning)

• Team needs strong batch cadence. A team that ships in defined releases (regulated environments, enterprise customers with quarterly upgrade cycles) benefits from sprints over kanban.
• Team is new to agile. Kanban looks lighter than Scrum but is harder to do well. The WIP discipline is more demanding than sprint discipline. Start with Scrum if the team is new.
• Work is too small to flow. A team where each story takes 30 minutes doesn't need kanban — the overhead of pulling and moving cards exceeds the work. Use a simpler task tool.

The most common kanban planning failure

After experiencing enough kanban teams, the same pattern keeps emerging: the team adopts kanban, skips the planning cadences, and gets a stale backlog that no one refines.

Signs

• The backlog has more than 100 items, most of them stale.
• The team picks what they want with no clear order.
• The next step is unknown to the stakeholders.
• The reason that cycle times grow is because WIP limits are not enforced.

The solution consists of explicitly reinstating the cadences. We standup daily to prioritise; groom weekly; review throughput monthly. The Kanban method assumes that these processes will happen; if not Kanban collapses.

LiteTracker is designed with a single ordered backlog as its default — and the pattern of finding the right amount of backlog refinement is built into the weekly cadence. Thus, the backlog remains ordered even when the team starts getting busy. Other tools (Jira or Trello) can benefit from kanban-style integrations but require configuration to do so well.

A real opinion on kanban vs Scrum

In the view of some, doing Kanban well is more difficult than doing Scrum well, but Kanban is well-fit for some shapes of work. The majority of teams that claim to utilize Kanban just perform Scrum, sans sprints. They retain the ceremonies and eliminate the iteration boundary. That is acceptable; it is a functioning hybrid. The WIP discipline needed for kanban is rarer than people claim.

Teams that apply WIP-based kanban are more predictable in their cycle times than teams that are on sprints. Claiming to be kanban but not doing WIP creates chaos Disciplinary measure is more important than framework.

Frequently asked

What is kanban planning?

The collection of cadences that kanban teams utilize instead of sprint planning. There are four regular activities to keep in the cadence: daily standup (what to pull next), weekly backlog grooming, monthly throughput review, quarterly roadmap. Roughly 10% of team time distributed across the cadences.

Do kanban teams have sprint planning?

No. Kanban lacks iteration boundaries, thus lacking sprint planning. Planning continuously takes place through the four cadences above. Certain teams utilize 'cycle planning' as a mixed approach; they use kanban flow while having follow-on re-planning sessions periodically.

What are WIP limits?

Explicit limitations on the number of items that can occupy any kanban column at the same time. There’s typically only 1 or 2 active stories being worked on per engineer.  WIP limits promote flow instead of batching and reveal bottlenecks.

How does kanban handle priorities?

A single backlog determines priority based on the item’s position. Next in line for pulling is what’s on top of the backlog. Changes in priorities take place continuously, not at the boundaries of sprints.

How do kanban teams forecast?

Using a throughput-based approach, you can calculate when a story is likely to get done based on history and queue size. Volatile throughput creates widespread forecast variance while stable throughput is predictable.

Can kanban teams meet deadlines?

Certainly, with a clear milestone overlay Stories that have a specific date get annotated with the correct tag; the planning cadence of that team ensures they are pulled in correctly. Unlike sprint commit-then-ship, which automatically ship dates, kanban requires explicit date commitemnt and tracking.

What's the difference between kanban and Scrum?

Scrum employs fixed-length sprints to commit fully to some work, Kanban employs continuous flow with limits on work in progress. Scrum relies on events (like planning and review), while kanban relies on cadence (like standups and throughput review). Both methods can be effective, the decision depends on the work shape and the cadence needs of the major stakeholders.

What's a hybrid Scrum-ban approach?

A kanban-style flow in the sprint, with cadence (planning, review, retro) around it. No phases, WIP limits, ordered backlog. Most contemporary “agile” teams run this hybrid even if they don’t call it 'scrum-ban". It captures the rhythm of planning and execution flow.

Still stuck

Kanban planning refers to distributed planning rather than no planning. The four cadences   daily, weekly, monthly and quarterly   replace sprint planning. The predictability of flow is made possible by WIP discipline. Most of the teams that struggle with kanban skip cadences or aren't enforcing WIP   both are fixable.

For teams that prefer a tracker where priority = position with a single ordered backlog (kanban-shaped from the get-go), that’s LiteTracker. Unlimited users on the free tier. If your team is new to agile, start with scrum and once the team is comfortable with WIP discipline, revisit kanban.

Make sure work-in-progress is always respected, run the cadence, and the planning happens.