Agile Frameworks and Methodologies →mediumMultiple Select

CAPM Agile Frameworks and Methodologies Practice Question

Which TWO statements correctly describe characteristics of the Kanban method?

⚠ Common exam trap

CAPM often tests the Scrum-vs-Kanban distinction — candidates incorrectly apply Scrum attributes (fixed roles, two-week iterations) to Kanban, which is deliberately role-agnostic and continuous-flow.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Work in progress limits are used to improve flow

Option C is correct because a defining characteristic of the Kanban method is the use of explicit work-in-progress (WIP) limits, which constrain how many items can be in a given workflow state at once and thereby improve flow, reduce multitasking, and expose bottlenecks. Option E is correct because Kanban relies on visualizing the workflow on a Kanban board, typically with columns representing process states and cards representing work items, so the team can see status and manage flow. Option A is incorrect because Kanban does not require a team to be dedicated to a single project; it can be applied to shared or multi-project teams and to ongoing service work. Option B is incorrect because the strict product owner, Scrum Master, and development team roles belong to Scrum, whereas Kanban prescribes no mandatory roles. Option D is incorrect because fixed two-week timeboxed iterations are a Scrum practice, while Kanban is based on continuous flow rather than mandatory timeboxed sprints.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The team must be dedicated to a single project
Why it's wrong here
Kanban deliberately imposes no dedicated-team requirement; it manages flow of work through a value stream, often across shared or support teams. Dedicated single-project teams belong to Scrum or other timeboxed frameworks, not to Kanban's continuous-pull model.
✗
Roles are strictly defined as product owner, Scrum Master, and development team
Why it's wrong here
Kanban defines no prescribed roles at all; workflow states and WIP limits are its organising constructs, so product owner, Scrum Master and development team belong to Scrum. It is tempting because those three accountabilities are genuinely standard in Scrum teams, and Kanban is often layered onto an existing Scrum team, which makes the roles appear inherent to Kanban itself.
✓
Work in progress limits are used to improve flow
Why this is correct
Kanban explicitly applies work in progress limits to each workflow stage, exposing bottlenecks and improving flow. This satisfies the stem's requirement for a defining Kanban characteristic, distinguishing it from timeboxed iterations, which Kanban does not mandate.
✗
Iterations are timeboxed to two weeks
Why it's wrong here
Kanban uses continuous flow with optional cadences, not fixed two-week iterations; timeboxing is a Scrum or XP characteristic. Two-week sprints would be correct for Scrum teams, but Kanban instead limits work in progress and measures cycle time.
✓
The process is visualized on a Kanban board
Why this is correct
Kanban makes work and its flow visible on a board, with columns representing workflow stages and cards representing items. This visualisation exposes bottlenecks, work-in-progress limits and cycle time, which is the defining characteristic distinguishing Kanban from push-based scheduling methods.

Go deeper

CAPM Agile Frameworks and Methodologies Practice Question

Why each option matters

Option-by-option breakdown

Related to this question