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:

Static analysis means:

Using automated tools to examine source code without running the program.

These tools scan the code and detect possible problems such as:

Your Agile metrics slide describes static code analysis as automated analysis of source code to identify potential bugs and security vulnerabilities.

Simple teaching line

Static analysis is like an automated code reviewer that checks the code before it runs.

Example tools:

SonarQube, ESLint, Checkstyle, PMD, SpotBugs, CodeQL.

Ref: ChatGPT/AI Tools

Code quality metrics help the team judge whether the code is easy to understand, safe to change, reliable, efficient, and not creating future problems. Your Agile metrics slides describe code quality as how well-written, maintainable, and defect-free the codebase is, including readability, consistency, efficiency, standards, and technical debt reduction.

Simple teaching line

Good code quality means the code works today and remains easy to change tomorrow.

Example for students

A feature may “work,” but if the code is messy, slow, hard to test, and full of shortcuts, then quality is still low. Good Agile teams do not only ask:

“Does it work?”

They also ask:

“Is it understandable, testable, reliable, efficient, and safe to maintain?”

Ref: AI Tools/ChatGPT

For a customer, the most useful number is usually:

Lead Time

Because lead time measures the customer’s waiting time.

Simple comparison

Example

A customer requests a new feature on Monday.

The team starts working on it on Thursday.

The feature is delivered on Friday.

From the customer’s view, the answer is:

“I waited 5 days.”

So lead time is most customer-focused.

Teaching line

Customers usually care about lead time because it tells them how long they wait for value. Teams care about cycle time and throughput because those help improve the system that produces that value.

A good short answer:

Lead time is most useful for customers. Cycle time and throughput are more useful for the team to manage and improve delivery.

REF: ChatGPT/AI Tools as is

For a Sprint Burndown Chart, the x-axis is usually the days inside the sprint.

Sprint burndown

Example:

So for a 2-week sprint, the x-axis may show:

Day 1, Day 2, Day 3 … Day 10

or actual dates:

July 1, July 2, July 3 … July 14

When would x-axis be “sprints”?

That is usually for a release burndown or product/release tracking, not a sprint burndown.

Teaching line

Sprint burndown tracks daily progress inside one sprint. Therefore, the x-axis is normally days or dates, and the y-axis is remaining work.

So the answer is:

For sprint burndown, use day/date on the x-axis.
For release burndown, use sprints/iterations on the x-axis.

Ref: AI Tools/ChatGPT as is