Interview Q&A

A Scrum Team is composed of three primary roles:

• Product Owner – Responsible for maximizing the value of the product and

managing the Product Backlog.

• Scrum Master – Acts as a servant-leader, facilitating the Scrum process and

removing impediments.

• Development Team – A cross-functional group that builds the product increment

each Sprint.

Example:

In a software startup developing a new mobile app, the Product Owner gathers customer

needs and prioritizes them. The Scrum Master ensures daily stand-ups run smoothly and

helps remove blockers like server access issues. The Development Team (UI/UX designers,

front-end and back-end developers) work together to deliver usable features every two

weeks.

Follow On:

Follow On:

Definition:

The Product Backlog is an ordered list of everything that might be needed in the product,

serving as the single source of work for the Scrum Team.

How to maintain it:

• Continuously refine items for clarity, detail, and priority.
• Regularly update it based on feedback, market changes, and stakeholder input.
• Collaborate with the team to ensure shared understanding.

Real-World Example:

For a streaming platform, the backlog might start with high-level features like “Watchlist” and

“User Reviews”. As sprints progress, these are broken down into more detailed items like

“Add to Watchlist Button” or “Review Moderation Rules”.

In Scrum, scope creep is managed by controlling what goes into a Sprint — not by

freezing the entire project.

How it’s handled:

• Sprint scope is locked once planning ends. No changes mid-Sprint without

discussion and agreement.

• Product Backlog remains flexible, so new ideas or requirements are added there

— not injected into the current Sprint.

• The Product Owner (PO) decides what gets prioritized for future Sprints.

Example:

If a stakeholder requests a new login method during the Sprint, the PO thanks them, adds it

to the Product Backlog, and it’s considered in the next planning session — not immediately

worked on.

Follow On:

Aspect Scrum Kanban Extreme Programming

(XP)

Framework

Type

Prescriptive, timeboxed

(Sprints)

Flow-based,

continuous delivery

Engineering-focused

Agile methodology

Roles PO, Scrum Master, Dev

Team

No defined roles Coach, Developer,

Customer (on-site)

Work

Planning

Sprint Backlog (2–4

weeks)

Continuous pull

from board

Iterations, similar to

Sprints

Change

Policy

No changes during a

Sprint

Changes allowed

anytime

Change-resistant within

iteration

Focus Delivery + team

process

Visualizing flow and

limiting WIP

Code quality and

engineering discipline

Practices Daily Scrum, Sprint

Planning, Review,

Retro

Visual board, WIP

limits, Cycle Time

Pair programming, TDD,

CI/CD, Refactoring

Example:

A support team may prefer Kanban for flexibility, while a product dev team building new

features might favor Scrum or XP for structure and code quality practices.

Review the concept and prepare a concise verbal explanation with a real project example.

Purpose:

Sprint Planning sets the direction for the upcoming Sprint. The team collaboratively decides

what can be delivered and how the work will be accomplished.

Key outcomes:

• A clear Sprint Goal.
• A selected set of Product Backlog Items (PBIs) for the Sprint.
• A high-level plan for delivering those items.

Real-World Example:

In a team building a customer support chatbot, the Product Owner presents the most

valuable backlog items. The team discusses capacity and agrees to focus on implementing

“Chatbot FAQ logic” and “User intent recognition.” These become the Sprint backlog.

What didn’t?

Techniques to prioritize:

• MoSCoW (Must, Should, Could, Won’t)
• Kano Model (Basic, Performance, Delighter)
• Value vs. Effort Matrix
• Weighted Shortest Job First (WSJF) in SAFe

Factors to consider:

• Customer value
• Business impact
• Risk reduction
• Dependencies

Follow On:

• Technical feasibility

Example:

A travel app team uses Value vs. Effort to prioritize. “In-app booking” has high value and

moderate effort, while “Flight status tracking” has high effort and low impact — so the former

gets scheduled first.

• Team members independently assign story points, then discuss differences.

Effort is typically estimated using relative sizing methods:

✅ Story Points (most common)

✅ Planning Poker (a team-based game using consensus to estimate)

✅ T-shirt sizes (S, M, L, etc., for quick high-level sizing)

Story Points consider:

• Complexity
• Amount of work
• Risks or unknowns

Example:

A login screen might be a 2-point story (simple, well understood). A feature with integrations

and security considerations may be 8 points due to complexity and risk.

Pro Tip:

Avoid estimating in hours — it introduces false precision. Focus on relative effort, not

duration.

Scrum defines three key artifacts:

• Product Backlog – A prioritized list of everything that might be needed in the

product, maintained by the Product Owner.

• Sprint Backlog – A subset of the Product Backlog items selected for the current

Sprint, along with a plan for delivering them.

• Increment – The sum of all completed work that meets the Definition of Done at the

end of a Sprint.

Example:

If your product is an e-commerce website, the Product Backlog could include features like

"Add to Cart", "Payment Gateway", and "User Login". In the current Sprint, the Sprint

Backlog may include just “User Login” and “Add to Cart”. At the end of the Sprint, a working

login system is delivered as the Increment.

Purpose:

The Daily Scrum is a 15-minute timeboxed event for the Development Team to inspect

progress toward the Sprint Goal and adapt the plan.

Effective format (common but not mandatory):

• What did I do yesterday?
• What will I do today?
• Are there any blockers?

Best Practices:

Follow On:

• Same time, same place daily.
• Focus on progress toward the Sprint Goal.
• Keep it short and to the point.

Real-World Example:

During a mobile app Sprint, a developer mentions a deployment delay due to a

configuration issue. The Scrum Master takes note and helps resolve it after the meeting —

preventing a bottleneck.

Top challenges:

Follow On:

• Team alignment across multiple squads
• Coordination of dependencies
• Shared ownership of product vision
• Overhead from meetings multiplying with team size
• Consistent backlog management
• Resistance to organizational culture change

Example:

If 10 Scrum teams are working on the same e-commerce platform, ensuring consistent UI

standards and integrating features becomes increasingly difficult without coordination

frameworks like Scrum-of-Scrums or SAFe.

SAFe (Scaled Agile Framework) builds on Scrum principles but provides structured

guidance for applying Agile at enterprise scale.

SAFe includes:

• Scrum at the team level
• Agile Release Trains (ARTs) to coordinate multiple teams
• Roles like Release Train Engineer (RTE), Product Management, Solution

Architect

• PI Planning instead of Sprint Planning for synchronization

Example:

A telecom company using SAFe may have 12 Scrum teams working in sync toward a

Program Increment (PI) every 10 weeks, using shared roadmaps and synchronized planning

sessions.

Follow On:

A Sprint is a fixed-length (usually 1–4 weeks) timebox where a usable and potentially

shippable product increment is developed. The Sprint fosters focus, regular delivery, and

continuous improvement.

Example:

A digital agency might run 2-week Sprints to deliver iterative updates to a client’s website.

After each Sprint, the client gets a working piece — such as a new landing page — and

provides feedback that shapes the next Sprint.

Definition:

The Definition of Done is a shared understanding of what “done” means for a backlog item

or Increment. It ensures transparency and consistent quality.

Impact on quality:

• Prevents incomplete work from being marked as finished.
• Reduces rework by setting clear expectations.
• Ensures the Increment is potentially shippable.

Example DoD:

• Code is committed and peer-reviewed
• Unit tests are written and passed
• Integrated into CI/CD pipeline
• User story accepted by Product Owner
• No major bugs in QA

Real-World Example:

Without a DoD, a team may claim a feature is “done” even though it hasn’t been tested.

With a proper DoD, it won’t be considered complete until it’s fully tested, reviewed, and

accepted.

Follow On:

• S, M, L, XL — useful for high-level estimation.

Key enablers:

• Trust: Allow teams to own delivery without micromanagement.
• Clear goals: Provide vision, not step-by-step instructions.
• Cross-functionality: Ensure the team has all necessary skills.
• Scrum Master: Coaches the team, but doesn’t assign tasks.
• Encourage decision-making within the team.

Follow On:

Example:

Instead of telling the team who should build the new feature, let them decide who does what

based on skills and availability. The Scrum Master can step in only if the team is blocked.

Review the concept and prepare a concise verbal explanation with a real project example.

Purpose:

To inspect the Increment and adapt the Product Backlog based on feedback. It’s a

collaborative working session, not a demo-only meeting.

Key components:

• Presentation of what was "Done" in the Sprint.
• Discussion on what went well and challenges faced.
• Stakeholder feedback on the Increment.
• Review of the market or business context.

Real-World Example:

The team presents a new analytics dashboard to stakeholders. Marketing suggests a

change in how data is grouped. The Product Owner logs this feedback into the Product

Backlog for future refinement.

The Product Owner:

• Continuously refines the Product Backlog — even during a Sprint.
• Works with stakeholders and the team to break down large items.
• Clarifies acceptance criteria.
• Re-prioritizes based on new insights.

Example:

Mid-Sprint, the PO learns from sales that customers are struggling with onboarding. They

update the backlog by splitting “User Onboarding Flow” into smaller, clearer stories for the

next Sprint.

Review the concept and prepare a concise verbal explanation with a real project example.

Preferred method:

Most agile teams favor Story Points with Planning Poker to foster team discussion and

build consensus.

Example:

A login screen might be estimated as a 3-point story. A password reset flow involving emails

and error handling might be 5 points.

Follow On:

Scrum-of-Scrums (SoS) is a coordination mechanism where representatives from multiple

Scrum teams meet regularly to discuss progress, dependencies, and blockers.

Structure:

• Each team sends a delegate (often the Scrum Master or a dev lead).
• Frequency varies (e.g., 2–3 times/week).
• Focus is on cross-team coordination, not status reporting.

Example agenda:

• What has your team completed?
• What will your team work on next?
• Are there any blockers or dependencies?

Example:

In a bank's digital transformation project, five Scrum teams are building different modules of

the same app. SoS meetings align delivery and resolve integration issues early.

Aspect Scrum Traditional (Waterfall)

Process Style Iterative and incremental Sequential and linear

Requirements Evolve over time Defined upfront

Follow On:

Team Involvement Cross-functional, collaborative Role-specific, hierarchical

Flexibility to Change High — welcomes changes Low — changes can be

costly

Delivery Frequent, every Sprint At the end of the project

Example:

In traditional construction, everything is planned before a brick is laid. In Scrum, like in

software development, teams build part of the system, get feedback, and adapt — like

adding a new feature based on early user testing.

Definition:

The Sprint Backlog is a subset of Product Backlog items the team commits to deliver in a

Sprint, plus a plan for how to achieve it.

How to manage it:

• Keep it visible and up to date (via a Scrum board or tool like Jira).
• Break down items into tasks during Sprint Planning.
• Update daily during stand-ups based on progress.
• Add tasks if necessary, but don’t change Sprint scope without discussion.

Example:

A team uses a Kanban board with “To Do”, “In Progress”, and “Done” columns. Every day,

they update task statuses so progress is clear and blockers are quickly identified.

Purpose:

To reflect on the Sprint and identify process improvements for the next iteration.

Structure (commonly used):

Follow On:

A Product Increment is the sum of all work completed in the Sprint that meets the

Definition of Done.

Ways to measure:

• Functionality delivered (e.g. completed features)
• Business value delivered (e.g. increase in conversions)
• Quality metrics (e.g. defect rates, test coverage)
• Velocity (amount of work delivered compared to previous Sprints)

Example:

In a SaaS platform, the Sprint delivered “Export to CSV” and “Custom Reports”. These

features are measured by tracking how many users adopt them post-release and how much

support ticket volume drops.

Follow On:

Spotify’s model is not a framework but a cultural model inspired by Agile/Scrum, focusing

on autonomy, alignment, and innovation.

Key concepts:

• Squads = Scrum Teams
• Tribes = Collection of related Squads
• Chapters = Discipline-focused groups (e.g., QA Chapter)
• Guilds = Interest-based communities (e.g., DevOps Guild)

Follow On:

Emphasis on:

• Autonomy with accountability
• Servant leadership
• Agile mindsets over strict roles

Example:

Each Squad at Spotify decides its own tools and ways of working but is aligned on broader

goals and architecture via Tribes and Chapters.

For small teams (3–5):

• Communication is simpler.
• Roles may overlap more (e.g., devs test their own work).

For larger teams (8+):

• Consider splitting into multiple Scrum Teams working on the same product, aligned

by a Scaled Scrum approach (e.g., Nexus, LeSS).

• Use communities of practice for specialized skill-sharing.

Follow On:

For varied skillsets:

• Promote cross-training to reduce silos.
• Use pair programming, knowledge sharing sessions, and code walkthroughs.

Example:

In a team with only one QA, developers start writing automated tests and review each

other’s code to balance the workload.

Scrum fosters continuous improvement through:

• Sprint Retrospective – A dedicated meeting at the end of each Sprint to reflect on

what went well and what can be improved.

• Empowered Teams – Teams are encouraged to experiment and adapt their process.
• Transparency and Inspection – Constant review of progress and adaptation as

needed.

Example:

After noticing delays in code reviews, a team agrees in the Retrospective to set aside daily

time for peer reviews. In the next Sprint, turnaround time improves noticeably.

Purpose:

The Sprint Goal provides focus and alignment for the team. It serves as a shared

objective for the Sprint, guiding decisions and trade-offs.

Defining a good Sprint Goal:

• Collaboratively set during Sprint Planning.
• Clear, concise, and focused on outcome, not just output.
• Tied to business or customer value.

Example:

Instead of “build three reports,” a better Sprint Goal would be:

✅ “Enable users to access key sales insights through interactive reports.”

Real-World Example:

After noticing last-minute testing rushes, the team agrees to integrate testing into the daily

workflow. Next Sprint, they try pairing QA early with devs, reducing defects by 30%.

A well-formed backlog item (often a User Story) should be:

✅ INVEST:

• Independent – Can be developed separately
• Negotiable – Not a fixed contract
• Valuable – Delivers user or business value
• Estimable – Team can estimate its size
• Small – Can be completed within a Sprint
• Testable – Has clear acceptance criteria

Example:

Poor: “Fix bugs”

Better: “As a user, I want error messages when login fails, so I know why I can’t access my

account.”

Best practices:

• Identify and visualize dependencies during PI Planning or Sprint Planning.
• Use Dependency Boards or digital tools (e.g., Jira Advanced Roadmaps).
• Cross-team backlog refinement to surface risks early.
• Encourage cross-functional teams to reduce external dependencies.
• Establish Integration Sprints or teams, if needed.

Example:

In a large retail company, multiple teams need the same API updates. A shared backlog,

joint planning sessions, and dedicated integration owners reduce surprises.

Scrum embraces change by:

• Allowing the Product Backlog to be continuously refined and reprioritized.
• Keeping Sprints short, so changes can be incorporated in the next cycle.
• Fostering close communication between stakeholders and the team.

Follow On:

Example:

A product team building a CRM system receives new legal requirements for data handling.

Instead of derailing the project, the Product Owner updates the backlog, and the team

includes those changes in the next Sprint.

Aspect Product Backlog Sprint Backlog

Follow On:

Owner Product Owner Development Team

Scope All desired features, bugs,

enhancements

Items selected for current Sprint

Timefram

Long-term, evolves continuously Short-term, Sprint-specific

Content Prioritized list of user

stories/features

Detailed tasks and plan for delivering

them

Example:

The Product Backlog includes “User Profile Page”, “Email Notifications”, “2FA Setup”. For

Sprint 4, the team selects “Email Notifications” and breaks it into tasks like “Create email

template”, “Setup backend service”, etc., forming the Sprint Backlog.

Meaningful metrics:

• Velocity (story points per Sprint): Trend, not target.
• Sprint Goal success: Did the team meet their goal?
• Lead Time / Cycle Time: Time from idea to delivery.
• Quality metrics: Bugs found, escaped defects.
• Team health: Engagement, collaboration, and satisfaction.

Caution: Avoid weaponizing metrics. They’re for continuous improvement, not judgment.

Example:

A team’s velocity drops — but it’s because they started writing more automated tests. The

focus remains on sustainable delivery, not chasing numbers.

Definition:

A User Story describes a feature from the end-user’s perspective. It answers: Who wants

it? What do they want? Why do they want it?

Template:

As a [type of user], I want [some goal], so that [some reason].

Best practices:

• Add Acceptance Criteria to clarify expectations.
• Keep it concise, focused, and testable.

Follow On:

Example:

As a shopper, I want to filter products by price range, so I can find items within

my budget.

Acceptance Criteria:

• Price slider from $0–$500
• Real-time update of results
• Works on mobile and desktop

Definition:

A Product Owner Team is a group of Product Owners (or PO + Product Managers) who

collaboratively manage a complex or large product backlog.

You need it when:

Follow On:

• The product is large or has multiple subcomponents.
• Multiple Scrum teams work on shared features or user journeys.
• Work spans multiple markets, compliance zones, or personas.

Structure:

• Chief Product Owner (overarching vision)
• POs for feature areas or team-specific backlogs
• Shared roadmap and prioritization process

Example:

For an enterprise SaaS platform with HR, Finance, and Compliance modules, each module

has a dedicated PO, coordinated by a Chief PO.

Purpose:

To keep the Product Backlog clean, prioritized, and well-understood by the team — ensuring

future Sprints run smoothly.

Best practices:

• Held once or twice per Sprint (not an official Scrum event, but crucial).
• Timebox to avoid fatigue (e.g., 1 hour per week).
• Break down large items (epics) into smaller, actionable stories.
• Clarify acceptance criteria and estimate effort.

Real-World Example:

Before Sprint Planning, the team refines a story called “Implement Dark Mode” by

discussing UI implications, dependencies, and edge cases. They split it into smaller tasks

like “UI toggle”, “Theme handler”, and “User preference saving”.

The Scrum Master facilitates, coaches, and removes obstacles. Unlike a traditional project

manager, they don’t assign tasks or manage timelines.

Scrum Master Project Manager

Facilitates Scrum practices Manages scope, schedule, and

budget

Focuses on team dynamics and

coaching

Focuses on deliverables and

deadlines

Servant leader Authority figure

Example:

If a developer is stuck due to a permissions issue, the Scrum Master will help resolve it. A

project manager might instead adjust timelines or escalate to keep the schedule on track.

Best practices:

• Daily Scrum encourages daily alignment.

Follow On:

• Task ownership is flexible — any team member can pick tasks.
• Use shared goals (Sprint Goal) instead of individual targets.
• Foster a safe environment for asking questions and learning.
• Encourage pairing between devs, designers, testers, etc.

Example:

In a team building a healthcare dashboard, developers work closely with UX designers to

ensure usability and compliance, reviewing designs together before coding begins.

Common estimation techniques:

Non-Functional Requirements (NFRs) like security, performance, and scalability are

treated as part of the Definition of Done (DoD) or explicitly captured in stories or tasks.

Approaches:

• Embed NFRs into acceptance criteria.
• Use technical enabler stories to address infrastructure or performance needs.
• Define NFR-related checklists in DoD.

Example:

For a fintech app, performance NFRs (e.g., “page load < 2 sec”) are part of every story's

DoD. Security is validated through automated scans in CI/CD.

The Product Owner (PO) is the voice of the customer and is responsible for:

• Defining and prioritizing the Product Backlog.
• Maximizing value delivered by the team.
• Making trade-off decisions between features, cost, and time.

Example:

In a fintech app team, the PO decides that user onboarding is more critical than the referral

program, so it’s prioritized in the backlog. This ensures the team focuses on what's most

valuable for launch.

Follow On:

Scrum is great wherever work is complex and iterative. Examples include:

• Marketing – Running campaigns in Sprints, delivering creative content.
• Education – Iteratively building course content or programs.
• Construction Design – Designing in phases, validating with stakeholders.
• Product Design – Developing prototypes and refining via feedback.

Real-World Example:

A university uses Scrum to develop an online learning program. In each Sprint, they deliver

lesson modules, gather student feedback, and adjust content and format accordingly.

Follow On:

Common pitfalls:

• Overcommitting based on optimism, not team capacity.
• No clear Sprint Goal, leading to scattered efforts.
• PO not prepared, causing delays or confusion.
• Ignoring team availability (e.g., vacations, holidays).
• Skipping task breakdown, leading to unclear work.

How to avoid:

• Come prepared with a refined backlog.
• Use velocity or past Sprint performance as a guide.
• Define a meaningful Sprint Goal.
• Factor in team availability.

During the Sprint:

• Feedback is captured but doesn’t change the current Sprint scope.
• Product Owner logs feedback in the Product Backlog.
• Team might discuss it in refinement sessions or plan to act on it in the next Sprint.

Follow On:

During Sprint Review:

• Stakeholders review the Increment.
• Discuss what’s useful, missing, or needs improvement.
• PO adjusts priorities accordingly.

Example:

After a demo, a stakeholder suggests a visual improvement to a dashboard. The team

doesn't implement it immediately but adds it to the backlog and addresses it in the next

Sprint.

The Development Team is responsible for:

• Delivering a potentially shippable increment at the end of each Sprint.
• Self-organizing how they accomplish the work.
• Collaborating closely and maintaining quality.

Example:

A team working on a healthcare dashboard decides among themselves who takes on UI,

backend, and testing tasks — without needing direction from a manager — and ensures the

code is production-ready by Sprint’s end.

Epics:

• Large, high-level features or initiatives that are too big for a single Sprint.
• Broken down into User Stories for implementation.

Relationship:

Epic → Multiple User Stories → Tasks (optional)

Example:

Epic: “User Account Management”

User Stories:

• As a user, I want to register with email.
• As a user, I want to log in with my credentials.
• As a user, I want to reset my password.

Each of these stories can be completed in a separate Sprint and delivered incrementally.

Tips to make Sprint Reviews impactful:

• Invite the right stakeholders (not just managers).
• Demonstrate working software, not just talk.
• Encourage interactive feedback — make it a conversation.
• Revisit progress toward the Product Goal.
• Align changes with business outcomes.

Follow On:

Real-World Example:

In a Sprint Review for a booking app, stakeholders suggested that date filters were

unintuitive. The team took this feedback and adjusted the UI in the next Sprint, improving

user satisfaction.

Follow On:

Ways to measure and manage technical debt:

• Code quality tools (SonarQube, CodeClimate)
• Automated test coverage
• Bug rates and frequency of rework
• Velocity trends — slowed delivery may indicate rising debt
• Team feedback in Retrospectives

Make it visible:

• Track known debt in the Product Backlog.
• Reserve capacity every Sprint to pay it down.

Example:

After frequent issues with legacy code, a team estimates and logs 5 technical debt stories,

prioritizing the worst ones during each Sprint.

Challenge How to Overcome

Unclear roles Provide clear Scrum training; reinforce roles (PO, SM, Dev

Team).

Lack of stakeholder

engagement

Involve them in Sprint Reviews, show working software

regularly.

Poor backlog refinement Schedule regular grooming sessions with the PO and

team.

Unrealistic expectations Educate stakeholders on sustainable pace and team

velocity.

Team silos Promote cross-skilling and shared ownership of work.

Skipping retrospectives Prioritize continuous improvement by making retros

engaging and action-focused.

Micromanagement Empower teams to self-organize; educate managers on

agile leadership.

Follow On:

Advanced Scrum & Scaling:

These values create a strong foundation for effective teamwork:

• Commitment – Teams commit to goals and deliverables.
• Courage – Members speak up about challenges and take initiative.
• Focus – Everyone stays aligned on Sprint goals.
• Openness – Honest communication about progress and problems.
• Respect – Valuing everyone's contribution fosters trust.

Example:

In a high-pressure release, a developer admits they’re falling behind. Instead of assigning

blame, the team rallies to support — pair programming to stay on track. That’s Scrum values

in action.

Follow On:

Scrum Ceremonies:

Definition:

A Burndown Chart is a visual tool that shows the remaining work in a Sprint or project

over time.

Purpose:

• Helps teams monitor progress toward completing the Sprint backlog.
• Enables early identification of scope creep or falling behind.

Follow On:

How to use:

• X-axis: Days in Sprint
• Y-axis: Remaining effort (usually in story points or hours)
• Ideal line vs. actual line

Example:

Midway through a Sprint, a team sees the burndown flatlining (no work is getting “done”).

This prompts a conversation — they discover a blocker in API access and address it before

the Sprint is derailed.

Scrum Implementation & Best

Practices:

Best practices:

• Rotate formats to keep things fresh.
• Foster psychological safety — no blaming.
• Use data and facts (velocity, defect rates) to ground discussions.
• Focus on 1-2 action items, not a wish list.
• Follow up — review actions in the next Retrospective.

Popular formats:

• Start / Stop / Continue
• Mad / Sad / Glad
• 4Ls (Liked, Learned, Lacked, Longed for)

Real-World Example:

A team felt retrospectives were repetitive. The Scrum Master tried a “Team Radar” activity to

visualize team health across areas like collaboration and quality. This revealed deeper

issues and sparked more meaningful discussions.

Scrum Artifacts:

Alignment strategies:

• Define and communicate a clear Product Vision.
• Use Sprint Goals that tie directly to business outcomes.
• Conduct Sprint Reviews with real stakeholders to validate direction.
• Use OKRs (Objectives & Key Results) at a program or portfolio level.
• Empower POs to make value-driven decisions, not just task prioritization.

Example:

If the business goal is to increase user retention, Sprint Goals focus on improving

Follow On:

onboarding UX and reducing churn. Sprint Reviews showcase progress toward these

objectives.

Follow On: