Pull system in Kanban means:

Work is started only when the next person or stage has capacity.

It is the opposite of a push system, where managers or upstream teams keep assigning work even when people are already overloaded.

Simple explanation

Kanban example

Board:

To Do → In Progress → Review → Done

Suppose In Progress WIP limit = 3.

If there are already 3 items in In Progress, the team cannot pull another item from To Do.

They must first finish something and move it to Review or Done.

Simple class example

“In Kanban, we do not keep starting new work just because work exists. We pull work only when there is available capacity.”

Example with Review

If Review WIP limit = 2 and Review already has 2 items, the developer should not push another completed item into Review. Instead, the team may help clear Review first.

Teaching line

Pull system means: finish work before starting more work.
It protects the team from overload and keeps work flowing smoothly.

REF: AI Tools as is

In Kanban, you can set WIP limits on both:

In Progress and Review

They should have separate limits, because they control different types of work.

Your slide says WIP limits are the maximum number of items allowed in each workflow stage, used to prevent overload and identify bottlenecks early.

Simple board example

Best classroom answer

We set WIP limits on the active work columns, especially In Progress and Review.
In Progress limit controls how much work the team starts.
Review limit controls how much work is waiting for testing, approval, or feedback.

Example

Suppose the team has 4 people:

This means:

• Maximum 3 items can be actively worked on.
• Maximum 2 items can wait in review.
• If Review already has 2 items, no one should move another item into Review until one item moves to Done.

Teaching line

In Kanban, we do not want many tasks half-finished. We want work to flow. So we limit active work in In Progress and Review to expose bottlenecks and help the team finish before starting more.

REF: AI Tools as is

For Kanban, these three metrics measure flow — how smoothly work moves from request to completion.

Your Agile metrics slides define throughput as the number of work items completed in a given time period, lead time as the time from request to delivery, and cycle time as the time from active work start to completion.

Simple teaching explanation

Lead time = customer waiting time.
Cycle time = team working time.
Throughput = how many items the team finishes.

Example using Kanban board

A task moves like this:

Backlog → To Do → In Progress → Review → Done

Suppose:

• Student submits a helpdesk request on Monday
• Team starts working on it on Wednesday
• Team finishes it on Friday

Then:

Key difference

Lead time includes waiting time. Cycle time only includes active work time.

So if work sits in To Do for 4 days before anyone starts, that waiting time increases lead time, but not cycle time.

REF: AI Tools as is

Your slides define velocity as a key Agile metric that measures how much work a team completes during a sprint and helps forecast future sprint capacity.

Your slides use burndown scenarios to interpret sprint progress, including teams being ahead of the ideal line, behind but still reaching the target, flatlining because of blockers, or showing erratic progress.

Simple teaching explanation:

Velocity tells us how much the team usually completes. Sprint burndown tells us whether the current sprint is progressing toward completion.

Example for students:

If our team usually completes 20 story points per sprint, we should not plan 45 story points for the next sprint. During the sprint, the burndown chart helps us check whether the remaining work is decreasing fast enough.

A good solution would be:

If the Review column exceeds its WIP limit, I would stop pulling new work into Review and focus the team on clearing the bottleneck. The goal is to finish and move existing work forward before starting or adding more work.

Step-by-step action

Example answer

Suppose the Review WIP limit is 2, but there are 4 items in Review.

I would not allow another item to move from In Progress to Review. Instead, the team should help complete the review of the 4 existing items. If the issue is that only one person is doing all reviews, another qualified team member should help. If the issue is unclear acceptance criteria, the Product Owner should clarify them. Once two items pass review and meet the Definition of Done, they can move to Done, and then new items may enter Review.

Best short answer for students

If Review exceeds its WIP limit, the team should stop starting new work, focus on finishing the items already in Review, identify and remove the bottleneck, and only move new items into Review when capacity becomes available. The team should also discuss the cause and improve the process so the overload does not continue.

REF: AI Tools/ChatGPT

Yes — DoD means Definition of Done.

Acceptance Criteria and Definition of Done are related, but they are not the same.

Your slides define Acceptance Criteria as clear, testable conditions that must be met for story completion, with formats such as Given–When–Then or checklist style.

Your slides define Definition of Done as the shared understanding of what “complete” means for every user story, including code review, testing, integration, acceptance criteria verification, documentation, performance, accessibility, and security checks.

Simple example

User story:

As a student, I want to reset my password so that I can access my account if I forget it.

Acceptance Criteria:

• User can request password reset by email.
• Reset link expires after 30 minutes.
• User receives a confirmation message after password change.

Definition of Done:

• Code is reviewed.
• Unit tests pass.
• Feature tested in staging.
• Acceptance criteria are verified.
• Documentation updated.
• Security review completed if needed.

Simple class explanation

Acceptance Criteria answer: “What must this specific story do?”
Definition of Done answers: “What must be true before any story is considered complete?”

So if students ask, you can say:

A story is not truly done just because it was coded. It must satisfy its own acceptance criteria and also meet the team’s Definition of Done.

REF: AI Tools/ChatGPT as is

A Scrum board and a Kanban board may look similar, but they manage work differently.

Scrum board example

During a two-week sprint:

Sprint Backlog → To Do → In Progress → Review → Done

Only the stories selected for that sprint normally appear on the board.

At the end of the sprint:

• completed stories are reviewed,
• incomplete stories return to the Product Backlog,
• a new Sprint Backlog is created.

Kanban board example

For a support team:

Requested → Ready → In Progress (WIP 3) → Review (WIP 2) → Done

When one item moves to Done, the team pulls another item into the available space.

There is no need to wait for the next sprint.

Important similarity

Both boards:

• visualize work,
• show progress,
• reveal blockers,
• support collaboration,
• can use columns such as To Do, In Progress, Review, and Done.

The difference is not mainly the appearance of the board. The difference is how work is planned and controlled.

Teaching line

A Scrum board manages work inside a sprint. A Kanban board manages the continuous flow of work.

A Scrum team can also use Kanban practices such as WIP limits. This hybrid use is sometimes called Scrumban.

REF: AI Tools/ChatGPT

Throughput can be used in Scrum too. It is not only for Kanban.

However:

Throughput is more strongly associated with Kanban and flow-based systems.
Velocity is more commonly used in Scrum.

In Kanban

Throughput means:

Number of work items completed during a period, such as 12 tickets per week.

Because Kanban uses continuous flow, throughput may be measured daily, weekly, or monthly.

In Scrum

Throughput can mean:

Number of Product Backlog Items or user stories completed during one sprint.

Example:

Average throughput:

9 stories per sprint

Throughput vs velocity in Scrum

Example:

A team completes:

• 6 stories
• totaling 28 story points

Then:

Throughput = 6 stories
Velocity = 28 story points

Important limitation

Throughput can be misleading when work items have very different sizes.

Completing 10 tiny stories is not necessarily better than completing 5 large, valuable stories.

Teaching line

Throughput is usable in both Scrum and Kanban, but it is a core flow metric in Kanban. In Scrum, velocity is more traditional, while throughput can provide an additional view of how many items the team finishes.

REF: AI Tools/ChatGPT as i

Flow metrics measure how smoothly and quickly work moves through a workflow, especially in Kanban.

Simple teaching explanation

Lead time measures customer waiting. Cycle time measures active workflow time. Throughput measures how many items are finished. WIP and queue measures show where work may be getting stuck.

Example workflow:

Requested → To Do → In Progress → Review → Done

• Lead time: Requested → Done
• Cycle time: In Progress → Done
• Throughput: Number moved to Done per week
• WIP: Number currently inside active workflow stages

The purpose of flow metrics is not to make people appear busy. It is to help the team reduce waiting, expose bottlenecks, and deliver value more predictably.

REF: AI Tools/ChatGPT as is