PSM III Understanding and Applying the Scrum Framework

Understanding and Applying the Scrum Framework Detailed Explanation

Scrum is an agile framework used primarily for software development but applicable to various complex work environments. It promotes flexibility, teamwork, and iterative progress to maximize value delivery. This section will provide a detailed, beginner-friendly explanation of Scrum’s foundation, roles, events, and artifacts.

1.1 Theoretical Foundations of Scrum

Scrum is based on empirical process control, which means that decisions are made based on observation, experimentation, and experience rather than strict plans. It is an iterative and incremental approach that enables teams to deliver small, usable pieces of a product while continuously improving their work.

1.1.1 Empirical Process Control

Empirical Process Control is based on the idea that complex work cannot be fully defined upfront. Instead, teams must work adaptively by making decisions based on real-world experience and feedback. The three pillars of empirical process control are:

1. Transparency

Transparency ensures that all aspects of the Scrum process are visible to the team, stakeholders, and the organization.

• Clear visibility into work progress, challenges, and outcomes.
• Well-defined artifacts (e.g., Product Backlog, Sprint Backlog, Increment).
• Agreed-upon definitions such as the Definition of Done (DoD) to ensure consistency.
• Regular communication among team members, stakeholders, and customers.

Example:

If the team’s progress is not visible to stakeholders, decision-making becomes difficult. Scrum addresses this by requiring clear documentation of work, using tools like task boards and burndown charts.

2. Inspection

Frequent inspection of work, progress, and processes helps detect issues early.

• Daily stand-up meetings (Daily Scrum) allow team members to assess their progress.
• Sprint Reviews let stakeholders inspect the increment and provide feedback.
• Sprint Retrospectives help the team reflect on what worked well and what needs improvement.

Example:

A Scrum Team working on a software product might conduct a Sprint Review to demo a new feature and gather feedback. If the feedback indicates that users struggle with a particular function, the team can make necessary adjustments.

3. Adaptation

When something is not working, the team must adapt quickly to improve the process or product.

• If a feature does not meet user expectations, the backlog should be adjusted.
• If a bottleneck slows down development, the team should adjust their workflow.
• If customers’ needs change, priorities in the backlog must shift.

Example:

If a company originally planned to develop a mobile-first application but later learns through customer feedback that desktop users are the primary audience, the team must adapt and reprioritize backlog items accordingly.

1.1.2 Incremental and Iterative Development

Scrum encourages both incremental and iterative development.

• Incremental Development – The team delivers small, usable parts of the product in each Sprint rather than waiting until the end of a project to release everything.
• Iterative Development – The team continuously refines, improves, and adapts the product based on feedback and testing.

Development Approach	Definition	Example
Incremental	Delivering smaller, usable parts of the product over time	A music app releases a basic player first, then adds playlists, then social sharing.
Iterative	Continuously improving existing features based on feedback	A messaging app releases a chat feature, gathers feedback, and improves it before adding voice calls.

Example:

Consider an e-commerce website:

1. In Sprint 1, the team delivers the login system.
2. In Sprint 2, they add the shopping cart feature.
3. In Sprint 3, they introduce a payment system.

Each Sprint builds upon the previous work, ensuring value is delivered consistently.

1.2 Scrum Roles and Responsibilities

Scrum defines three key roles, each with specific responsibilities:

1. Scrum Master – Ensures the Scrum process runs smoothly.
2. Product Owner (PO) – Manages the Product Backlog and represents stakeholders.
3. Developers – The team responsible for delivering a working product.

Each role has a unique contribution to Scrum, ensuring collaboration and accountability.

1.2.1 Scrum Master

The Scrum Master is not a traditional project manager but a servant-leader who ensures that the team adheres to Scrum values and principles.

Key Responsibilities:

• Facilitates Scrum Events – Ensures that Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective happen efficiently.
• Removes Impediments – Helps the team resolve obstacles that slow down progress.
• Coaches the Team – Guides team members in adopting agile practices and improving collaboration.
• Protects the Team – Shields the team from distractions and external pressure.

Example:

A Scrum Master notices that a stakeholder keeps interrupting the team during the Sprint, demanding last-minute changes. The Scrum Master educates the stakeholder on how Scrum works and channels their requests into backlog refinement.

1.2.2 Product Owner (PO)

The Product Owner is responsible for maximizing the value of the product and managing the Product Backlog.

Key Responsibilities:

• Defines and Communicates Product Vision – Ensures the team and stakeholders have a shared understanding of goals.
• Manages and Prioritizes the Product Backlog – Orders backlog items to ensure that the most valuable features are developed first.
• Represents Stakeholders – Gathers feedback from customers, business teams, and executives.

Example:

A Product Owner at a fintech company prioritizes security features first because regulatory compliance is critical, delaying the development of social features until later.

1.2.3 Developers

Developers (or the Development Team) are responsible for delivering high-quality work that meets the Definition of Done (DoD).

Key Responsibilities:

• Self-organize – Decide how to complete work without external micromanagement.
• Develop Product Increments – Write code, test functionality, and integrate features.
• Collaborate with the Product Owner – Provide technical insights and effort estimations.

Example:

If the PO asks the team to build a new login system, Developers collaborate to decide how to implement it, whether it should use OAuth, multi-factor authentication, or email login, ensuring it meets security standards.

1.3 Scrum Events (Ceremonies)

Scrum defines five key events, which serve as opportunities for team collaboration, inspection, and adaptation. These events help teams work effectively by ensuring transparency, minimizing risks, and maintaining focus.

Event	Purpose	Timebox
Sprint	A fixed-length iteration where work is completed and delivered	1–4 weeks
Sprint Planning	Plan work for the Sprint	8 hours (for a 4-week Sprint)
Daily Scrum	Synchronize work and identify obstacles	15 minutes per day
Sprint Review	Present work done and gather feedback	4 hours (for a 4-week Sprint)
Sprint Retrospective	Reflect and improve team processes	3 hours (for a 4-week Sprint)

1.3.1 Sprint

The Sprint is the heart of Scrum, providing a structured timebox for delivering a usable product increment.

Key Characteristics of a Sprint

• Fixed length (1 to 4 weeks) – Ensures a predictable rhythm.
• Once started, the duration does not change – Provides stability for planning and execution.
• Delivers a usable increment – Each Sprint should produce a potentially shippable product.
• No changes that endanger the Sprint Goal – Helps the team stay focused.

Sprint Workflow Example

1. Sprint Planning – The team selects work items and defines the Sprint Goal.
2. Daily Scrum – Team members discuss progress and adjust their plan.
3. Development Work – The team works to complete Sprint Backlog items.
4. Sprint Review – The team demonstrates completed work to stakeholders.
5. Sprint Retrospective – The team reflects on how to improve in the next Sprint.

Example:

A team developing an online shopping cart might work on implementing coupon functionality in one Sprint. At the end of the Sprint, they present a working feature that allows users to apply discount codes.

1.3.2 Sprint Planning

Sprint Planning is the first event of the Sprint, where the Scrum Team decides:

1. What can be delivered in this Sprint?
2. How will the work be achieved?

Inputs to Sprint Planning

• Product Backlog – Provides prioritized work items.
• Team Capacity – The available time and resources for the Sprint.
• Past Sprint Performance – Helps estimate realistic workload.

Sprint Planning Steps

1. Define the Sprint Goal – The guiding objective for the Sprint.
2. Select Product Backlog Items (PBIs) – Choose work that aligns with the goal.
3. Break down PBIs into tasks – Developers define how to complete the work.

Example:

For a music streaming app, the Sprint Goal might be:
"Allow users to create and save playlists."

The selected backlog items might include:

• Design playlist UI.
• Implement playlist storage.
• Develop an API for managing playlists.

The Developers then break these items into tasks such as:

• "Create a database table for playlists."
• "Design UI for adding/removing songs."
• "Write unit tests for playlist creation."

1.3.3 Daily Scrum

The Daily Scrum is a short (15-minute) meeting where Developers synchronize work and identify obstacles.

Purpose of Daily Scrum

• Ensure alignment – Everyone knows what others are working on.
• Identify impediments – Blockers can be addressed quickly.
• Adjust plans if needed – Ensures flexibility in execution.

Daily Scrum Questions

Each Developer answers three key questions:

1. What did I accomplish yesterday?
2. What will I work on today?
3. Do I have any impediments?

Example:

• Yesterday: "I completed the login screen UI."
• Today: "I will integrate the login UI with authentication API."
• Blockers: "The API team has not finalized authentication endpoints."

Common Mistakes in Daily Scrum

Turning it into a status report instead of a collaborative discussion.
Letting it drag beyond 15 minutes.
Allowing managers or stakeholders to take control of the meeting.

1.3.4 Sprint Review

The Sprint Review is held at the end of the Sprint to inspect the increment and gather feedback.

Purpose of Sprint Review

• Demonstrate completed work – The team shows what was achieved.
• Gather feedback – Stakeholders provide input on the increment.
• Adjust the Product Backlog – New insights may change priorities.

Who Attends the Sprint Review?

• Scrum Team
• Product Owner
• Stakeholders (users, customers, business teams)

Sprint Review Agenda

1. Presentation of the Increment – Developers showcase the finished work.
2. Discussion on business impact – Product Owner and stakeholders analyze results.
3. Backlog adjustments – The Product Owner updates priorities based on feedback.

Example:

A team building a ride-sharing app presents a new feature allowing users to share ride fares. Stakeholders request a button to split the payment equally, which gets added to the backlog for a future Sprint.

Common Mistakes in Sprint Reviews

Treating it as a formal approval meeting instead of a collaborative feedback session.
Showing unfinished work that does not meet the Definition of Done.
Ignoring feedback from stakeholders.

1.3.5 Sprint Retrospective

The Sprint Retrospective is the final event in the Sprint, allowing the team to reflect on their process and make improvements.

Purpose of the Sprint Retrospective

• Identify what worked well.
• Discuss what didn’t work and why.
• Agree on actions for continuous improvement.

Sprint Retrospective Format

1. What went well? – Recognize successful practices.
2. What can be improved? – Discuss challenges.
3. What actions should be taken? – Define improvements for the next Sprint.

Example:

A team working on an e-learning platform realizes:

• What went well: "User authentication was implemented smoothly."
• What can be improved: "Testing took longer than expected due to unclear acceptance criteria."
• Action item: "Improve acceptance criteria during backlog refinement."

Common Pitfalls in Sprint Retrospectives

Blaming individuals instead of focusing on process improvement.
Ignoring retrospective insights and failing to implement improvements.
Skipping retrospectives when things seem to be going well.

1.4 Scrum Artifacts

Scrum defines three primary artifacts:

Artifact	Purpose
Product Backlog	A prioritized list of all potential product features and improvements.
Sprint Backlog	A subset of the Product Backlog selected for a Sprint, including a detailed execution plan.
Increment	The sum of all completed work items that meet the Definition of Done (DoD).

Each artifact ensures that the work being done is visible and understood by all stakeholders.

1.4.1 Product Backlog

The Product Backlog is an ordered list of all potential features, enhancements, bug fixes, and technical improvements for the product.

Characteristics of the Product Backlog

• It is dynamic – It evolves as new information emerges.
• It is prioritized – Items with higher business value appear at the top.
• It is owned by the Product Owner – The PO ensures that it aligns with business objectives.
• It is refined continuously – Items must be well-defined before being selected for a Sprint.

Product Backlog Items (PBIs)

Each item in the backlog is a Product Backlog Item (PBI). Common types of PBIs include:

• User Stories – Features described from a user's perspective.
• Bugs – Issues that need fixing.
• Technical Debt – Improvements to maintain code quality.
• Spikes – Research tasks to explore technical solutions.

Example of a User Story Format:

"As a user, I want to reset my password so that I can regain access to my account."

This follows the format:

• Who (user type)
• What (functionality)
• Why (business value)

Backlog Refinement

Backlog refinement (or grooming) ensures that items are clear, estimated, and ready for development.

Key activities in refinement:

1. Adding new items based on stakeholder feedback.
2. Breaking down large PBIs into smaller, manageable parts.
3. Estimating effort required to complete each item.

1.4.2 Sprint Backlog

The Sprint Backlog is a subset of the Product Backlog selected for a Sprint, along with a detailed execution plan.

Characteristics of the Sprint Backlog

• It is created during Sprint Planning – The team selects PBIs based on priority and capacity.
• It contains tasks and an execution plan – Developers decide how to implement each item.
• It is owned by the Developers – Only Developers can modify the Sprint Backlog.

Components of a Sprint Backlog

Component	Description
Sprint Goal	The objective the team aims to achieve.
Selected PBIs	The work items chosen for the Sprint.
Task Breakdown	A detailed plan for completing each PBI.

Example of a Sprint Goal:

"Improve user authentication by implementing two-factor authentication (2FA)."

How the Sprint Backlog Evolves

• Tasks are continuously updated as progress is made.
• New insights may emerge, requiring adaptation within the Sprint.
• Work cannot be removed or added arbitrarily—any changes must align with the Sprint Goal.

1.4.3 Increment

An Increment is the sum of all completed work items that meet the Definition of Done (DoD).

Characteristics of an Increment

• It is a step toward the final product – Each increment builds upon previous work.
• It must be usable – Even if not released, it should be functional.
• It is inspected in the Sprint Review – Stakeholders provide feedback before the next iteration.

Example of an Increment:

If a team is developing a ride-sharing app, an increment might be:
"Users can book rides and view driver details, with payments processed securely."

This increment meets business needs, is tested, and is potentially shippable.

1.5 Definition of Done (DoD)

The Definition of Done (DoD) ensures that work is completed to a high standard before being considered part of an increment.

Why DoD Matters

• Ensures quality – Prevents unfinished work from accumulating.
• Creates consistency – Defines what "done" means for the team.
• Improves transparency – Stakeholders know what to expect.

Typical DoD Criteria

Code is written, reviewed, and merged.
Features are tested (unit, integration, acceptance tests).
Documentation is updated.
The increment is deployable.

Example:

A team building a mobile app might define DoD as:
"Feature must be implemented, tested on three devices, and reviewed before being merged into the main branch."

1.6 Scrum Values

Scrum is built upon five core values that guide behavior and decision-making:

1. Commitment – The team commits to delivering high-quality work.
2. Focus – The team focuses on Sprint Goals and avoids distractions.
3. Openness – Transparency is essential for trust and collaboration.
4. Respect – Team members respect each other’s contributions.
5. Courage – Teams must take responsibility and address challenges directly.

1.7 Scrum Anti-Patterns

Anti-patterns are common pitfalls that prevent teams from following Scrum effectively.

1.7.1 Common Scrum Master Anti-Patterns

• Acting as a project manager – Controlling tasks instead of facilitating collaboration.
• Not protecting the team – Allowing external interruptions to disrupt work.
• Skipping retrospectives – Ignoring process improvements.

1.7.2 Common Product Owner Anti-Patterns

• Neglecting the backlog – Not prioritizing or refining items.
• Overloading the team – Assigning too much work for a Sprint.
• Lack of stakeholder engagement – Failing to gather feedback regularly.

1.7.3 Common Developer Anti-Patterns

• Ignoring Definition of Done – Delivering incomplete work.
• Working in silos – Not collaborating with teammates.
• Skipping testing – Rushing development without ensuring quality.

1.8 Scaling Scrum

While Scrum is designed for small teams, larger organizations may need scaling frameworks.

Scaling Framework	Description
LeSS (Large-Scale Scrum)	Minimalist approach for multiple Scrum teams.
SAFe (Scaled Agile Framework)	Provides structure for enterprise-wide agility.
Scrum@Scale	Uses interconnected Scrum teams for complex projects.

Example:

A company with six Scrum teams working on a banking application might adopt LeSS to ensure alignment while maintaining agility.

1.9 Advanced Scrum Topics

Scrum is highly adaptable, but real-world challenges require advanced strategies to maintain agility and efficiency. This section covers common challenges teams face when applying Scrum in complex environments.

1.9.1 Handling Distributed Scrum Teams

In an ideal Scrum setup, teams work together in the same location to maximize collaboration. However, many organizations have distributed teams spread across different locations or time zones.

Challenges of Distributed Teams

1. Time Zone Differences – Teams in different regions have limited overlapping work hours.
2. Communication Gaps – Fewer face-to-face discussions lead to misunderstandings.
3. Lack of Team Bonding – Remote members may feel disconnected.
4. Difficulties in Maintaining Transparency – Work progress and impediments may not be visible.

Best Practices for Distributed Scrum Teams

Challenge	Solution
Time Zone Issues	Define overlapping core work hours. Use asynchronous updates when necessary.
Communication Gaps	Use video calls for Sprint Planning, Reviews, and Retrospectives. Encourage written documentation for decisions.
Lack of Team Bonding	Host virtual team-building events and encourage informal interactions.
Transparency Issues	Use visual tools like Jira, Trello, or Confluence to track work. Keep work progress visible to all.

Example

A Scrum Team with members in the US, India, and Germany implements "core working hours" from 2 PM to 5 PM GMT, ensuring at least three hours of overlap for real-time collaboration.

1.9.2 Improving Cross-Team Collaboration in Scrum

When multiple teams work on the same product, ensuring alignment and integration can be difficult. Frameworks like Scrum of Scrums, LeSS, and SAFe help teams coordinate efforts.

Common Challenges in Multi-Team Scrum Environments

1. Dependencies between teams – One team's work may block another team's progress.
2. Inconsistent priorities – Teams may have conflicting Sprint Goals.
3. Integration issues – Work delivered by different teams may not fit together properly.

Techniques for Cross-Team Collaboration

Challenge	Solution
Managing Dependencies	Use Scrum of Scrums meetings to identify and resolve blockers early.
Aligning Priorities	Synchronize Sprint Goals across teams during a joint Sprint Planning session.
Avoiding Integration Issues	Implement continuous integration and automated testing to ensure compatibility.

Scrum of Scrums

A Scrum of Scrums meeting is a scaled Daily Scrum where representatives from different teams discuss:

1. What has our team completed?
2. What are we working on next?
3. Are we blocked by another team?

Example

A company developing an e-commerce platform has three Scrum Teams:

• Team A builds the checkout system.
• Team B develops the payment gateway.
• Team C manages the user authentication system.

To prevent delays, they meet three times a week in a Scrum of Scrums to ensure dependencies are managed.

1.9.3 Handling Mid-Sprint Interruptions

Scrum teams aim to focus solely on their Sprint Backlog during the Sprint. However, unexpected urgent work may arise.

Common Types of Mid-Sprint Interruptions

1. Critical production issues – Bugs or outages that require immediate attention.
2. Urgent stakeholder requests – High-priority business needs that emerge suddenly.
3. Scope creep – Stakeholders attempting to add new work to the Sprint.

How to Handle Mid-Sprint Interruptions

Type of Interruption	Recommended Action
Critical Production Issues	Define a buffer (e.g., 10% of Sprint capacity) to handle emergencies. If major, consider stopping the Sprint.
Urgent Stakeholder Requests	Product Owner evaluates urgency. If essential, add to the next Sprint. If critical, swap an item of equal effort.
Scope Creep	Educate stakeholders on Sprint commitments. Changes go into the backlog for future Sprints.

Example

A Scrum Team at a bank is developing a loan approval system. Mid-Sprint, a security vulnerability is discovered in production. The team pauses one non-critical Sprint task to address the issue and ensure compliance.

1.10 Common Pitfalls and How to Avoid Them

Even experienced Scrum teams can fall into anti-patterns that reduce agility and efficiency.

1.10.1 Common Scrum Master Mistakes

Mistake	Solution
Acting as a project manager	Focus on coaching and facilitating rather than directing.
Not enforcing Scrum rules	Ensure adherence to timeboxing, roles, and artifacts.
Ignoring team morale	Regularly check for burnout and resolve team conflicts.

1.10.2 Common Product Owner Mistakes

Mistake	Solution
Backlog items are not clearly defined	Use the INVEST principle (Independent, Negotiable, Valuable, Estimable, Small, Testable).
PO is not available to the team	Allocate fixed hours to work closely with Developers.
Too many low-priority items in Sprint	Prioritize work using WSJF or MoSCoW method.

1.10.3 Common Developer Mistakes

Mistake	Solution
Ignoring the Definition of Done	Enforce DoD in every Sprint Review.
Not collaborating with teammates	Encourage pair programming and knowledge sharing.
Skipping testing to speed up delivery	Use automated tests and continuous integration.

Understanding and Applying the Scrum Framework (Additional Content)

1. Scrum Master in Non-Agile Environments

1.1 Responding to Anti-Agile Organizational Culture

In reality, many organizations claim to “do Scrum” but retain a command-and-control mindset. The Scrum Master must act as a change agent in such situations.

Common Organizational Anti-Patterns

• Management still expects status reports, Gantt charts, or milestone tracking.

• Teams are judged by velocity instead of delivered value.

• Scrum is treated as a delivery process, not a mindset.

Scrum Master’s Role

• Educate leaders on empiricism: that planning must be adaptive in complex domains.

• Shield the team from micromanagement or unjustified reporting.

• Facilitate learning loops through Sprint Reviews and Retrospectives to generate organizational insights.

Example

A manager demands mid-Sprint scope changes because of executive pressure.
The Scrum Master invites the manager to the Sprint Review instead and explains how work is planned and inspected based on incremental value, not status-driven control.

1.2 Supporting an Immature or Dysfunctional Team

Scrum only works if teams self-organize and take ownership. But early-stage teams often lack psychological safety, collaboration habits, or technical discipline.

Scrum Master Interventions

• Introduce team working agreements to encourage accountability.

• Use Retrospective formats that help surface interpersonal issues.

• Help the team gradually adopt technical excellence practices (Definition of Done, pair programming, CI/CD).

Realistic Mindset

The Scrum Master should meet the team where they are, and coach them towards maturity—not impose a “perfect Scrum” ideal from day one.

1.3 Handling Stakeholder Overreach

Some stakeholders try to:

• Join Daily Scrums to monitor progress.

• Bypass the Product Owner to influence team priorities.

• Introduce last-minute requests without respecting the Backlog.

Scrum Master Strategies

• Clarify roles and boundaries during Sprint Reviews and Backlog Refinement.

• Ensure the Product Owner is empowered as the single source of backlog priorities.

• Educate stakeholders that transparency comes through artifacts and Scrum events, not through control.

2. Scrum Principles vs. Real-World Challenges

2.1 Why Scrum Enforces Timeboxing

Timeboxing brings discipline and urgency to complex work. Without time limits:

• Work tends to expand indefinitely (Parkinson’s Law).

• Teams over-engineer and delay feedback.

Timeboxing ensures frequent learning, inspectable outputs, and faster adaptation.

Example: Sprint Timebox

Scrum insists the Sprint is never extended, even if work is incomplete. This forces teams to:

• Learn better estimation.

• Improve backlog refinement.

• Focus on the Sprint Goal over perfect delivery.

2.2 Why Sprint Scope Should Not Be Changed Mid-Sprint

Changing scope mid-Sprint:

• Breaks focus and disrupts flow.

• Undermines team ownership of commitment.

• Prevents measuring progress toward Sprint Goals.

Instead, Scrum encourages placing new work in the Product Backlog and addressing it in the next Sprint.

2.3 The Empirical Rationale

Scrum is rooted in empirical process control: transparency, inspection, and adaptation.

It was designed for complex domains where predictive methods fail.
The structure of Sprints, artifacts, and roles supports real-time learning, not pre-scripted control.

3. Critical Thinking about Scrum

3.1 When Scrum Might Not Be the Right Choice

Scrum is not a one-size-fits-all solution. It is less suitable when:

• Work is highly repetitive or well-defined, such as factory operations.

• The team cannot be cross-functional or lacks autonomy.

• The organization is not willing to embrace empirical thinking or iterative delivery.

Alternative Approaches

• Use Kanban if flow and throughput are more important than timeboxes.

• Use Waterfall when requirements are known and fixed (e.g., legal documentation, medical standards).

3.2 Limitations of Scrum

• Scrum does not prescribe technical practices (e.g., TDD, DevOps), though these are critical for success.

• Scrum assumes a level of organizational maturity that might not exist.

• Misinterpreting roles—especially turning the Scrum Master into a project manager—can derail effectiveness.

4. Comparisons That Highlight Scrum’s Uniqueness

4.1 Scrum vs. Traditional Project Management

Aspect	Scrum	Waterfall
Planning	Adaptive, ongoing	Fixed, upfront
Roles	PO, SM, Developers	Project Manager-driven
Deliverables	Incremental, usable each Sprint	Final product at end
Change Management	Embraced through Backlog	Formal change requests
Feedback Cycle	Every Sprint (1–4 weeks)	End of project (months/years)

4.2 Scrum vs. Kanban

Aspect	Scrum	Kanban
Timeboxing	Yes (Sprints)	No (continuous flow)
Roles	Defined (SM, PO, Dev)	Optional
Commitments	Sprint Goal	WIP limits
Change Policy	Locked during Sprint	Flexible

Scrum focuses on cadence and team dynamics, while Kanban emphasizes flow and visualization.

Conclusion

In PSM III, demonstrating that you understand not just what Scrum is, but why it is designed this way, and how to adapt it intelligently in real-world challenges, is the difference between average and excellent answers.