Kanban for Agile Projects Study Material (UNISA, CUT & SA Agile Delivery)

Kanban is a practical way to deliver work in Agile environments by visualizing flow, limiting work in progress, and improving predictability without forcing rigid time-boxing. This study material focuses on Kanban for Agile projects using language and exam-ready concepts commonly tested in South African university modules—especially UNISA and CUT—such as project management, IT service delivery, and agile practices in capstone-style contexts. You’ll learn how to design a Kanban system, define policies, manage flow metrics, run replenishment and service classes, and avoid common pitfalls when organizations attempt “Agile” without changing how work actually moves.

1) Kanban Fundamentals for Agile Project Delivery (UNISA & IT/Project Management Modules)

Kanban originated in manufacturing and operations, but its modern meaning in Agile is largely about workflow control. Instead of planning work in fixed-length iterations, Kanban emphasizes continuous delivery and system-level improvement. In university modules—often under headings like “Agile software development,” “project scheduling,” or “IT project management”—students are expected to connect Kanban concepts to outcomes: reduced lead time, better throughput, and fewer bottlenecks.

1.1 What “Kanban” Means in Agile Context

A Kanban system is defined by:

A board that visualizes work items moving through defined states (e.g., To Do → In Progress → Review → Done).
Work-in-Progress (WIP) limits that restrict how many items can be in a given state at once.
Explicit policies that clarify how and when work moves.
A cadence for replenishment, service delivery review, and improvement.
Flow metrics to manage and improve the delivery system.

In Agile projects, these elements replace assumptions like “we will finish everything in iteration N” with measurement-driven reasoning such as “we can reduce average lead time by addressing blocked work and improving review capacity.”

1.2 Kanban vs Scrum: Exam-Style Comparison

Students frequently need to distinguish Kanban from Scrum because South African course outlines often include comparative analysis under “Agile methods.” A clear, exam-friendly contrast:

Aspect	Kanban	Scrum
Delivery rhythm	Continuous flow	Iterations (Sprints)
Planning unit	Replenishment + pull	Sprint planning
Main control mechanism	WIP limits + flow	Sprint goal + roles + events
Metrics focus	Lead time, throughput, aging	Velocity, sprint burndown
Cadence events	Flow review, replenishment, improvement	Sprint planning, daily scrum, review, retro

Key takeaway: Kanban doesn’t eliminate planning; it shifts planning from time-boxed sprint commitment to capacity-aware replenishment driven by observed flow.

1.3 Kanban in UNISA Project/IT Deliverables: The “System View”

UNISA study materials and exam frameworks (especially in modules aligned to IT project management or software delivery) frequently emphasize that project success depends on:

clarity of requirements,
coordination and risk management,
schedule and delivery control,
quality assurance and stakeholder communication.

Kanban maps directly to this by turning “schedule control” into flow control. For example:

Requirements stability improves when policies define what “ready” means.
Risk management improves when service classes separate faster/worse-risk work.
Coordination improves because blockers become visible.
Quality improves when “Done” includes test/review criteria.

1.4 Core Kanban Concepts: Cards, Columns, and Policies

Cards represent items of work. In Agile projects, cards might represent:

user stories,
bug fixes,
tasks,
acceptance tests,
design revisions,
documentation updates.

Columns represent workflow states. Common states in software delivery:

Backlog / Ready
Analysis / Design
Development
Code Review
Testing
Release / Done

Policies are the rules for movement. Without them, teams drift into “tribal knowledge” and the board becomes decorative. Example policies:

A card can move to Development only if:
- acceptance criteria are written,
- dependencies are identified,
- priority is defined.
A card can move to Review only when:
- implementation is complete,
- tests are written and passing.
A card is Done only when:
- automated tests pass,
- stakeholder acceptance is documented,
- deployment checklist is completed.

In exam answers, policies matter because they reduce ambiguity, which reduces rework—rework shows up as aging, cycle time inflation, and WIP accumulation.

1.5 The Role of Pull and WIP Limits

Kanban’s practical engine is pull. When capacity is available (indicated by WIP below a limit), the team pulls the next most valuable work item. WIP limits prevent the team from “multitasking” and from pushing work downstream before it’s ready.

Common mistake: setting WIP limits too high. If WIP limits are, say, 20 items for one column in a small team, the WIP limit becomes meaningless. A better approach is to start conservative and calibrate.

A realistic learning set for a typical small Agile delivery team (e.g., 5–9 contributors):

In Progress column WIP limit: 3–5
Review WIP limit: 2–3 (review is often bottlenecked)
Testing WIP limit: 2–4

Even if exact numbers vary, exam answers should state the principle: WIP limits should reflect true capacity and bottlenecks, and they should be tuned based on observed flow.

1.6 Cadence in Kanban (Without Iteration Commitments)

Kanban still needs rhythm, but not sprint events. A typical cadence for university-level assignments:

Replenishment (e.g., 1–2 times per week): select work for entry into the system based on available capacity.
Service delivery review (optional weekly/biweekly): review performance and handle systemic issues.
Operations review (if applicable): assess incidents, quality defects, and blocked work.
Continuous improvement: run experiments and update policies.

This is important because students often ask: “If there are no sprints, when do we plan?” The answer: planning occurs via replenishment, guided by policies, priorities, and WIP availability.

2) Designing a Kanban Board for Agile Projects (UNISA + Practical System Setup)

A frequent exam scenario is: “Design a Kanban board for a software development project. Define columns, WIP limits, policies, and metrics.” To answer strongly, you need to demonstrate that the board is designed based on the organization’s workflow, not copied from generic templates.

2.1 Step-by-Step: Building Your Kanban System

A structured approach that fits university marking rubrics:

Identify work item types
- user stories,
- bug tickets,
- technical tasks,
- operational requests.
Map the workflow
- define how work moves from request to completion.
Define “Ready” and “Done”
- ready = policy-compliant to enter workflow,
- done = quality-complete and accepted.
Add WIP limits
- set limits per column, aligned to capacity and bottlenecks.
Create service classes (if needed)
- separate work types by risk/urgency/value.
Define policies for each transition
- what signals permission to move left-to-right.
Instrument the board
- ensure you can measure lead time, cycle time, throughput.
Run replenishment and review
- keep the system flowing and improve it.

2.2 Choosing Columns: The “Workflow Truth” Principle

Columns should represent meaningful work states. If columns are too granular, you create overhead; if too broad, you hide bottlenecks.

Example for a project typical in Agile IT modules:

Backlog / Ready
Analysis & Design
Development
Code Review
Testing
Deployment / Release
Done

You can compress or expand, but the transitions must align to real work.

Counter-argument to “more columns is better”: More columns can increase variability because teams interpret states differently. If WIP limits aren’t calibrated per column, the team may clog intermediate stages.

2.3 Defining WIP Limits: Starting Values and Calibration

WIP limits should start from capacity and evidence. You don’t need perfect knowledge at the beginning, but you must demonstrate that WIP limits are deliberate.

A plausible starting configuration for a team of 6 developers/analysts/testers (roles overlap):

Analysis & Design WIP limit: 2
Development WIP limit: 3
Code Review WIP limit: 2
Testing WIP limit: 2
Deployment / Release WIP limit: 1

Why smaller limits for review, testing, deployment?

Reviews tend to be bottlenecks.
Deployment may require specific approvals or environments.

Calibration strategy:
After observing flow over 2–4 weeks (or enough cycles for measurement), adjust WIP limits based on:

queue length (number of cards waiting),
aging (how long cards remain in a state),
blocked reasons.

2.4 Policies: How to Make Transitions Objective

Policies can be written as checklists. Example policies (exam-ready):

Policy: Move to Development

Acceptance criteria are complete.
Dependencies resolved or documented.
Card has a clear estimate range (if your module uses estimation).
User story size is within agreed bounds.

Policy: Move to Code Review

Implementation is complete.
Unit tests updated and passing.
Coding standards followed.
Feature flags or release notes are updated (if applicable).

Policy: Move to Testing

Code review approved.
Test plan exists for the story.
Required test data prepared.

Policy: Move to Deployment / Release

QA sign-off recorded.
Deployment checklist completed.
Rollback strategy documented.

The exam point: policies reduce variability, which reduces queue time and cycle time.

2.5 Service Classes: Managing Different Types of Work

Not all work should move through the same pathway. Agile projects often include:

regular feature development,
urgent production issues,
compliance-driven tasks,
customer escalations.

Service classes let you define different expectations and priorities. Example:

Service Class	Typical Work	Expected Delay/Target
Expedite	Sev-1 incidents, critical security fixes	24–48 hours
Standard	Regular user stories	5–10 business days
Batch/Intangible	Large refactors, compliance tasks	within planned roadmap window

In exam answers, explain that service classes prevent “expedite” work from being delayed by normal backlog—while also preventing abuse (e.g., everything marked expedite).

2.6 Example: A Full Kanban Board Scenario (A University Case)

Consider a fictitious but realistic Agile project in an IT department:

Work arrives from product management and support.
The team includes 2 developers, 1 QA, 1 designer/analyst, and a rotating reviewer.

The workflow is:

Backlog / Ready
Analysis & Design
Development
Code Review
Testing
Done

WIP limits set:

Analysis & Design: 2
Development: 3
Code Review: 2
Testing: 2

Policies define readiness and done. Suppose five cards arrive in a week:

A (user story) ready with full acceptance criteria
B (bug fix) with reproduction steps
C (user story) missing acceptance criteria
D (minor UI enhancement) ready
E (production incident) needs expedite handling

If the team tries to pull everything immediately, C will block because it isn’t ready. The system should pull only A, B, and D into workflow based on ready policies and WIP limits. E goes via an expedite class if your system defines it; otherwise, it should still enter based on a separate expedite lane or priority policy.

Exam-critical lesson: Kanban failures often come from treating policy as optional. Cards move too early, which increases rework and “aging.”

2.7 Common Board Design Pitfalls (and How to Fix Them)

No WIP limits
- Outcome: long queues, high lead time, hidden bottlenecks.
Unclear “Done”
- Outcome: work appears finished but keeps returning, inflating cycle time.
Too many reasons for blocked
- Outcome: metrics become noise; improvement becomes unclear.
Mixed service classes without rules
- Outcome: expedite work starves or normal work becomes unpredictable.
WIP limits used as quotas
- Outcome: the team keeps work “in progress” to meet a target rather than finishing.

A strong study answer acknowledges these pitfalls and demonstrates remediation: clarify policies, enforce WIP, separate classes, and track blocker reasons consistently.

3) Flow Metrics, Analysis, and Continuous Improvement in Kanban (CUT & Agile Analytics)

Universities often test whether students can interpret flow metrics and apply them to improvement. Kanban is “data-driven” but students must avoid confusing metrics. This section builds exam-grade competence in analyzing flow using lead time, cycle time, throughput, and WIP/aging.

3.1 Key Metrics: Lead Time vs Cycle Time

These are often confused, so it’s worth being precise.

Cycle Time: time from start of work to done.
Example: from when a card enters In Progress (e.g., Development) to when it reaches Done.
Lead Time: time from request/arrival (or “ready” entry) to done.
Example: from when a card is added to Backlog / Ready to when it reaches Done.

If your board starts counting from “Ready,” lead time and cycle time differ based on how long items wait in queue before entering Development.

In exam scenarios:

If lead time rises but cycle time stays steady, bottleneck may be in queueing/entry.
If both rise, the bottleneck may be in processing stages.

3.2 Throughput: Measuring Output of the System

Throughput is usually measured as:

number of completed cards per unit time (e.g., per day or per week),
sometimes also broken down by service class or work item type.

Throughput can be used for forecasting in a limited, probabilistic way. Students should explain that Kanban forecasting relies on historical flow, and it’s not a commitment like sprint scope. Throughput analysis helps answer: “Are we improving or are we just moving the same work around?”

3.3 WIP and Aging: Seeing Bottlenecks

Two related ideas are central:

WIP: number of cards in progress (or in a defined state).
Aging: how long cards have spent in states (especially in queues like review or testing).

Aging charts or color-coded aging thresholds are often used. A simple method:

cards in a column have timestamps,
if a card exceeds threshold (e.g., older than 3 days in Review), it changes color.

The exam reasoning: aging indicates where work is stagnating. If many cards are older than threshold in Code Review, code review is a bottleneck.

3.4 Flow Efficiency and Why It Matters

Flow efficiency is often defined as:

Flow efficiency = (Value-adding time) / (Total lead time)

In practice for software:

value-adding time could be development and review effort,
non-value time could be queueing/blocked waiting.

If flow efficiency is low, improving the system isn’t about “working harder,” but about:

reducing waiting,
reducing rework,
reducing blocked time.

Exam marks often reward students who connect metrics to systemic causes.

3.5 Statistical Process Control Concepts (Exam-Approach)

Some university curricula introduce the idea of distributions and variability. In Kanban, you can explain:

delivery times have variability due to dependencies, size differences, and quality gates,
predictions should be based on observed distribution, not a single average.

Even without deep statistics, a solid answer references:

median lead time (robust against outliers),
percentiles (e.g., 85th percentile lead time) for more realistic forecasting.

3.6 Example Metrics Calculation (Consistent Scenario)

Assume a Kanban system counts lead time from when a card becomes Ready and cycle time from when it enters Development.

Over one week, the team completes 6 cards:

Card	Ready Date	Development Start	Done Date	Lead Time (days)	Cycle Time (days)
A	Mon	Mon	Thu	3	3
B	Tue	Tue	Fri	3	3
C	Mon	Wed	Fri	4	2
D	Wed	Wed	Mon	5	3
E	Thu	Thu	Thu	0	0
F	Fri	Fri	Mon	3	0

This table demonstrates how the definitions impact computed results. (In real systems, E and F would rarely have zero cycle time; this example is for clarity.)

Exam lesson: when metrics look surprising (e.g., cycle time near zero), it likely means the board states don’t capture start time accurately, or you’re measuring from the wrong column.

3.7 Common Misinterpretations (and Counter-Arguments)

Misinterpretation 1: Average lead time is enough.
Counter: averages hide variability. Two systems can have the same average lead time but very different risk profiles. Using percentiles gives a more realistic picture.

Misinterpretation 2: More WIP always increases throughput.
Counter: WIP beyond capacity often increases context switching, queueing, defects, and rework. Throughput may plateau or even decline due to bottlenecking.

Misinterpretation 3: A board looks busy, so performance is bad.
Counter: you must interpret relative to WIP limits and aging. A board with WIP at limits might be healthy if flow time remains stable and blockers are rare.

3.8 Designing an Improvement Feedback Loop

Kanban improvement is systematic. A typical learning loop:

Observe metric (e.g., aging in Review column rises).
Inspect workflow for cause (e.g., review approval policy too strict or reviewers overloaded).
Identify a bottleneck (e.g., 1 reviewer for 2 days).
Run an experiment (e.g., rotate reviewer, reduce review scope, improve test automation).
Measure impact using before/after metrics.

A strong exam response includes both hypothesis (“review bottleneck is caused by overloaded reviewer”) and measurement (“lead time percentile drops from 85th percentile by 1 day after experiment”).

4) Implementing Kanban Practices for Agile Delivery Teams (UNISA + Governance, Quality, and Stakeholders)

Implementation isn’t just building a board. Teams need governance, quality criteria, stakeholder expectations, and safe collaboration structures. University modules often assess whether students can align delivery practices to organizational constraints such as QA gates, change management, and stakeholder reporting.

4.1 Creating a “Definition of Ready” and “Definition of Done”

Kanban benefits from explicit quality gating. Two artifacts:

Definition of Ready (DoR)
Definition of Done (DoD)

These are not necessarily the same as Scrum’s definitions, but their intention is the same: reduce rework and remove ambiguity.

Example DoR for Agile IT work:

acceptance criteria written,
dependencies identified,
required environment access available (or blocked flagged),
card meets size constraints.

Example DoD:

code reviewed,
tests passing,
documented change and rollback approach,
accepted by stakeholder (or meets acceptance policy).

In Agile exam questions, emphasizing DoR/DoD is a strong sign you understand quality as part of the process, not a phase at the end.

4.2 How Kanban Supports Quality Management

Kanban quality control can be implemented via:

a “Review” column with explicit criteria,
testing policy embedded in “Testing” readiness conditions,
automated quality gates (linting, unit tests, static analysis),
defect handling policies (e.g., defects create their own service class or workflow path).

A practical policy example:

a story can move to Done only if automated test suite passes and code review passes without major feedback.

If you want to mention governance in an SA context, you can connect to organizational quality management requirements:

change approvals,
release control,
compliance evidence for audit trails.

Even if your university course uses general “project management,” you can frame Kanban as enabling governance through visibility and audit-ready policies.

4.3 Replenishment Planning: Prioritization Under WIP Constraints

Replenishment in Kanban is a planning activity. It chooses what enters the system. It should consider:

priority and business value,
work readiness (DoR),
service class and urgency,
available capacity (WIP room),
dependencies and risk.

A university-style argument:

If you replenish without checking DoR, WIP limits will prevent unlimited explosion, but you still waste capacity once items fail policies.
If you replenish without considering service class, your system becomes unpredictable.

A realistic replenishment rule set:

Pick the next highest priority cards that meet DoR.
Only pull into the first workflow column where WIP is below its limit.
Ensure expedite policy triggers only for defined criteria (e.g., Sev-1 issues).
If no card meets DoR, trigger improvement or requirement clarification.

4.4 Stakeholder Communication: Reporting Without Sprint Numbers

Stakeholders often expect “progress” reporting. Kanban can provide:

current WIP and throughput trend,
lead time estimates,
aging distribution (how many cards are stuck in each stage),
forecast based on historical throughput and WIP limits.

Common exam trap: forecasting incorrectly as a commitment. A good response distinguishes:

forecasts = probabilistic,
commitments = agreed scope at policy gates or capacity planning.

If your university assignment includes a “management report” component, you can structure reporting as:

What is moving well? (throughput stable; low aging)
Where are bottlenecks? (Review aging high)
What are we changing? (review policy adjustment; improve automation)
What is the expected impact? (lead time percentiles)

4.5 Governance and Roles: Who Does What in Kanban?

Kanban can be run without formal Scrum roles, but responsibilities still exist:

Service Delivery Manager / Kanban Lead: ensures the system is working, facilitates replenishment and improvements.
Team Members: pull work, respect WIP limits, follow policies.
Product Owner / Service Owner: manages priorities and service class definitions.
SME / Reviewers / QA: provide specialized capacity at relevant stages.

In SA university contexts, you might mention that organizations sometimes overlay Kanban with Scrum roles (e.g., Scrum Master becomes Kanban facilitator), but avoid claiming a fixed mapping unless your course material does.

4.6 Change Management: Evolving Policies Safely

Kanban policies are not static commandments—they evolve. A safe change management approach:

treat policy changes as experiments,
communicate changes clearly,
allow a learning window (e.g., 1–2 replenishment cycles),
monitor metrics after changes.

Example:

if you change Definition of Ready to require “acceptance criteria must include test cases,” lead time might initially increase due to more work upfront, but cycle time and rework might decrease later.

A strong exam answer mentions both possible short-term and long-term effects.

4.7 Case Example: A Delivery Team That Improves Lead Time

A common case study pattern (adapted for exam reasoning):

Week 1: lead time high, review aging high.
Investigation: reviews are delayed because reviewers are pulled into unrelated tasks.
Experiment: create a “reviewer capacity” policy; limit WIP in Development so reviews don’t get overwhelmed.
Result: review column aging reduces, throughput stabilizes, lead time decreases.

In exam writing, ensure causality is plausible:

reduced queue in review due to constrained upstream WIP,
not because the team “worked faster” arbitrarily.

5) Exam-Ready Kanban for Agile Projects: Practical Questions, Pitfalls, and South African University Alignment

This section is designed to function like a consolidated exam practice module: it provides question patterns typical in university exams and assignments, and it reinforces the “must know” content. It also anchors the learning to common SA curricula themes: agile delivery, project planning/control, and IT service delivery—including modules where students encounter Scrum/Agile methods, project governance, and workflow management.

5.1 Common Exam Questions and How to Answer Them

Question Pattern A: “Explain Kanban and compare it to Scrum.”

A strong answer should include:

continuous flow vs time-boxed iteration,
WIP limits vs sprint commitment,
metrics differences (lead time/cycle time vs velocity),
board and policies.

Add a short example:

“In Kanban, a user story can move to Review when it meets Done/DoR policies, and WIP limits ensure the team doesn’t overload review.”

Question Pattern B: “Design a Kanban board for an Agile project.”

Answer structure:

list workflow columns,
define DoR/DoD,
propose WIP limits,
define policies for transitions,
specify which metrics will be tracked,
mention replenishment cadence.

Question Pattern C: “Your Kanban board shows increasing lead time. Diagnose the cause.”

A complete diagnostic framework:

check WIP limits adherence,
check aging distribution per column,
compare cycle time vs lead time,
inspect blocked reasons,
validate policies (is work re-entering earlier stages due to unclear Done?),
evaluate capacity changes (e.g., reviewer availability).

Question Pattern D: “What is flow efficiency and how does it guide improvement?”

Answer:

define flow efficiency as value-adding time / total lead time,
interpret low efficiency as too much queueing/rework,
propose improvements targeting bottlenecks and queue reduction.

5.2 A Worked Scenario: Diagnosing Bottlenecks with Flow Metrics

Assume a scenario consistent with the Kanban definitions used earlier:

Lead time increases over 3 weeks.
Team claims “we are coding quickly.”

Use metric logic:

If cycle time (Development → Done) is stable, coding is fine.
If lead time increases, queue time increased before Development entry:
- backlog waiting,
- DoR delays,
- WIP limit in Analysis column too low/high.
If both cycle time and lead time increase, bottleneck likely inside processing:
- review capacity reduced,
- testing environment failing,
- Definition of Done too strict and causing rework loops.

Then link to action:

adjust upstream WIP to protect bottleneck,
reduce “blocked” category types and track root causes,
improve test automation,
clarify policies for “ready” and “done.”

5.3 Pitfalls in Agile Kanban Adoption (What Markers Look For)

Pitfall 1: Treating the board as a task list rather than a system

Symptoms:

no WIP limits,
no explicit policies,
cards move whenever someone “gets to it,”
metrics are unreliable.

Marker response:

explain how WIP limits and policies make it a control system.

Pitfall 2: WIP limits set without understanding capacity

Symptoms:

WIP limits too high → no benefit,
too low → underutilization and stalled flow.

Marker response:

argue for starting conservative and calibrating using metrics.

Pitfall 3: Too many workflow states

Symptoms:

cards rarely move,
overhead grows,
people interpret columns inconsistently.

Marker response:

propose simplifying columns and ensuring each state reflects meaningful workflow.

Pitfall 4: “Expedite” abuse

Symptoms:

everything labeled expedite,
normal work never gets capacity.

Marker response:

define criteria for expedite, require service class validation, monitor its impact.

Pitfall 5: Quality gates ignored

Symptoms:

Done means “developer finished,” not “accepted and tested,”
defects explode downstream.

Marker response:

implement DoD in policies and enforce it through workflow.

5.4 Kanban Experiments: How to Propose and Justify Improvements

A good exam answer doesn’t just say “we should improve.” It proposes:

a hypothesis,
an experiment,
a measurable outcome.

Example experiments:

Reduce review bottleneck
- Hypothesis: review bottleneck is causing aging and lead time increases.
- Experiment: introduce pair-review or rotate reviewer; raise review WIP limit moderately only if upstream WIP is adjusted.
- Measure: review aging median decreases; lead time 85th percentile decreases.
Improve readiness
- Hypothesis: cards waiting due to missing acceptance criteria inflate lead time.
- Experiment: strengthen DoR policy and add a “Ready checklist” before entering Development.
- Measure: queue time before Development decreases; rework incidents decrease.
Reduce rework
- Hypothesis: testing failures cause re-entry and cycle time inflation.
- Experiment: enforce test automation and “definition of done includes passing automated tests.”
- Measure: defect count per release decreases; cycle time variance decreases.

Even without numeric results, markers reward a clear logic chain.

5.5 South African University Alignment: Where These Concepts Appear in Study Context

This document is positioned for students in South Africa preparing for Agile/Scrum/IT project management topics often associated with modules and exam patterns found in university course structures, such as:

UNISA modules covering agile methods, software delivery practices, or project management fundamentals (often where students must explain approaches, compare methods, and propose control mechanisms for delivery).
Central University of Technology (CUT) style modules where project delivery, process control, and service delivery governance appear in applied assignments and exam questions (where students must justify workflow and explain metrics).

While module codes vary by year and faculty pathway, the exam competencies remain consistent:

can you explain Kanban concepts precisely,
can you design and justify a board and policies,
can you diagnose system problems with flow metrics,
can you propose improvements using an experiment approach.

5.6 Practice Mini-Tests (Answer Frameworks)

Use these as exam rehearsals. Write answers using the structure your lecturer expects.

Mini-Test 1: “Define lead time, cycle time, and throughput in Kanban.”

A high-scoring structure:

define each term,
relate them to board entry/exit columns,
explain why each matters.

Mini-Test 2: “Your Kanban board shows many cards waiting in Code Review. What do you do first?”

High-scoring:

inspect WIP limit adherence,
inspect review policy and acceptance criteria,
check blocked reasons (e.g., missing tests, missing approvals),
adjust upstream WIP or improve readiness,
propose review capacity experiment.

Mini-Test 3: “Explain how service classes improve predictability.”

High-scoring:

define service classes,
show that policies and expectations differ by class,
argue that this prevents expedite work from derailing normal flow.

Mini-Test 4: “Explain why WIP limits are necessary.”

High-scoring:

connect WIP limits to multitasking, bottlenecks, and queueing,
explain how WIP limits make problems visible,
mention tuning through calibration.

5.7 Summary Checklist: Kanban for Agile Projects (What to Memorize)

For exam readiness, internalize this checklist:

Board states reflect real workflow stages.
DoR defines readiness to enter the system.
DoD defines completion and quality.
Policies govern transitions (not convenience).
WIP limits control multitasking and reveal bottlenecks.
Replenishment pulls work based on capacity and readiness.
Service classes manage different urgency/risk/value types.
Metrics: lead time, cycle time, throughput, aging, flow efficiency.
Improvement runs as experiments based on observed system behavior.
Stakeholder reporting uses predictions probabilistically and highlights bottlenecks.

Final Note on Mastery (Exam Outcome Orientation)

When Kanban is implemented correctly for Agile projects, it turns delivery into a measurable flow system. Students who can (1) design a board with policies and WIP limits, (2) interpret flow metrics to diagnose bottlenecks, and (3) propose experiments with clear measurement logic typically perform well in the exam-style questions common to SA university Agile/IT project management pathways.