What flowed well?

Where did work move smoothly through the board?

Bug fixes moved from review to done within a day, a fast turnaround.
Our daily standup helped us swarm on blocked items quickly.
Clear acceptance criteria meant fewer cards bounced back to development.
Where were the bottlenecks?

Which stages caused work to pile up or stall?

Code review was a constant bottleneck, with only one reviewer available.
Cards sat in 'waiting for deployment' for days at a time.
Testing got backed up because environments were unstable.
WIP limits and policies

Are our work-in-progress limits and rules working?

We kept breaching the WIP limit in development. Should we lower it?
The 'in progress' limit forced us to finish before starting new work, which helped.
Our definition of done is unclear, so cards move prematurely.
What will we improve?

What concrete changes will improve our flow?

Add a second code reviewer to the rotation to ease review delays.
Lower the dev WIP limit to 3 to reduce context switching.
Introduce a 'blocked' aging policy: escalate anything blocked over 2 days.

What is the Kanban Flow Retrospective?

Kanban teams don't work in sprints, so a sprint-shaped retrospective often misses the point. The Kanban Flow Retrospective looks at how work moves through your board: where cards stall, where they move quickly and what causes the pile-ups. It's a practical way to find the friction that slows delivery and makes it hard to predict. The team works through four topics: what flowed well, where the bottlenecks were, whether your work-in-progress (WIP) limits and policies are working, and what you'll change. Discussing them together in TeamRetro builds a shared picture of how work gets from "to do" to "done". It suits teams practicing Lean or Kanban, and any agile team trying to improve cycle time and throughput. Run it regularly and it becomes a habit of small improvements (kaizen). Bringing the board and your flow metrics into the room keeps the conversation on the system instead of on individuals, so the team can agree on process changes and check at the next session whether they worked.

Kanban Flow retrospective format

What flowed well?

Where did work move smoothly through the board?

This topic captures the parts of your workflow that performed well: work items that moved steadily from start to finish without unnecessary delays. Encourage the team to think about specific cards, handoffs, or stages that felt smooth, and prompt them to identify what enabled that flow so those practices can be repeated.

Where were the bottlenecks?

Which stages caused work to pile up or stall?

Bottlenecks are the stages where work accumulates faster than it can be processed, slowing down the entire flow. Ask the team to look at columns where cards piled up or sat idle, and dig into why. Focus on the system and process rather than individuals to avoid blame and keep the conversation constructive.

WIP limits and policies

Are our work-in-progress limits and rules working?

This topic examines whether the team's WIP limits, column policies, and definitions of done are helping or hindering flow. Prompt the team to reflect on whether limits were respected, too tight, or too loose, and whether the rules for moving cards were clear. This often reveals where the process itself needs tuning.

What will we improve?

What concrete changes will improve our flow?

This is the action-oriented topic where the team turns insights into commitments. Encourage concrete, owned, and measurable improvements rather than vague intentions. Tie each action back to a bottleneck or flow issue raised earlier, and decide how you'll know it worked at the next retrospective.

When to use this retrospective

  • When your team practices Kanban or Lean and wants to improve flow without waiting for a sprint to end.
  • When cycle times are rising or work feels stuck, and you need to find the bottleneck.
  • When WIP limits and column policies are unclear or being ignored.
  • When you want retrospective discussion tied to flow metrics like throughput and lead time.
  • Every two weeks or once a month, to make improving flow a habit.

Suggested icebreaker questions

  • If your workflow were a type of traffic, what would it be right now: open highway, rush hour, or total gridlock?
  • What's one thing in your daily routine that always flows smoothly, no bottlenecks attached?

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Bring the board and your flow metrics (cycle time, throughput, WIP) so the discussion starts from data.
  • Talk about the system, not individuals. Bottlenecks are usually process problems, so keep it blame-free.
  • Limit yourselves to one or two improvement actions so the team can deliver them before the next retro.
  • Give every action an owner and a way to measure it at the next session.
  • Use anonymous idea entry before discussion so quieter team members contribute.
  • Start by reviewing the actions from last time to see what's changed.

Frequently asked questions

How is a Kanban Flow Retrospective different from a Sprint Retrospective?
A sprint retrospective looks back on a fixed timebox. A Kanban Flow Retrospective looks at how work moves through your system, using flow metrics like cycle time, throughput and WIP instead of sprint goals.
How long does a Kanban Flow Retrospective take?
Most teams finish in 45–60 minutes. Allow up to 90 minutes for a large team or when there's a big bottleneck to work through.
When should we run a Kanban Flow Retrospective?
Kanban has no sprints, so pick a steady cadence such as every two weeks or once a month. Run an extra one when you notice cycle times rising or queues growing.
What metrics should we bring to the retrospective?
Cycle time, lead time, throughput, WIP levels and a cumulative flow diagram. They show where work is piling up and whether your changes are helping.
Who should facilitate a Kanban Flow Retrospective?
A Scrum Master, agile coach, team lead or flow manager often runs it, but anyone on the team can. What matters is keeping the discussion on the system and making sure every action has an owner and a measure.
Ready to run this retrospective?Try this retrospective live