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

Agile Quality: Cross-functional ownership means:

Quality is everyone’s responsibility, not only the QA/tester’s responsibility.

In Agile, the whole team works together to build quality into the product: developers, testers, Product Owner, Scrum Master, UX/design, business analyst, and sometimes DevOps/security. Your Week 7 slide contrasts this with traditional quality, where QA is often separated after development.

Simple explanation

Example

For a checkout feature:

• Developer checks that the code works.
• QA tests payment success and failure cases.
• Product Owner confirms acceptance criteria.
• UX checks that buttons work clearly on mobile.
• DevOps checks deployment and monitoring.
• Team reviews whether the story meets the Definition of Done.

Teaching line

In Agile, quality is not passed to QA at the end. The whole team owns quality from the beginning.

REF: AI Tools/ChatGPT as is

• • Quality gates near the end
• Dedicated QA after development
• Heavy documentation
• Defects discovered late
• Rework can be expensive

Traditional quality means quality is often checked after most of the development work is already completed.

It follows a pattern like:

Plan → Build → Test → Fix → Release

Your Week 7 quality slide contrasts this with Agile quality, where testing and quality practices are moved earlier and shared by the whole team.

1. Quality gates near the end

A quality gate is a formal checkpoint where the project is reviewed before it can move forward.

Example:

The team finishes development, then the product must pass a final testing phase before release.

Problem:

If major defects are found at the end, fixing them may delay the release.

2. Dedicated QA after development

In traditional quality, developers may build first, then hand the product to a separate QA/testing team.

Example:

Developers complete the checkout feature. Then QA tests it later.

Problem:

Developers may already have moved on to other work, so fixing defects becomes slower.

3. Heavy documentation

Traditional quality often depends on detailed quality plans, test plans, sign-off forms, and formal review documents.

This can be useful for control and compliance, but it may slow feedback.

Example:

Before testing begins, the team prepares long test documents and approval forms.

4. Defects discovered late

Because testing happens near the end, defects may be found after many features are already built.

Example:

The team discovers late that the checkout process crashes on mobile.

Problem:

The defect may affect design, code, database, payment integration, and user experience.

5. Rework can be expensive

Late defects are usually more expensive because the team may need to redo completed work.

Example:

If password reset was built incorrectly, the team may need to change requirements, code, tests, documentation, and training materials.

Simple teaching line

Traditional quality often checks quality at the end. Agile tries to build quality throughout the work.

A good classroom example:

“If students write the whole assignment first and only check grammar at the end, fixing problems may be difficult. But if they check each section while writing, quality is built in earlier.”

REF: AI Tools/ChatGPT as is

This is a team-level dashboard.

It answers:

How is the team doing right now, and what should we act on today or this sprint?

1. Sprint progress

This shows whether the team is on track to complete the sprint goal.

Teaching line:

Sprint progress tells the team whether the current sprint is moving toward completion.

Example:

Burndown line is above ideal → more work remains than expected → team may be behind.

2. Quality

This shows whether the team is delivering good work, not just fast work.

Teaching line:

Quality tells the team whether completed work is reliable, usable, and maintainable.

Example:

Velocity is high, but escaped defects are also high → team may be moving fast but not building quality in.

3. Blockers

This shows what is preventing the team from finishing work.

Teaching line:

Blockers show where the team needs to swarm, help each other, or escalate.

Example:

Three stories are waiting for API access from another team → dependency blocker.

4. Team health

This shows how sustainable and healthy the team is.

Teaching line:

Team health shows whether the team can continue delivering sustainably.

Example:

Team completed the sprint, but everyone worked overtime and satisfaction dropped → delivery may not be sustainable.

Simple classroom explanation

“A team dashboard is not mainly for executives. It helps the Agile team inspect and adapt during the sprint. It shows sprint progress, quality, blockers, and team health so the team knows what to fix next.”

Best short explanation

Team dashboard = daily/sprint-level decision dashboard. It helps the team see whether work is progressing, quality is good, blockers need attention, and the team is healthy enough to keep delivering.

REF: ChatGPT/AI Tools

This is usually a program manager / product manager / ART-level dashboard idea.

It answers:

Are features moving forward, are cross-team dependencies under control, and can we predict delivery with confidence?

1. Feature progress

This shows how much work has been completed for major features.

Example questions:

Example:

Teaching line:

Feature progress tells us whether important product capabilities are moving toward completion.

2. Dependencies

This shows whether one team is waiting for another team, system, vendor, or decision.

Example questions:

Example:

Teaching line:

Dependencies show where work may get stuck because one team needs something from another team.

3. Predictability

This shows whether the team or program usually delivers what it planned.

Example questions:

Example:

Teaching line:

Predictability tells us how confidently we can trust the plan.

Simple classroom explanation

“Feature progress tells us what is being delivered. Dependencies tell us what might block delivery. Predictability tells us whether the plan is realistic based on past delivery.”

Best short explanation

This dashboard helps managers see whether features are progressing, whether dependencies need attention, and whether delivery forecasts are reliable.

REF: AI Tools/ChatGPT

Executive dashboard means a high-level dashboard for senior leaders, not for daily team work.

It should answer:

Are our major initiatives healthy, delivering outcomes, within risk tolerance, and within budget?

1. Portfolio health

This shows whether the organization’s major projects/programs are generally on track.

Examples:

Teaching line:

Portfolio health tells executives whether the overall project portfolio is healthy or at risk.

2. Outcomes

This shows whether the work is producing business/customer value, not just activity.

Examples:

Teaching line:

Outcomes show whether the work is creating value, not just completing tasks.

3. Risk

This shows major threats that could affect delivery, quality, compliance, security, or business results.

Examples:

Teaching line:

Risk tells executives where attention or escalation may be needed.

4. Budget

This shows whether spending is aligned with the plan and expected value.

Examples:

Teaching line:

Budget shows whether investment is controlled and aligned with business value.

Simple classroom explanation

“A team dashboard asks: What should the team do today?
An executive dashboard asks: Are we investing in the right work, getting value, managing risk, and staying within budget?”

Example executive dashboard

Best short explanation:

Executive dashboard = big-picture decision dashboard. It focuses on portfolio health, business outcomes, major risks, and budget so leaders can decide where to invest, intervene, or adjust strategy.

Ref: ChatGPT/AI Tools

CSAT — Customer Satisfaction Score

CSAT measures how satisfied customers are with a specific product, feature, service, or interaction.

Usually the customer is asked:

“How satisfied were you with this experience?”

Common scale:

1 to 5
1 = very dissatisfied
5 = very satisfied

Example:

After using a new checkout feature, customers rate it 4.5 out of 5.

Teaching line:

CSAT tells us whether customers are happy with what was delivered.

NPS — Net Promoter Score

NPS measures customer loyalty and likelihood of recommendation.

Usually the customer is asked:

“How likely are you to recommend this product to a friend or colleague?”

Scale:

0 to 10

General interpretation:

Teaching line:

NPS tells us whether customers like the product enough to recommend it.

CES — Customer Effort Score

CES measures how easy or difficult it is for customers to complete a task.

Usually the customer is asked:

“How easy was it to complete this task?”

Example tasks:

• reset password,
• place an order,
• submit a support request,
• find a product,
• complete checkout.

Teaching line:

CES tells us how much effort the customer had to spend. Lower effort usually means a better user experience.

Simple comparison

Easy example

For a campus food ordering app: