The Scrum Big Picture

Read the map as one system, not a pile of ceremonies. Accountabilities decide who owns what. Artifacts make work and progress visible. Events are the inspect-and-adapt loop that keeps the three commitments lined up: Product Goal, Sprint Goal, and a Done Increment.

The Scrum Big Picture is an adaptation by The Agile Forum of the Scrum Guide (2020) by Ken Schwaber and Jeff Sutherland (scrumguides.org) and the Scrum Guide Expansion Pack by Ralph Jocham, John Coleman and Jeff Sutherland (scrumexpansion.org). It is shared under CC BY-SA 4.0 and is not endorsed by the original authors. Icons: Phosphor Icons (MIT). Created by Coach & Trainer: Dhirender Verma.

How the pieces connect

1. Product Goal
2. Product Backlog
3. Sprint Planning
4. Sprint Goal
5. Daily Scrum
6. Increment
7. Sprint Review
8. Sprint Retro

Scrum Academy: learn Scrum step by step

111 guided lessons with knowledge checks (including one lesson for every element of the Big Picture, explained in the glossary below), followed by a 52-decision Sprint simulation.

Foundations

What is Scrum?: Definition and purpose

Scrum is a lightweight framework for generating value through adaptive solutions to complex problems. It gives teams a way to learn quickly, deliver usable results, and change direction when evidence demands it.

• Scrum is a framework, not a detailed instruction manual.
• It is iterative and incremental: learn, build, inspect and adapt.
• Scrum works best when uncertainty is meaningful and feedback matters.

Example: An online store is losing customers during checkout. Rather than spending six months building a huge redesign, a Scrum Team learns from real customers and delivers improvements in small usable steps.

When and why use Scrum?: Complex work and outcomes

Scrum is useful when you face changing needs, incomplete knowledge, and a need to learn from real outcomes. It is not a promise that every project needs Sprints.

• Begin with a meaningful product or service and the value it should deliver.
• Look for uncertainty, feedback opportunities, and a capable cross-functional team.
• Avoid adopting Scrum solely because an organization wants “more ceremonies.”

Example: A familiar, repeatable administrative process may not need Scrum. Testing new checkout experiences with uncertain customer behavior may benefit from it.

Scrum theory, values and pillars: Why the framework works

Scrum is founded on empiricism and lean thinking. Teams make their work visible, inspect what is actually happening, and adapt their plans based on evidence.

• Pillars: Transparency, Inspection, Adaptation.
• Values: Commitment, Focus, Openness, Respect, Courage.
• Lean thinking reduces waste and focuses attention on essentials.

Example: The team notices customers abandon a new payment screen. The analytics and feedback are transparent; the team inspects the results and adapts what it builds next.

One Scrum Team, three accountabilities: Who does what?

A Scrum Team consists of one Product Owner, one Scrum Master and Developers. They form one cohesive, self-managing, cross-functional team with shared responsibility for useful results.

• Product Owner: maximizing product value and effective Product Backlog management.
• Developers: Sprint Backlog, adapting the plan, quality, usable Increment.
• Scrum Master: establishing Scrum and improving Scrum Team effectiveness.

Example: For the checkout product: the Product Owner focuses on product value and backlog ordering; Developers build and verify the Increment; the Scrum Master helps everyone use Scrum effectively.

Product direction

Stakeholders, vision and product discovery: Who needs value? · Expanded / practice

Scrum creates value through the product, but stakeholders do not always agree on which problem matters most. Start with people and evidence: customers, users, leaders, support teams, partners and regulators. Product vision and strategy can help teams make coherent choices; they are not additional 2020 Scrum artifacts.

• Distinguish users, buyers, decision-makers and operational stakeholders.
• Write a simple problem statement and an outcome hypothesis before proposing features.
• Use prototypes, observation, analytics or experiments throughout product work.
• Keep Product Goal (core) distinct from optional vision, roadmaps and OKRs.

Example: ShopEase support tickets show payment failures. The team interviews shoppers and discovers that losing the cart is more frustrating than the failed payment itself. They reframe their product direction toward recovery.

Product Goal and Product Backlog: Direction before tasks

The Product Goal describes a future state of the product. The Product Backlog is an emergent, ordered list of what is needed to improve the product and pursue that goal.

• Product Goal gives a coherent longer-term destination.
• Product Backlog is continually refined, clarified and reordered.
• User stories, epics, bugs and “Definition of Ready” are optional practices, not required Scrum artifacts.

Example: Product Goal: make checkout easy enough that more mobile shoppers finish paying. Backlog candidates include address autofill, clearer delivery charges, and better error handling.

Backlog refinement and useful work items: Clarify, split, size, and order

Product Backlog refinement is ongoing collaborative work: break items down, add detail and make them understandable. Scrum does not require every item to be a user story or a ticket of a standard size. Useful optional details include description, acceptance examples, expected outcome, size and order.

• Product Owner stays accountable for backlog ordering and clarity, while others contribute.
• Refinement is an ongoing activity, not one of five formal Scrum events.
• Stories, bugs, spikes, epics and technical debt are optional backlog-label conventions.
• Definition of Ready (DoR) is optional; do not turn it into a compulsory approval gate.

Example: Large request: “Improve checkout.” Split it into recovering the payment session, preserving the cart and explaining errors. Define a concrete example of a failed-payment retry without losing items.

Work in Sprints

The Sprint: the container for learning: One month or less · fixed length

The Sprint is Scrum’s container event. Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective all occur within it. Its length is fixed at one month or less, and a new Sprint follows immediately. The whole team works toward the Product Goal while protecting the Sprint Goal.

• Do not extend the Sprint just to finish unfinished tickets.
• No change should endanger the Sprint Goal; the product scope can be clarified and renegotiated with the Product Owner.
• Maintain quality and refine Product Backlog as needed during the Sprint.
• The Sprint Review is not a release approval gate; release a Done Increment when appropriate.

Example: ShopEase uses an illustrative two-week Sprint. Developers refine and adapt daily, complete a usable payment-recovery increment and inspect results with stakeholders before planning improvements.

Sprint Planning: why, what, how: Start a Sprint with purpose

Sprint Planning initiates the Sprint. The Scrum Team collaborates on why this Sprint matters, what work may be Done, and how the Developers plan to deliver it.

• WHY: agree on one cohesive Sprint Goal.
• WHAT: Developers select feasible work with Product Owner collaboration.
• HOW: Developers create an actionable and adaptable plan.

Example: Sprint Goal: help mobile customers correct payment errors without restarting checkout. Developers select a small set of relevant items and agree how to create a Done Increment.

Daily Scrum and work during the Sprint: Inspect and adapt every day

A Sprint is a fixed-length event of one month or less containing all other Scrum events. Developers inspect progress toward the Sprint Goal at the 15-minute Daily Scrum and adapt the Sprint Backlog as needed.

• Sprint Planning, Daily Scrums, Sprint Review and Retrospective all happen within the Sprint.
• Developers can adapt their plan whenever needed, not only in the Daily Scrum.
• Boards, pair programming, CI/CD and testing practices are useful options, not Scrum-mandated tools.

Example: A payment API behaves unexpectedly. Developers change their plan, collaborate to resolve the issue, and keep focus on the Sprint Goal.

Increment and Definition of Done: Usable work, quality built in

An Increment is a verified, usable step toward the Product Goal that adds to previous Increments. Only work meeting the Definition of Done can be part of an Increment.

• There can be multiple Increments in one Sprint.
• Definition of Done creates shared transparency about quality.
• An Increment may be released before Sprint Review; Review is not an approval gate.

Example: The new payment-error recovery works, is tested, meets security and usability criteria, and integrates with the existing checkout experience.

Inspect & improve

Sprint Review: inspect product progress: Learn with stakeholders

In Sprint Review, the Scrum Team and stakeholders inspect the outcome of the Sprint, discuss what changed in their environment, and collaborate on future adaptations.

• Discuss progress toward the Product Goal and relevant outcomes.
• Inspect evidence and consider changes to the Product Backlog.
• The Review happens inside the Sprint, near its end.

Example: Users try the new recovery flow and explain that the error messages still confuse them. The Product Owner uses this information when adapting the Product Backlog.

Sprint Retrospective: improve the way of working: Learn about teamwork and quality

The Scrum Team inspects how the Sprint went regarding interactions, processes, tools and Definition of Done, then plans practical improvements to increase quality and effectiveness.

• Inspect what helped and hindered effectiveness.
• Select improvements that can be acted on.
• Check whether those improvements actually helped.

Example: The team identifies late integration as a source of rework and agrees to integrate code more frequently next Sprint.

Three distinct feedback loops: Connect learning end to end

Three helpful learning loops explain how product work keeps improving: Review evidence adapts product decisions; Retrospective learning improves team effectiveness; real-world results inform direction and strategy.

• Loop 1: Sprint Review → Product Backlog and future decisions.
• Loop 2: Sprint Retrospective → improvements in the next Sprint.
• Loop 3: real results → discovery, strategy, Product Goal thinking and backlog.

Example: Review: customers ask for clearer errors. Retro: engineers improve test setup. Outcomes: checkout completion rises only slightly, so the team revisits hypotheses and future work.

Release, outcomes and value evidence: Output ≠ outcome

An Increment is verified, integrated usable output. A released product change can produce outcomes when people use it. Scrum does not require release at the end of the Sprint or approval at Sprint Review; real-world results are distinct from completing backlog items.

• Output: a Done checkout-recovery capability. Outcome: shoppers complete payments more reliably.
• Observe product metrics and qualitative feedback after release.
• Return evidence to Product Goal, discovery, strategy and Product Backlog.
• The Scrum Guide Expansion Pack adds Product and Definition of Outcome Done as an expanded interpretation, not core 2020 artifacts.

Example: ShopEase releases payment retry. Usage analytics show fewer restart attempts, but completion rate does not improve. The Product Owner investigates why rather than declaring victory on feature delivery.

Apply & extend

Try Scrum: your first Sprint: From reading to real-world practice

Start with a product and meaningful Product Goal, form one Scrum Team, establish quality expectations, order the Product Backlog, and use a Sprint to deliver a usable Increment while inspecting and adapting.

• Identify stakeholders, product, Product Goal and the Scrum Team.
• Agree on a Definition of Done and transparent Product Backlog.
• Run the events, create Done Increments, inspect evidence and repeat.

Example: Checkout improvement: set a Product Goal, order testable work, plan a two-week Sprint, adapt daily, meet DoD, inspect with stakeholders and improve in the Retro.

Practical patterns, measures and anti-patterns: Optional techniques + healthier alternatives

Teams can add useful techniques around Scrum: Sprint boards, acceptance examples, user stories, working agreements, CI, test automation and flow measures. None replaces the three artifacts, five events, accountabilities and commitments. Select techniques based on the problems you are trying to solve.

• Use cycle time, quality signals and goal progress to learn—not as weaponized individual KPIs.
• A Sprint Review is a working session, not merely a demo or approval gate.
• Developers adapt their own plan; the Scrum Master enables effectiveness rather than assigning work.
• Improve one testable practice per Sprint and inspect the effect in the next Retrospective.

Example: ShopEase observes carry-over each Sprint. The team inspects item slicing, interruptions and Definition of Done rather than blaming individuals for low velocity.

How to introduce Scrum in a real organization: From explanation to adoption

A team cannot make Scrum effective simply by adding meetings to an existing process. Clarify the product boundary, Product Goal, customer access, empowered Scrum Team, usable Increment quality bar and feedback opportunities. Start with a short experiment, inspect real obstacles and adapt organizational conditions.

• Define the product and the customers whose needs it serves.
• Establish accountabilities, product direction and an ordered Product Backlog.
• Agree on a usable quality bar, event cadence and access to stakeholders.
• Inspect outcomes, impediments and organizational constraints after each Sprint.

Example: ShopEase forms one product-focused Scrum Team. Leadership grants access to users, maintains a stable product boundary and removes slow testing approvals. The first two Sprints prioritize learning about reliable checkout.

Responsible AI and expanded Scrum thinking: Optional, governed assistance · Expansion Pack

AI can help frame research, analyze feedback, propose backlog slices, support code and test creation, and synthesize Retrospective themes. But AI outputs can be wrong or unsafe. The Scrum Team remains accountable for decisions, quality, privacy, security and actual customer outcomes.

• Keep AI-generated work transparent, traceable and verified.
• Protect customer and employee data and review security-sensitive changes.
• AI can assist discovery, backlog, planning, testing and feedback without becoming a Scrum role or event.
• The Scrum Guide Expansion Pack introduces Product and Definition of Outcome Done as expanded guidance; keep them distinct from 2020 Scrum Guide commitments.

Example: AI drafts tests for the ShopEase payment-retry feature. Developers review the code, verify security/privacy and independently test failure cases before the Increment can meet Definition of Done.

AI in practice

A team AI working agreement: Make AI use explicit

Before AI tools spread quietly through a team, agree how they are used. A short working agreement lists approved tools, what data may be shared, how AI-assisted work is labelled and reviewed, and who to ask when unsure.

• List approved tools and the tasks each is good for.
• State what must never go into a tool: secrets, customer personal data, confidential code.
• Agree how AI-assisted work is marked and who reviews it.
• Revisit the agreement at the Retrospective as tools and risks change.

Example: ShopEase agrees: the coding assistant may see the checkout code but never production data; AI-written tests are labelled in the pull request; one human reviewer is required.

Protecting data when you use AI: Respect for users includes their data

AI tools can store, log or learn from what you send them. Treat every prompt as data leaving your team unless your organisation has confirmed otherwise.

• Use only tools approved by your organisation for the data involved.
• Remove or mask personal data before analysis when possible.
• Get consent before recording or transcribing interviews.
• Make data handling part of the Definition of Done for AI-assisted work.

Example: Before clustering support chats, the ShopEase team masks names, emails and card digits, then runs the analysis in the company-approved tool.

Verifying AI output: Confident wording is not evidence

AI can produce fluent answers that are wrong: invented facts, outdated code examples, tests that always pass. The tone of an answer tells you nothing about whether it is correct.

• Check facts against a trusted source or the raw data.
• Run and read AI-written tests, and make sure they can fail.
• Ask the tool for its reasoning or sources, then verify them.
• Take extra care where errors are costly: payments, security, health and legal matters.

Example: An AI-generated test for payment retry passes even when retry is switched off. A Developer notices the assertion checks nothing and rewrites it.

AI and the Definition of Done: One quality bar for every Increment

The Definition of Done applies to everything in the Increment, however it was produced. Some teams add explicit checks for AI-assisted work.

• AI-assisted code is reviewed by someone who understands it.
• Security and licence checks run on generated code.
• Data used with AI followed the team's privacy rules.
• Product features that use AI are tested for wrong or harmful outputs.

Example: ShopEase adds two lines to its Definition of Done: AI-generated code is reviewed by a human, and no customer data is shared with unapproved tools.

Bias and fairness in AI-assisted decisions: Inspect results by group

AI learns from past data, and past data carries past bias. Ordering, targeting or approving with AI can quietly disadvantage some users.

• Ask who could be disadvantaged before using AI on decisions about people.
• Compare results across user groups, not only the average.
• Keep a human decision for anything that affects access, money or safety.
• Report and fix bias like any other defect.

Example: An AI fraud score blocks more first-time mobile buyers from one region. The team inspects the data, adds human review for blocked orders and tracks the block rate by region.

AI around the Scrum events: AI prepares the event; people hold it

AI can prepare and follow up every event: summaries before Sprint Planning, stuck-work alerts before the Daily Scrum, feedback themes for the Sprint Review, anonymous input for the Retrospective. The conversations themselves stay human.

• Sprint Planning: forecasts as ranges and dependency checks as input.
• Daily Scrum: a short list of blocked items, not a replacement for talking.
• Sprint Review: usage data and feedback themes to discuss with stakeholders.
• Sprint Retrospective: patterns and anonymous input, never individual rankings.

Example: Before each Daily Scrum, a bot posts items untouched for two days. The Developers spend their 15 minutes deciding what to do about them.

When the product itself uses AI: Wrong answers, drift and trust

AI features behave probabilistically and can change with new data. Discovery, Acceptance Criteria and outcome measures need to cover wrong answers, drift and user trust, not only the happy path.

• Define what a harmful or unacceptable output looks like.
• Test early with realistic data, including edge cases.
• Monitor quality after release, because models drift.
• Give users a way to correct or report bad results.

Example: ShopEase adds an AI-recommended payment method. Outcome Criteria track checkout completion and how often users override the suggestion.

Is AI actually helping?: Treat each tool as an experiment

Teams often feel faster with AI. Measure it: cycle time, escaped defects, rework and outcomes before and after, so the team learns whether to expand, adjust or stop using a tool.

• Choose two or three measures before the trial starts.
• Compare a period before and after, watching quality as well as speed.
• Ask the team how the tool affects learning and skills.
• Decide at the Retrospective: keep, change or drop.

Example: After six weeks with a coding assistant, ShopEase's cycle time falls but escaped defects rise. The team adds a review checklist and measures again.

Expansion Pack in practice

Output Done and Outcome Done: Two commitments, two questions

The Expansion Pack distinguishes the Definition of Output Done (the quality of the Increment, which the Scrum Guide calls the Definition of Done) from the Definition of Outcome Done (evidence that benefits were realised).

• Output Done: a usable, verified Increment, checked before release.
• Outcome Done: observable evidence of benefit, checked after use.
• Define the outcome evidence before release to avoid bias.
• The 2020 Scrum Guide's three artifacts and commitments are unchanged.

Example: Payment retry is Output Done when it is tested, integrated and secure. It is Outcome Done when failed-payment recovery reaches the agreed level for four weeks.

Mapping your stakeholders: Different stakeholders, different conversations

The Expansion Pack names several kinds of stakeholders: customers and users, decision-makers, sponsors, subject-matter experts, regulators and supporters. Each needs a different kind of interaction.

• List each group and what they need from the product.
• Note how, and how often, the team interacts with each.
• Bring real users, not proxies, to inspect the Increment.
• Revisit the map when the Product Goal changes.

Example: ShopEase maps shoppers (users), the payments director (decision-maker), finance (sponsor), the fraud specialist (subject-matter expert), card-scheme rules (governance) and the HR partner who keeps the team stable (supporter).

Problems, opportunities and risks: Start with the problem, test the solution

Instead of starting from features, the Expansion Pack frames work as problems to solve or opportunities to pursue, with risks managed proactively. Value is an assumption until evidence confirms it.

• Write down the problem and who has it before the solution.
• List the key assumptions and pick the riskiest.
• Design the smallest experiment that tests it.
• Keep risks in the Product Backlog where they can be ordered.

Example: 'Add a digital wallet' becomes: shoppers without cards abandon checkout; we assume a wallet option would recover them; we test with a one-week placeholder button and measure clicks.

From Increment to impact: Evidence after release decides what comes next

Delivery is the start of value, not the end. A released Increment changes the product; result feedback shows whether outcomes and impact follow; that evidence flows back to the Product Goal and Product Backlog.

• Release Done Increments when appropriate, with measures in place.
• Gather quantitative and qualitative result feedback.
• Inspect outcomes with stakeholders whenever evidence arrives, not only at the Sprint Review.
• Adapt the Product Goal or Product Backlog based on what you learned.

Example: Three weeks after release, ShopEase sees retry use rise but checkout completion stay flat. Interviews reveal a confusing confirmation screen, and the next Sprint Goal targets it.

Leadership and supporters: Change the conditions, not just the team

Scrum exposes organisational impediments: slow approvals, unstable teams, conflicting goals. The Expansion Pack calls on leadership and supporters to change these conditions so teams can self-manage.

• Leaders create clarity of goals and trust, not task lists.
• Supporters remove organisational blockers such as funding, staffing and approvals.
• Measure the whole system, not individual teams in isolation.
• Model the values: openness about problems and respect for team decisions.

Example: ShopEase's finance partner moves the team from annual project funding to quarterly funding tied to the Product Goal, so the team can change direction with evidence.

Sprint simulation: 52 decisions

1. Start with the problem, not a ceremony ShopEase is an online store. Customer interviews suggest that mobile shoppers abandon checkout after a payment failure, but the team does not yet know which fix will help most.
2. One team. Three accountabilities. A Product Owner, Scrum Master and Developers collaborate on ShopEase. Support staff and customers provide valuable feedback, but they are not all Scrum Team members.
3. Agree on a meaningful Product Goal The team agrees it wants mobile shoppers to complete checkout more reliably. They need a longer-term destination that supports continuous backlog decisions.
4. Build an ordered Product Backlog Ideas emerge: clearer error messages, payment retry, address autofill, faster load time, and customer-support links. The team has more ideas than it can implement immediately.
5. Split the checkout change into learnable slices A single request says “Fix the entire mobile checkout.” The Developers do not yet understand edge cases, and the Sprint Goal needs a manageable slice.
6. Plan a Sprint: why, what and how The team chooses an illustrative two-week Sprint, within Scrum’s one-month-or-less timebox. Stakeholders need a way to recover from payment errors without restarting checkout.
7. An unexpected challenge appears The payment provider’s test environment is unstable. The Developers discover that their original plan is no longer realistic and discuss what to change.
8. A leader asks for unrelated work A director requests a loyalty banner urgently. The Sprint Goal is payment recovery, and the team is already addressing a third-party payment outage.
9. Is the Increment actually Done? The new payment retry screen works in a demo, but its error-handling tests fail and it has not been integrated with the live checkout experience.
10. A Done Increment is ready for use The team now has a usable, integrated, tested checkout recovery improvement that meets the Definition of Done. Product stakeholders would benefit from releasing it early.
11. Learn with stakeholders at Sprint Review Customers test the improved payment flow. They like the retry option but do not understand one error message. The Product Owner sees that the backlog should change.
12. Use the Retrospective to improve quality The team notices that integration was consistently late. This made testing stressful and delayed progress even though the Sprint Goal was achieved.
13. Three feedback loops — three different adaptations During Review shoppers say the error message is confusing. In Retro, Developers identify unstable test data. Production data shows some users still abandon carts.
14. Did the released change create value? Analytics show checkout completion improved, but less than expected. The team wants to know whether the problem was only partly solved or the hypothesis was wrong.
15. Prepare for the next Sprint—and beyond ShopEase keeps working toward its Product Goal with new evidence. The team considers using a task board, automated testing, interviews, flow metrics and AI-assisted analysis.
16. Use AI assistance without weakening quality An AI tool generates payment retry logic and dozens of tests. A new teammate argues that AI output is automatically ready to release.
17. The director wants a fixed six-month plan The payments director asks for a six-month plan with a date for every checkout feature, so the board can approve funding.
18. Users say one thing and do another A survey says shoppers want a digital wallet option. Analytics show very few use the wallet option ShopEase already offers.
19. A compliance rule appears The card network announces that payment retries must use strong customer authentication from next quarter.
20. The expert bottleneck Every payment item waits for the fraud specialist's approval. Items sit for days and the Sprint Goal is slipping.
21. Discovery and delivery in the same Sprint The team is unsure whether address autocomplete helps mobile shoppers. A manager proposes a separate research team that reports back in two months.
22. The backlog has 600 items The Product Backlog has grown to 600 items. Most are years old and nobody knows which ones still matter.
23. The Sprint Goal is at risk Integrating the new address service is much slower than expected. On day 4 the Developers see they cannot finish everything they selected.
24. Should the Sprint be cancelled? Leadership drops the partnership that the current Sprint Goal was built around. The goal no longer makes sense.
25. The velocity comparison A manager compares ShopEase's velocity with another team's and asks why ShopEase is 'slower'.
26. The Retrospective goes quiet After a manager joined the last Retrospective and criticised individuals, nobody speaks openly any more.
27. Technical debt slows everything Each change to checkout now takes twice as long because of old, fragile code.
28. Is the Product Goal achieved? Checkout abandonment has fallen to the target level for six weeks. The Product Owner asks what comes next.
29. Everyone uses a different AI tool Half the team uses various AI assistants privately. Nobody knows which tools saw which code or data.
30. Customer data in a chatbot A Developer pasted 300 support chats, including customer emails, into a free public chatbot to get a summary.
31. AI-written tests always pass An AI assistant generated 40 tests for the new retry logic. All pass, even after a Developer deliberately breaks the feature.
32. An AI tool reorders the backlog every night A new plugin reorders the Product Backlog nightly by ticket volume. The Product Owner wakes up to a different order every day.
33. The AI forecast becomes a promise An AI tool forecasts '42 points' for the Sprint. A manager wants the team to commit to exactly that number.
34. AI personas instead of interviews Someone proposes skipping user interviews by generating ten AI personas, because it is faster.
35. An AI fraud score blocks one group Data shows the AI fraud check blocks far more first-time buyers from one region than from others.
36. Replace the Daily Scrum with a bot? A bot now posts a daily summary of the board. A team member suggests dropping the Daily Scrum.
37. The AI report ranks people An analytics tool produces a Retrospective report ranking Developers by commits and tickets closed.
38. Is the coding assistant worth it? After two months with an AI coding assistant, the team must decide whether to keep paying for it.
39. Adding an AI feature to checkout The Product Owner wants an AI feature that suggests the best payment method for each shopper.
40. Who approves AI-generated security code? An AI agent produced a change to how payment tokens are stored.
41. Defining Outcome Done before release The team is about to release one-click reorder for repeat customers.
42. Revenue up, satisfaction down One-click reorder increased revenue, but satisfaction scores from repeat customers fell.
43. A second team joins the product ShopEase grows and a second Scrum Team will work on the same product.
44. Three weeks for every approval Every release waits three weeks for a central change board, even small fixes.
45. Annual project funding Finance wants to lock next year's scope, time and budget for ShopEase in a single annual project.
46. People move teams every quarter Management moves people between teams every quarter to balance workloads.
47. A faster team, a slower product The ShopEase team finishes work faster than ever, yet releases now queue for weeks with the operations team.
48. The Scrum Master as project manager A new leader asks the Scrum Master to assign tasks to Developers and send a daily status report.
49. The project is 'done' Sponsors propose disbanding the ShopEase team because the checkout project is complete.
50. Agile by December The company announces a transformation: every team must be 'agile by December'.
51. Leadership without a title A Developer notices users struggling with returns and organises three user sessions for the team.
52. What next for ShopEase? A year on, checkout and reorder outcomes are strong. Stakeholders ask what comes next.

One Scrum Team, three accountabilities

Product Owner, Developers, and Scrum Master are accountabilities on one Scrum Team — not three departments. The team is self-managing within Scrum: they decide who does what, when, and how, toward the Sprint Goal.

• Product Owner — Product value, Product Goal, Product Backlog ordering. Makes trade-offs visible. Says no (or not now) so the team can say yes to a coherent Sprint Goal.
• Developers — Sprint Backlog, how work gets Done, quality of the Increment. Forecast what they can complete, swarm toward one Sprint Goal, and update the plan as they learn.
• Scrum Master — Scrum effectiveness — coaching the team and the wider organization. Teaches the why behind events, removes impediments, and protects focus without becoming the boss of the work.

Artifacts and their commitments

• Product Backlog (commitment: Product Goal). The ordered list of what might improve the product. It exists to achieve the Product Goal — not to park every request forever.
• Sprint Backlog (commitment: Sprint Goal). The Developers' plan for this Sprint: the Sprint Goal, the selected Product Backlog items, and an actionable plan for delivering them. The plan can change; the Goal should stay coherent.
• Increment (commitment: Definition of Done). The usable, quality-bar slice of product created during the Sprint, added to previous Increments. If it is not Done, it is not an Increment — it is unfinished work.

How Product Goal, Sprint Goal, and Increment relate

These three nest. If they do not line up, the team can be busy every day and still have no story stakeholders can follow.

1. Product Goal — The longer-term destination for the product. The Product Backlog is the path; this is why the path exists.
2. Sprint Goal — Why this Sprint exists — one coherent objective the team could miss even if some tickets close. It is a step toward the Product Goal, not a dump of unrelated stories.
3. Increment — Usable evidence that the step happened. Stakeholders inspect it at the Sprint Review and help adapt what comes next.

When each event creates clarity vs. when it drifts

• The Sprint (A fixed container (typically 1–4 weeks) that holds all other events). Creates clarity: A time-box creates focus: start together, finish together, inspect together. When it drifts: A mini-waterfall inside the Sprint, stretching the Sprint when work is not Done, or treating the Sprint as a reporting period instead of a learning loop.
• Sprint Planning (Start of the Sprint — why, what, and how). Creates clarity: The team leaves with a Sprint Goal, a selected slice of the Product Backlog, and a plan the Developers own. When it drifts: Loading tickets with no Sprint Goal; the Product Owner dictating how; planning until every hour is allocated and nobody can absorb discovery.
• Daily Scrum (Every working day of the Sprint — 15 minutes, Developers). Creates clarity: Inspect progress toward the Sprint Goal and adjust the next 24 hours. People talk to each other, not at a board. When it drifts: A status report to the Scrum Master, a 45-minute stand-up, or a ticket-by-ticket recitation with no mention of the Sprint Goal.
• Sprint Review (End of the Sprint — inspect the Increment with stakeholders). Creates clarity: Working product in the room (or on screen). Stakeholders help adapt the Product Backlog. Progress toward the Product Goal is honest. When it drifts: A slide-only demo, no real stakeholders, or treating Review as a sign-off gate instead of an inspect-and-adapt conversation.
• Sprint Retrospective (After Review, before the next Planning — people, process, tools). Creates clarity: One concrete improvement with an owner, tried in the next Sprint. When it drifts: Skipped under schedule pressure, a blame session, or a parking lot of ideas that never become an experiment.

Common anti-patterns and healthier alternatives

• The Scrum Master “runs the meetings.” Healthier: The Scrum Master coaches the team to run their own events. Developers own the Daily Scrum.
• The Product Owner is a stakeholder request queue. Healthier: The Product Owner orders work by Product Goal and outcomes, and makes insertion cost visible.
• No Sprint Goal — just a list of stories. Healthier: One coherent Sprint Goal that could fail even if some tickets complete.
• Velocity as a performance KPI. Healthier: Use Sprint Goal success, cycle time, quality, and customer/business outcomes.
• Carry-over is “normal” every Sprint. Healthier: Inspect slicing, forecasting, interruptions, and whether Done is actually Done.
• Stakeholders stuff scope mid-Sprint. Healthier: New asks go to the Product Backlog. Trade-offs go through the Product Owner. The Sprint Goal stays protected.
• Definition of Done is optional (“we’ll test next Sprint”). Healthier: If it is not Done, it is not an Increment. Quality is part of “done,” not a later phase.
• The Retro is a complaint hour with no follow-through. Healthier: Pick one improvement, name an owner, and check it in the next Retro.

Glossary

Stakeholders & environment

Stakeholders & Environment (Scrum Guide 2020)

Everyone interested in, affected by, or able to influence the product. The Scrum Guide 2020 refers to stakeholders throughout without defining them; the Expansion Pack defines Stakeholder as a role and stresses regular, intentional interaction with the Scrum Team.

In detail

A stakeholder is anyone who has an interest in the product, is affected by it, or can influence it. That includes the people who use it, the people who pay for it, the people who approve it and the people who must live with its consequences, such as support teams or regulators.

Scrum does not ask the Scrum Team to manage stakeholders from a distance. It asks for regular, intentional collaboration. The Sprint Review is the formal moment for this, but good teams talk to stakeholders throughout the Sprint, during refinement and while validating value. The aim is shared understanding, not status reporting.

Example

A bank's mobile-app team lists its stakeholders: retail customers, branch staff who answer customer questions, the compliance team, the marketing lead and the head of digital who funds the work. Each Sprint Review the Product Owner invites the two or three groups most affected by the current Product Goal, so the conversation stays focused and useful.

Using AI

AI can summarise stakeholder interviews, support tickets and survey comments into themes, so the team sees who is affected and how. It can also draft a stakeholder map from project documents. The Product Owner still decides who to involve and how often; AI only helps make the picture visible.

Common mistakes

• Treating the Sprint Review as a slide show for stakeholders instead of a working session.
• Talking only to the loudest or most senior stakeholder and missing the people who actually use the product.

Customers & Users (Scrum Guide Expansion Pack)

Customers receive value by buying or selecting the product; users interact with it directly to reach a goal. Their observed behaviour and feedback are the strongest evidence of value.

In detail

Customers and users are not always the same people. A customer chooses or pays for the product; a user interacts with it to get something done. In a hospital system, the hospital buys the software, while nurses and doctors use it every day. Both matter, but in different ways.

What users actually do is the strongest evidence of value. Opinions and requests are useful, but observed behaviour, such as which features are used, where people get stuck and whether they come back, tells the Scrum Team whether an Increment really helped.

Example

An online learning platform releases a new course search. Customers (the companies that buy licences) asked for it, but usage data shows learners rarely use the filters. The team watches five learners use the search, learns that they want to search by job role, and adds that to the Product Backlog.

Using AI

AI can analyse large volumes of user feedback, app-store reviews and support chats and group them by need or pain point. It can also spot unusual patterns in usage data. Always check AI summaries against a sample of real feedback, and never paste personal customer data into public AI tools.

Common mistakes

• Building what the customer asked for without checking whether users can and will use it.
• Relying on what people say they want instead of what they actually do.

Decision-makers (Scrum Guide Expansion Pack)

Stakeholders with the authority to approve, select or authorise adoption or purchase of the product. They may never use it themselves, yet their choices decide how value reaches others.

In detail

Decision-makers have the authority to approve, select or authorise a product, even if they never use it. A procurement manager who chooses a supplier, a director who approves a rollout or an IT head who signs off on a new tool are all decision-makers.

Their decisions control how value reaches users. If decision-makers do not understand the product's benefits, a good product can still fail. The Product Owner therefore needs to understand what evidence decision-makers need and make that evidence visible early.

Example

A team builds an expense-claims tool for a large company. Employees love the prototype, but the finance director decides whether it replaces the old system. The Product Owner invites the director to a Sprint Review focused on audit trails and approval rules, which is what the director cares about.

Using AI

AI can help prepare a clear, evidence-based summary for a decision-maker, for example by turning usage metrics and pilot feedback into a one-page brief. The Product Owner must check every figure; a polished but wrong summary damages trust quickly.

Common mistakes

• Assuming that happy users will automatically persuade the people who decide.
• Inviting decision-makers only at the end, when changing direction is expensive.

Sponsors & Business (Scrum Guide Expansion Pack)

Financial sponsors and business leaders fund the product and assess viability and return. Scrum works best when funding and expectations stay flexible as new information emerges.

In detail

Sponsors and business leaders fund the product and judge whether it is worth the investment. They care about viability: return on investment, cost, market position and risk.

Scrum works best when funding is flexible. Instead of fixing a large budget and scope at the start, sponsors can fund a Product Goal or a period of time, review evidence regularly and decide whether to continue, change direction or stop. This keeps money flowing to the work that proves its value.

Example

A retailer's sponsor funds an online-ordering team quarter by quarter. Each quarter the Product Owner shows outcomes such as orders per week and customer satisfaction. When click-and-collect proves more popular than home delivery, the sponsor agrees to shift the next quarter's focus.

Using AI

AI can model scenarios, for example the likely cost and benefit of two different Product Goals, and turn financial data into clear charts. Treat these models as input to a conversation, not as decisions; the assumptions behind them must be visible and challenged.

Common mistakes

• Fixing scope, time and budget all at once and then expecting agility.
• Measuring the team by output delivered instead of outcomes achieved.

Market & Competitors (Scrum Guide 2020)

The marketplace changes continuously. Changes in the market and the environment are inspected at the Sprint Review and can re-order the Product Backlog.

In detail

The market keeps changing: competitors launch features, customer expectations rise, new technology appears and economic conditions shift. A plan made six months ago may no longer fit today's reality.

Scrum handles this through regular inspection. At the Sprint Review, the Scrum Team and stakeholders look at what has changed in the marketplace and decide whether the Product Backlog should be re-ordered. Short Sprints mean the team can react within weeks instead of months.

Example

A travel-booking team plans to build loyalty points next. At the Sprint Review, the marketing lead shares that a major competitor has just launched instant refunds, and customers are asking for the same. The Product Owner moves faster refunds above loyalty points in the Product Backlog.

Using AI

AI tools can monitor competitor releases, news and social media and produce a short weekly digest of market signals. The team should treat this as a prompt for discussion; whether a market change matters for the product is a human judgement.

Common mistakes

• Reviewing only the work done and never discussing the market at the Sprint Review.
• Chasing every competitor feature instead of staying focused on the Product Goal.

Regulators & Governance (Scrum Guide Expansion Pack)

Laws, policies, standards and oversight that constrain and guide the product. Governance should be coherent with Scrum: transparent, regularly inspected and free of surprises.

In detail

Governance covers the laws, regulations, policies, standards and oversight that guide and limit a product. Data protection, accessibility rules, financial regulations and internal security standards are common examples.

Good governance and Scrum can work together. Instead of a big compliance check at the end, requirements are made transparent early, built into the Definition of Done or Acceptance Criteria, and inspected every Sprint. This avoids late surprises and keeps both speed and safety.

Example

A healthcare team adds to its Definition of Done: personal health data is encrypted, access is logged and the privacy notice is updated when data use changes. The compliance officer attends refinement for items that touch patient data, so issues are found before the work starts.

Using AI

AI can help check text and code against known rules, for example flagging missing accessibility labels or highlighting clauses in a policy that affect a feature. The accountable people still sign off; AI checks support compliance but do not replace it.

Common mistakes

• Leaving compliance checks to the end, when changes are slow and costly.
• Treating governance as someone else's problem instead of part of the Definition of Done.

Suppliers & Partners (Complementary practice (not part of Scrum))

Vendors and partners whose work, lead times or contracts affect what the Scrum Team can deliver. Dependencies on them should be made transparent during refinement.

In detail

Suppliers and partners are external organisations whose work affects what the Scrum Team can deliver: a payment provider, a data supplier, an outsourced design agency or a hardware vendor. Their lead times, contracts and quality become part of the team's reality.

The key is transparency. Dependencies on partners should be visible during Product Backlog refinement, so the Product Owner can order work sensibly and the team can plan around waiting times. Where possible, partners are invited to collaborate in Sprint Reviews instead of working to a fixed contract in isolation.

Example

A team needs a new API from its payment provider before it can offer instalment payments. During refinement they mark the item as dependent on the partner, agree a test date with the provider and meanwhile build the screens against a mock service, so no Sprint is wasted.

Using AI

AI can help track dependencies across many backlog items and partner contracts and flag when a delay in one partner's delivery affects several items. People must still negotiate with partners and agree what happens when dates move.

Common mistakes

• Discovering a partner dependency in the middle of a Sprint.
• Writing fixed-scope contracts that stop the team from adapting to what it learns.

Subject-Matter Experts (Scrum Guide Expansion Pack)

Specialists who contribute deep domain, technical, design or compliance knowledge. They support the Scrum Team and transfer learning without getting in the way of its self-management.

In detail

Subject-matter experts bring deep knowledge the Scrum Team needs: a tax specialist, a security architect, a UX researcher or a clinician. They help the team understand the problem and make good decisions.

SMEs support the team without taking over. The best SMEs teach as they help, so knowledge spreads into the team over time. They join refinement or pair with Developers when needed, instead of becoming a bottleneck that every decision must pass through.

Example

An insurance team is building a claims form. A senior claims handler joins two refinement sessions to explain how fraud is spotted, then pairs with a Developer for an hour to review the first version. After a few Sprints the team can handle most questions itself.

Using AI

AI can act as a first stop for routine questions, for example explaining a regulation or a technical standard in plain language, so SME time is saved for difficult cases. Always confirm important answers with the expert, because AI can sound confident and still be wrong.

Common mistakes

• Making the SME approve every item, which creates a queue and slows the team.
• Using an SME's time without capturing what was learned for the rest of the team.

Supporters (Scrum Guide Expansion Pack)

A specific kind of stakeholder introduced by the Expansion Pack: change agents such as managers, sponsors, HR or finance who actively help the Scrum Team thrive and make the organisation coherent with Scrum.

In detail

Supporters are a kind of stakeholder introduced in the Expansion Pack: people such as managers, HR, finance or senior leaders who actively help the Scrum Team succeed. They change the organisation so that it fits the way Scrum works.

Supporters remove obstacles that the team cannot fix on its own, such as rigid budgeting, individual performance targets that discourage teamwork, or slow approval processes. They do not direct the team's work; they shape the environment around it.

Example

A Scrum Team keeps losing Developers to other projects for days at a time. Their department head, acting as a supporter, agrees with other managers that team members stay dedicated to one team, and changes the staffing process so the Scrum Team stays stable.

Using AI

AI can help supporters see organisational patterns, for example how long approvals take or how often people are moved between teams, using data from existing systems. Changing those patterns still needs leadership, conversation and trust.

Common mistakes

• Managers who call themselves supportive but still assign tasks to individuals in the team.
• Expecting the Scrum Master alone to fix organisation-wide problems.

Problems, Opportunities & Risk (Scrum Guide Expansion Pack)

The Expansion Pack frames work as problems or opportunities and gives proactive risk management more prominence. Value is treated as an assumption until evidence such as observation or measured outcomes confirms it.

In detail

The Expansion Pack encourages teams to frame work as problems to solve or opportunities to take, not just features to build. A problem statement such as customers abandon checkout when shipping costs appear is more useful than add a shipping calculator, because it leaves room to find the best solution.

It also stresses proactive risk management. Every idea about value is an assumption until evidence confirms it. Teams list their riskiest assumptions, test them early and cheaply, and adjust the Product Backlog based on what they learn.

Example

A food-delivery team believes customers want a subscription for free delivery. Instead of building the full subscription system, they offer it as a test to 5% of customers in one city. Only a few sign up, so they explore a different idea before investing months of work.

Using AI

AI can help reframe feature requests as problem statements, list the assumptions behind an idea and suggest small experiments to test them. The team chooses which risks matter most and which experiments are ethical and worthwhile.

Common mistakes

• Writing solutions into the Product Backlog before the problem is understood.
• Treating a successful launch as proof of value without measuring the outcome.

Product direction

Product Owner (Scrum Guide 2020)

Accountable for maximising the value of the product resulting from the work of the Scrum Team. Develops and communicates the Product Goal, creates and orders Product Backlog items and keeps the Product Backlog transparent and understood. One person, not a committee.

In detail

The Product Owner is accountable for maximising the value of the product that results from the Scrum Team's work. They develop and communicate the Product Goal, create and clearly describe Product Backlog items, order them, and make sure the Product Backlog is transparent and understood.

The Product Owner is one person, not a committee. They may take input from many stakeholders and may delegate work, but they remain accountable. For the role to work, the organisation must respect their decisions; these decisions are visible in the content and order of the Product Backlog and in the Increment reviewed at the Sprint Review.

Example

Three department heads each want their feature first. The Product Owner meets them together, explains the Product Goal of reducing customer onboarding time, and orders the backlog by impact on that goal. One request moves down, and the department head understands why.

Using AI

AI can help a Product Owner draft clear backlog items, summarise feedback, compare options against the Product Goal and spot duplicated or unclear items. Ordering decisions and trade-offs between stakeholders stay with the Product Owner.

Common mistakes

• A Product Owner who only writes tickets and has no authority to make product decisions.
• Several people acting as Product Owner, so the team receives conflicting priorities.

Product Vision (Scrum Guide Expansion Pack)

A meaningful long-term picture of desired outcomes. It is not a Scrum-defined artifact: the Expansion Pack describes it as a useful input when considering a Product Goal, and as something that may itself need to adapt.

In detail

A product vision is a meaningful, long-term picture of the change the product should create for its customers and users. It answers the question why this product exists and inspires everyone involved.

The vision is not a Scrum artifact. The Expansion Pack describes it as a useful input when the Scrum Team considers its Product Goal. A vision usually lasts longer than any single goal, but it can also change when the team learns something important about its users or market.

Example

A language-learning app's vision is: anyone can hold a real conversation in a new language within six months. Their current Product Goal is narrower: beginners complete their first full week of lessons. The goal is a step toward the vision.

Using AI

AI can help a team test whether its vision is clear by rewriting it in plain language, generating questions customers might ask, or comparing it with competitors' positioning. A vision must still come from real understanding of customers and from the people who will pursue it.

Common mistakes

• A vision so vague that it cannot guide any decision.
• Confusing the vision with a list of features.

Product Strategy (Complementary practice (not part of Scrum))

The set of choices about how to move toward the vision: target customers, needs to serve, and how to win. Not defined by Scrum; the Product Goal often supports the product strategy.

In detail

A product strategy is the set of choices about how to move toward the vision: which customers to serve first, which needs to focus on, how the product will be different from alternatives and how it will be sustainable.

Scrum does not define product strategy, but it fits naturally around it. The Product Goal often expresses the next step of the strategy, and evidence from each Sprint Review and from value validation helps the Product Owner adjust the strategy when assumptions turn out wrong.

Example

A fitness app decides its strategy is to win busy professionals first, not athletes. That choice shapes the next Product Goal: short workouts that fit into a lunch break. Features for marathon training stay low in the Product Backlog.

Using AI

AI can help analyse market segments, summarise competitor strategies and stress-test strategic options with what-if questions. Strategy is about choices and trade-offs, and those need human judgement and accountability.

Common mistakes

• Trying to serve every customer group at once.
• Writing a strategy once and never revisiting it, even when evidence says it is wrong.

Product Goal (Scrum Guide 2020)

The commitment for the Product Backlog. It describes a future state of the product and is the long-term objective for the Scrum Team, which must fulfil or abandon one Product Goal before taking on the next.

In detail

The Product Goal describes a future state of the product that the Scrum Team aims for. It is the commitment for the Product Backlog: everything in the backlog should help reach it. It gives the team a clear long-term target to plan against.

The Scrum Team works on one Product Goal at a time. It must either fulfil the goal or abandon it before taking on the next one. Abandoning a goal is not failure; it is a sensible response when evidence shows the goal is no longer valuable.

Example

An HR software team sets the Product Goal: new employees can complete all onboarding tasks on their phone without help from HR. Every Sprint Goal for the next few months is a step toward it, such as uploading documents or signing contracts on mobile.

Using AI

AI can help draft a Product Goal from research notes, check whether backlog items actually support it and highlight items that do not fit. The Product Owner owns the goal and must be able to explain it in their own words.

Common mistakes

• Having several Product Goals at once, which splits focus.
• A Product Goal that is just a list of features instead of a future state.

Product Discovery (Scrum Guide Expansion Pack)

Learning what is valuable before and while building it: research, framing problems, testing assumptions, prototypes and experiments. The Expansion Pack places discovery alongside delivery and asks that discovery work stays transparent in the Product Backlog and Sprint Backlog.

In detail

Product discovery is the work of learning what is valuable before and while building it. It includes user research, framing problems, testing assumptions, building prototypes and running experiments.

The Expansion Pack places discovery alongside delivery. Discovery work should be visible in the Product Backlog and the Sprint Backlog, just like delivery work, so the whole Scrum Team and its stakeholders can see what is being learned and how it changes the plan.

Example

Before building a new invoicing feature, a team spends part of a Sprint interviewing six small-business owners and testing a clickable prototype. They learn that users care most about automatic payment reminders, so the first Increment focuses on reminders instead of invoice design.

Using AI

AI can transcribe and summarise interviews, cluster research notes into themes, generate prototype variations and suggest experiments. It speeds up discovery, but the team must still talk to real users and decide what the evidence means.

Common mistakes

• Doing discovery in a separate team, so the Developers never hear from users directly.
• Hiding discovery work outside the backlog, so stakeholders think nothing is happening.

Product Backlog

Product Backlog (Scrum Guide 2020)

An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team and is never complete.

In detail

The Product Backlog is an emergent, ordered list of everything that is needed to improve the product. It is the single source of work for the Scrum Team: if something is not in the Product Backlog, the team does not work on it.

The backlog is never complete. It changes as the team, the stakeholders and the market learn more. Items near the top are small and clear enough to be worked on soon; items further down can be rough ideas. The Product Owner is accountable for it, but the whole Scrum Team helps keep it healthy.

Example

A team keeps one Product Backlog in its tool. When a sales manager emails a request, the Product Owner adds it to the backlog instead of passing it straight to a Developer. Every request, bug and improvement is visible in one ordered list.

Using AI

AI can find duplicate items, suggest clearer wording, group related items and flag items that have not been touched for months. It can also summarise the backlog for stakeholders. The order and content still reflect the Product Owner's decisions.

Common mistakes

• Keeping several backlogs or side lists, so nobody knows the real priorities.
• Letting the backlog grow into thousands of old items that nobody will ever do.

Product Backlog Item Types (Complementary practice (not part of Scrum))

Epic, Feature, User Story, Bug, Improvement, Technical Debt, Spike and Experiment are popular ways to classify items. Scrum prescribes no item type or format: everything is simply a Product Backlog item.

In detail

Many teams label Product Backlog items by type: Epic (a large body of work), Feature, User Story, Bug, Improvement, Technical Debt, Spike (a time-boxed investigation) and Experiment. These labels help people understand items at a glance and report on work.

Scrum itself does not prescribe any item type or format. To Scrum, everything is simply a Product Backlog item. Use types if they help transparency, but do not let them create separate queues or arguments about classification.

Example

A team uses Epics to group work toward the Product Goal, User Stories for user-facing changes, and Spikes for research, such as a two-day spike to compare two payment providers before deciding which to integrate.

Using AI

AI can suggest an item type, split an Epic into smaller items, or draft a user story in a consistent format. Review the suggestions; a well-formatted item that misses the real need is not useful.

Common mistakes

• Believing user stories are required by Scrum.
• Managing bugs and technical debt in a separate list that the Product Owner never orders.

Ordering the Product Backlog (Scrum Guide 2020)

The Product Owner orders the items. Higher-ordered items are usually clearer, smaller and more detailed than lower-ordered ones. Order reflects value, risk, dependencies and learning.

In detail

The Product Owner orders the Product Backlog. Order is not just priority by importance; it reflects value, risk, dependencies, learning and cost. Sometimes a risky item goes first to learn early, even if it is not the most valuable.

Higher-ordered items are usually clearer, smaller and more detailed, because they will be worked on soon. Lower items can stay large and vague. This saves effort: the team only adds detail when an item is close to being selected.

Example

A team building a booking system orders payment integration above a nicer calendar view. Payments are riskier and depend on a partner, so doing them early exposes problems while there is still time to react.

Using AI

AI can score items against agreed criteria, show the effect of different orders on the Product Goal and point out dependencies. The ordering decision, and the conversation with stakeholders about it, stays with the Product Owner.

Common mistakes

• Labelling everything as high priority, which means nothing is.
• Ordering only by what the most senior stakeholder wants.

Product Backlog Item (PBI) (Scrum Guide 2020)

A single piece of potentially valuable work. Refinement adds details such as description, order and size. The Expansion Pack adds that an item can carry Acceptance Criteria and Outcome Criteria.

In detail

A Product Backlog item (PBI) is a single piece of work that could add value to the product: a feature, a fix, an improvement or an experiment. Through refinement, items gain details such as a description, an order and a size.

The Expansion Pack adds that an item can carry Acceptance Criteria, which say when its output is complete, and Outcome Criteria, which say when enough value has been delivered. Together with the Definition of Done, these make it clear what finished really means.

Example

PBI: Customers can save a card for faster checkout. Description: why it matters and who it is for. Acceptance Criteria: card is stored securely and can be removed. Outcome Criteria: repeat customers check out at least 20% faster. Size: estimated by the Developers.

Using AI

AI can draft descriptions and criteria from a conversation, spot vague words such as fast or easy, and suggest test cases. The team should discuss and agree the item together; a draft is a starting point, not a substitute for shared understanding.

Common mistakes

• Items written as one line with no shared understanding behind them.
• Very large items that cannot be finished within a single Sprint.

Acceptance Criteria (Scrum Guide Expansion Pack)

Conditions specific to one Product Backlog item that show when its output is complete, in addition to the Definition of Done. Not mentioned in the Scrum Guide 2020; described in the Expansion Pack.

In detail

Acceptance Criteria are conditions specific to one Product Backlog item that show when its output is complete. They apply in addition to the Definition of Done, which covers quality standards for every item.

They are not mentioned in the Scrum Guide 2020 but are described in the Expansion Pack and widely used. Good criteria are clear, testable and agreed before the work starts, so the Developers and the Product Owner share the same picture of done for that item.

Example

For a password-reset item: a reset link is emailed within one minute; the link expires after 30 minutes; the user sees a clear message if the link has expired. The Definition of Done separately requires tests, code review and accessibility checks.

Using AI

AI can propose Acceptance Criteria and edge cases you might miss, such as expired links or an email address that does not exist, and turn criteria into test scripts. The Product Owner and Developers confirm which criteria really matter.

Common mistakes

• Repeating the Definition of Done inside every item's criteria.
• Criteria so vague that nobody can test them.

Outcome Criteria (Scrum Guide Expansion Pack)

The why behind the what: criteria on a Product Backlog item that show when enough value has been delivered, complementing the Definition of Outcome Done. Ideally expressed as measures.

In detail

Outcome Criteria describe the why behind the what. They state when enough value has been delivered by a Product Backlog item, for example a change in user behaviour or a business result. Ideally they are expressed as measures.

They complement the Definition of Outcome Done at the product level. Acceptance Criteria tell you the output is complete; Outcome Criteria tell you whether that output achieved its purpose, which is often only visible after release.

Example

For a new onboarding checklist: Acceptance Criteria confirm the checklist works. Outcome Criteria say that at least 70% of new users complete setup within their first day, compared with 45% today. The team checks the data two weeks after release.

Using AI

AI can suggest measurable outcomes for an item, help set up dashboards and analyse whether the outcome moved. Be careful with cause and effect: a change in a metric may have other causes, and people must interpret the evidence honestly.

Common mistakes

• Never checking outcomes after release, so value is assumed instead of proven.
• Choosing a measure that is easy to count but does not reflect real value.

Product Backlog Refinement (Scrum Guide 2020)

The ongoing activity of breaking down and further defining Product Backlog items into smaller, more precise ones. It is not an event. The Developers who will do the work are responsible for sizing.

In detail

Product Backlog refinement is the ongoing activity of breaking down and adding detail to Product Backlog items so they become smaller and more precise. It includes clarifying the need, adding criteria, splitting large items and sizing them.

Refinement is not a Scrum event; teams decide how and when to do it, often a little every week. The Developers who will do the work are responsible for sizing it. The Product Owner may influence the Developers by helping them understand and select trade-offs.

Example

Every Wednesday the team spends one hour on the next items in the backlog. They split a large item, add Acceptance Criteria with the Product Owner and size the items. By Sprint Planning, the top items are ready to be selected.

Using AI

AI can suggest ways to split items, list questions the team should ask and highlight ambiguous wording before the session. Refinement is a conversation, so use AI to prepare it, not to replace it.

Common mistakes

• Skipping refinement and then spending all of Sprint Planning trying to understand items.
• The Product Owner refining alone and handing finished specifications to the team.

Ready & Definition of Ready (Complementary practice (not part of Scrum))

The Scrum Guide says items that can be Done within one Sprint are deemed ready for selection in Sprint Planning. A written Definition of Ready is a common team convention; it is not a Scrum artifact or commitment and should never become a gate.

In detail

The Scrum Guide says that Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in Sprint Planning. Being ready simply means the item is clear and small enough to start.

Some teams write a Definition of Ready, a checklist such as has Acceptance Criteria and has been sized. This is a team convention, not a Scrum artifact or commitment. Used lightly, it helps; used as a strict gate, it delays learning and pushes work back to the Product Owner.

Example

A team's simple ready check: we understand why the item matters, it fits within one Sprint and we know how we will test it. If an important item is not quite ready, they still discuss it in Sprint Planning instead of rejecting it.

Using AI

AI can check items against the team's ready conventions and flag missing information before Sprint Planning. Remember that ready is about shared understanding, which a checklist cannot fully capture.

Common mistakes

• Using a Definition of Ready as a contract that blocks valuable work.
• Believing Definition of Ready is an official part of Scrum.

The Sprint

The Sprint (Scrum Guide 2020)

The heartbeat of Scrum: a fixed-length event of one month or less that contains all other events and all the work. A new Sprint starts immediately after the previous one ends. No changes are made that would endanger the Sprint Goal, and quality does not decrease.

In detail

The Sprint is the heartbeat of Scrum: a fixed-length event of one month or less in which ideas are turned into value. It contains all the other events and all the work. A new Sprint starts immediately after the previous one ends.

During the Sprint, no changes are made that would put the Sprint Goal at risk, quality does not decrease, the Product Backlog is refined as needed and scope may be clarified with the Product Owner. Short Sprints limit risk to a small amount of time and money and give frequent chances to inspect and adapt. A Sprint can be cancelled by the Product Owner if its goal becomes obsolete.

Example

A team works in two-week Sprints from Monday to Friday of the following week. Each Sprint starts with Sprint Planning and ends with the Sprint Review and Sprint Retrospective, and the next Sprint begins the following Monday with no gap.

Using AI

AI can help keep the Sprint visible, for example by summarising progress toward the Sprint Goal or flagging work that has been stuck for several days. The Developers decide how to respond.

Common mistakes

• Changing Sprint length often, which removes the rhythm Scrum depends on.
• Adding hardening or planning gaps between Sprints.

Sprint Planning (Scrum Guide 2020)

Initiates the Sprint by laying out the work to be performed. The whole Scrum Team answers three topics: why is this Sprint valuable, what can be Done, and how will the chosen work get done. Timeboxed to a maximum of eight hours for a one-month Sprint.

In detail

Sprint Planning starts the Sprint by laying out the work to be performed. The whole Scrum Team collaborates and answers three topics: why is this Sprint valuable, what can be Done this Sprint, and how will the chosen work get done.

The Product Owner brings the Product Goal and the most valuable items; the Developers select how much they can complete, based on their past performance, capacity and Definition of Done. Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint, and is usually shorter for shorter Sprints.

Example

In a two-week Sprint, Planning takes about two hours. The Product Owner proposes the goal let returning customers reorder in one click. The Developers pick five items that support it, check their capacity with two people on leave, and break the first items into tasks.

Using AI

AI can prepare Sprint Planning by summarising the top items, showing past delivery data and checking dependencies. It can draft a task breakdown for discussion. The Scrum Team still agrees the goal and the Developers own the plan.

Common mistakes

• The Product Owner or a manager deciding how much work the Developers must take.
• Leaving Sprint Planning without a clear Sprint Goal.

Sprint Goal (Scrum Guide 2020)

The commitment for the Sprint Backlog and the single objective for the Sprint. It gives the Developers flexibility in the exact work needed and creates coherence and focus.

In detail

The Sprint Goal is the single objective for the Sprint and the commitment for the Sprint Backlog. It explains why the Sprint is valuable and gives the Developers flexibility in exactly which work they do to achieve it.

The goal creates focus and coherence: it encourages people to work together instead of on separate tasks. If the work turns out different from what was expected, the Developers talk to the Product Owner to adjust the scope of the Sprint Backlog without changing the goal.

Example

Sprint Goal: shop owners can see today's sales on their phone. Halfway through, a chart library proves slow. The Developers agree with the Product Owner to show a simple table first; the goal is still met, and the chart moves to a later Sprint.

Using AI

AI can help a team phrase a clear, outcome-focused Sprint Goal and check whether the selected items actually support it. The team should be able to explain the goal in one sentence without any tool.

Common mistakes

• A goal that is just the list of selected items.
• Ignoring the goal during the Sprint and treating the Sprint Backlog as a to-do list.

Sprint Backlog (Scrum Guide 2020)

The Sprint Goal (why), the Product Backlog items selected for the Sprint (what) and an actionable plan for delivering the Increment (how). A plan by and for the Developers, updated throughout the Sprint.

In detail

The Sprint Backlog has three parts: the Sprint Goal (why), the Product Backlog items selected for the Sprint (what) and an actionable plan for delivering the Increment (how).

It is a plan by and for the Developers. It is updated throughout the Sprint as more is learned and should be visible enough that anyone can see the progress. It should have enough detail that changes in progress can be inspected in the Daily Scrum.

Example

On the team's board, the Sprint Goal sits at the top, the selected items are in a column, and each item is broken into tasks. When a Developer discovers an extra step, they add a task to the board straight away.

Using AI

AI can help keep the Sprint Backlog up to date, for example by turning stand-up notes into board updates or highlighting tasks with no progress. The Developers decide what changes to make.

Common mistakes

• A manager adding work to the Sprint Backlog without the Developers.
• A Sprint Backlog that is never updated after Sprint Planning.

Daily Scrum (Scrum Guide 2020)

A 15-minute event for the Developers, held every working day at the same time and place, to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.

In detail

The Daily Scrum is a 15-minute event for the Developers, held every working day at the same time and place. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.

The Developers can use any structure that helps, as long as it focuses on the goal and produces a plan for the next day. It improves communication, identifies impediments and promotes quick decisions. It is not a status report to a manager.

Example

Instead of each person reporting what they did, a team walks the board from right to left: what is closest to Done, what is blocked and what should we finish today to protect the Sprint Goal? Detailed problem-solving happens right after, with only the people needed.

Using AI

AI can prepare a short summary before the Daily Scrum, such as items stuck for two days or failing builds, so the team spends its 15 minutes on decisions. Avoid using AI to monitor individuals; it damages trust.

Common mistakes

• Turning the Daily Scrum into a status meeting for the Scrum Master or a manager.
• Solving every problem in the meeting so it runs for 45 minutes.

The Work of the Sprint (Scrum Guide 2020)

During the Sprint the Scrum Team turns selected Product Backlog items into a Done Increment. Scope may be clarified and renegotiated with the Product Owner as more is learned. The Expansion Pack adds discovery and value validation to this work.

In detail

During the Sprint, the Scrum Team turns the selected Product Backlog items into a Done Increment. The Developers organise the work themselves and collaborate across skills to finish items, not just start them.

Scope may be clarified and renegotiated with the Product Owner as the team learns more, as long as the Sprint Goal is protected. The Expansion Pack adds that this work also includes discovery and value validation, not only building.

Example

Two Developers pair on the hardest item first, while another prepares test data. When they find that one item is much bigger than expected, they agree with the Product Owner to deliver a smaller first version that still meets the Sprint Goal.

Using AI

AI coding assistants, test generators and design tools can speed up the work. Every AI-produced change must meet the Definition of Done, including review and testing, just like human work.

Common mistakes

• Starting many items at once and finishing few of them.
• Working in separate silos such as development then testing, so work piles up at the end.

Sprint Board (Complementary practice (not part of Scrum))

A visual board (To Do, In Progress, Done) that makes the Sprint Backlog and progress toward the Sprint Goal transparent. A widely used practice; Scrum does not require a specific board or tool.

In detail

A Sprint board shows the Sprint Backlog visually, usually with columns such as To Do, In Progress and Done. It makes progress toward the Sprint Goal transparent to the team and anyone interested.

It is a practice, not a Scrum requirement. Teams can use a physical wall, a digital tool such as Jira, or any other format. The board is useful only if it reflects reality and helps the team make decisions, especially at the Daily Scrum.

Example

A team adds a work-in-progress limit of three items to the In Progress column. When the column is full, nobody starts a new item; they help finish one instead. Items now reach Done more steadily through the Sprint.

Using AI

AI features in tools such as Jira can summarise the board, predict which items are at risk and suggest when work-in-progress is too high. The team decides whether to act on these signals.

Common mistakes

• A board that nobody updates, so it shows a false picture.
• Too many columns that hide where work is waiting.

Professionalism & Built-in Quality (Scrum Guide Expansion Pack)

The Expansion Pack adds professionalism: striving for excellence and owning the product across its life cycle. In software this includes technical excellence such as clean code, test automation, continuous integration and continuous delivery.

In detail

The Expansion Pack adds professionalism to the picture: striving for excellence, taking ownership of the product across its whole life and holding high standards of work. Quality is built in from the start, not inspected in at the end.

In software this means technical excellence: clean code, automated tests, continuous integration, continuous delivery and attention to security and performance. These practices let the team change the product quickly and safely, which is what agility really needs.

Example

A team adds automated tests to every new feature and runs them on each code change. When they later need to change the pricing logic, the tests show within minutes whether anything else broke, so they can release with confidence the same day.

Using AI

AI can generate test cases, review code for common mistakes and suggest refactoring. Professional teams treat AI output like any other contribution: it is reviewed, tested and understood before it is accepted.

Common mistakes

• Cutting quality to hit a date, which creates technical debt that slows every later Sprint.
• Accepting AI-generated code that nobody in the team understands.

Increment (Scrum Guide 2020)

A concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments, thoroughly verified and usable. Several Increments may be created within a Sprint.

In detail

An Increment is a concrete stepping stone toward the Product Goal. Each Increment adds to all previous Increments and is thoroughly verified, so that they all work together. To provide value, an Increment must be usable.

Work becomes part of an Increment only when it meets the Definition of Done. Several Increments may be created within a Sprint, and an Increment may be released to users before the end of the Sprint. The Sprint Review is not the first moment value can be delivered.

Example

During a two-week Sprint, a team releases a new search filter on day four and a bug fix on day eight. At the Sprint Review they show the combined, working product, including both changes, and discuss what users have done with them.

Using AI

AI can help verify an Increment by generating regression tests and checking that new changes work with existing features. A human decision is still needed on whether the Increment is truly usable and valuable.

Common mistakes

• Calling work an Increment when it is not yet usable or not integrated.
• Waiting for the end of the Sprint to release value that is already Done.

Definition of Done (Scrum Guide 2020)

The commitment for the Increment: a formal description of the quality measures required for the product. Work that does not meet it cannot be released or presented at the Sprint Review and returns to the Product Backlog. The Expansion Pack names it the Definition of Output Done.

In detail

The Definition of Done is the commitment for the Increment: a formal description of the quality the product must meet. The moment a Product Backlog item meets it, an Increment is born. It creates transparency, because everyone shares the same understanding of what Done means.

If an item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review; it returns to the Product Backlog. If the organisation has a standard, the Scrum Team follows it at minimum; otherwise the team creates its own. The Expansion Pack calls it the Definition of Output Done.

Example

A team's Definition of Done: code reviewed by another Developer, automated tests pass, accessibility checks pass, product documentation updated and deployed to the staging environment. An item that is coded but not tested is not Done, however close it is.

Using AI

AI can check parts of the Definition of Done automatically, such as test coverage, accessibility and security scans, and remind the team of steps that are often forgotten. The Developers remain responsible for the quality of the Increment.

Common mistakes

• Calling work 90% done, which hides the real remaining effort.
• A Definition of Done that never improves as the team matures.

Release (Scrum Guide Expansion Pack)

Making a new or updated version of the product available to stakeholders. An Increment may be delivered before the end of the Sprint; the Sprint Review is never a gate to releasing value. A released Increment enables result feedback.

In detail

A release makes a new or updated version of the product available to customers and users. In Scrum, an Increment can be released whenever it meets the Definition of Done and the Product Owner decides it is valuable to release it.

The Sprint Review is never a gate to releasing value. Many teams release several times a Sprint, or even daily. Releasing early is what allows result feedback: real evidence of how users respond.

Example

A team uses feature flags to release a new checkout to 10% of users on Tuesday. By the Sprint Review on Friday, they already have data showing the new flow is faster, and stakeholders discuss rolling it out to everyone.

Using AI

AI can monitor a release, for example by watching error rates and user behaviour and raising an alert if something looks wrong, so the team can roll back quickly. The decision to release or roll back remains a human one.

Common mistakes

• Holding Done work until the end of the Sprint just because the Sprint Review has not happened.
• Releasing without any way to measure the result.

Sprint Review (Scrum Guide 2020)

The Scrum Team and stakeholders inspect the outcome of the Sprint, progress toward the Product Goal and changes in the environment, then collaborate on what to do next. It is a working session, not just a presentation. Maximum four hours for a one-month Sprint.

In detail

The Sprint Review is where the Scrum Team and stakeholders inspect the outcome of the Sprint and decide on future adaptations. They review what was accomplished, progress toward the Product Goal and changes in the environment, then collaborate on what to do next.

It is a working session, not just a presentation or demo. The Product Backlog may be adjusted as a result. It is timeboxed to a maximum of four hours for a one-month Sprint, usually less for shorter Sprints.

Example

Instead of slides, the team lets stakeholders use the new feature on their own phones. The sales lead notices that customers in one region use a different date format; the Product Owner adds an item for it, and the group agrees what should come next.

Using AI

AI can prepare the Sprint Review by summarising what was Done, gathering usage data and collecting stakeholder feedback afterwards into themes. The conversation and decisions happen between people in the room.

Common mistakes

• A one-way demo with no discussion or decisions.
• Showing work that does not meet the Definition of Done.

Sprint Retrospective (Scrum Guide 2020)

The Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and the Definition of Done, and plans ways to increase quality and effectiveness. Maximum three hours for a one-month Sprint.

In detail

The Sprint Retrospective is where the Scrum Team plans ways to increase quality and effectiveness. The team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done.

It discusses what went well, what problems it encountered and how those problems were or were not solved. It then identifies the most helpful changes, which may be added to the next Sprint Backlog. It concludes the Sprint and is timeboxed to a maximum of three hours for a one-month Sprint.

Example

The team notices that code reviews often take two days. They agree to try one change next Sprint: reviews happen before anyone picks up new work. At the next Retrospective they check whether review time actually dropped.

Using AI

AI can collect anonymous feedback before the Retrospective and show patterns in flow, quality and incident data. The team should still talk openly; the trust and decisions that come from the conversation are the point.

Common mistakes

• Listing many problems but agreeing no concrete action.
• Skipping the Retrospective when the team is busy, exactly when it is most needed.

Feedback Loop (Scrum Guide 2020)

Stakeholder feedback and evidence gathered at the Sprint Review may adjust the Product Backlog. This is how Scrum inspects and adapts the product itself.

In detail

The feedback loop is how Scrum inspects and adapts the product itself. At the Sprint Review, stakeholder feedback and evidence about the Increment flow back into the Product Backlog and can change what the team does next.

The shorter this loop, the less the team risks building the wrong thing. A team that waits months for feedback can waste a lot of effort; a team that gets feedback every Sprint can correct course quickly.

Example

Stakeholders at the Sprint Review say the new report is useful but they need it as a weekly email, not a dashboard. The Product Owner reorders the backlog so the email version comes next, instead of the planned dashboard improvements.

Using AI

AI can gather feedback from many channels, such as support tickets, surveys and usage analytics, and present it to the team before the Sprint Review. The Product Owner decides how the feedback changes the backlog.

Common mistakes

• Collecting feedback but never changing the Product Backlog as a result.
• Only hearing from internal stakeholders and never from real users.

Continuous Improvement (Scrum Guide 2020)

The most impactful improvements identified in the Sprint Retrospective are addressed as soon as possible and may be added to the Sprint Backlog of the next Sprint. This is how Scrum inspects and adapts the way of working.

In detail

Continuous improvement is how Scrum inspects and adapts the way the team works. The most impactful improvements identified in the Sprint Retrospective are addressed as soon as possible and can even be added to the next Sprint Backlog.

Small, regular improvements add up. A team that improves one thing every Sprint becomes much more effective over a year than a team that waits for a big change programme.

Example

After a Retrospective, the team adds one improvement item to the next Sprint Backlog: automate the deployment to the test environment. It takes half a day, and it saves about an hour every day afterwards.

Using AI

AI can track whether an improvement worked, for example by comparing cycle time or defect rates before and after a change. It can also suggest experiments based on what other teams have tried. The team chooses which improvements to make.

Common mistakes

• Agreeing improvements at the Retrospective and then forgetting them.
• Trying to change too many things at once, so nobody knows what helped.

Value realization

Value Realization (Scrum Guide Expansion Pack)

The Expansion Pack extends the picture beyond delivery: output (the Increment) leads to outcomes (changes for users) which lead to impact (results for the organisation). Value is only real once evidence confirms it.

In detail

Value realization extends the picture beyond delivering an Increment. The Expansion Pack describes a chain: output (the Increment the team builds) leads to outcomes (changes in what customers and users do) which lead to impact (results for the organisation).

Value is only real once evidence confirms it. A feature can be delivered on time and still create no value if nobody uses it. Teams that focus on value realization measure what happens after release and use that evidence to decide what to do next.

Example

Output: a team releases a self-service password reset. Outcome: calls to the help desk about passwords fall by 40% over a month. Impact: the support team saves several hours a day and customer satisfaction scores rise.

Using AI

AI can connect data from different systems, such as usage analytics, support tickets and sales, to show whether outcomes and impact are actually happening. People must check that the data really links to the change and was not caused by something else.

Common mistakes

• Celebrating output, such as features shipped, as if it were value.
• Measuring impact so late that the team cannot learn from it.

Product (Scrum Guide Expansion Pack)

Introduced as an artifact by the Expansion Pack: the conduit that delivers value, cared for across its entire life cycle. Its commitment is the Definition of Outcome Done.

In detail

The Expansion Pack introduces the Product as an artifact: the vehicle that delivers value to customers and users. A product can be a physical item, a digital service, an internal tool or anything else that provides value.

The Product is cared for across its entire life, from the first idea to retirement, not only while a project is running. Its commitment is the Definition of Outcome Done, which states the evidence needed to show that the product really delivers benefits.

Example

A company stops running separate projects for its customer portal. Instead, one Scrum Team owns the portal as a product: it builds new features, fixes problems, watches usage and eventually decides which old parts to remove.

Using AI

AI can help a team understand the whole life of its product, for example by showing which features are used, which cost the most to maintain and which could be retired. Decisions about the product's future belong to the Product Owner.

Common mistakes

• Treating the product as finished after launch, so nobody looks after it.
• Defining the product so narrowly that the team cannot solve the real customer problem.

Value Validation (Scrum Guide Expansion Pack)

Confirming, or disconfirming, with evidence that the expected outcomes have been achieved. Typical evidence: product telemetry, user observation, customer feedback and measures tracked over time.

In detail

Value validation means confirming, or disconfirming, with evidence that the expected outcomes have been achieved. It turns assumptions about value into facts the team can act on.

Typical evidence includes product telemetry (usage data), watching users, customer feedback, and measures tracked over time. Validation should be planned before release, so the team knows what to measure and avoids interpreting results to fit what it hoped for.

Example

Before releasing a recommendation feature, a team agrees that success means at least 15% of users click a recommendation within a week. After release only 4% do, so they interview users, learn the recommendations are irrelevant, and improve the model.

Using AI

AI can analyse usage data and feedback quickly and highlight whether results meet the expected outcomes. Be careful of bias: the team must look honestly at evidence that disappoints, not only at numbers that look good.

Common mistakes

• Deciding what success looks like only after seeing the results.
• Validating with internal opinions instead of real customer evidence.

Definition of Outcome Done (Scrum Guide Expansion Pack)

A commitment introduced by the Expansion Pack. It describes the observable evidence, quantitative or qualitative, required to demonstrate realised benefits. Best defined before realisation starts to avoid bias.

In detail

The Definition of Outcome Done is a commitment introduced by the Expansion Pack, attached to the Product. It describes the observable evidence, quantitative or qualitative, needed to show that benefits have really been realised.

Where the Definition of Done describes the quality of the output, the Definition of Outcome Done describes the result for customers and the organisation. It is best agreed before the work starts, to avoid bias when the results arrive.

Example

For an online banking product, the Definition of Outcome Done includes: at least 60% of active customers use the app monthly, complaint volume falls quarter on quarter, and fraud losses stay below an agreed level.

Using AI

AI can help track the measures in the Definition of Outcome Done automatically and report trends to stakeholders. People decide whether the evidence is good enough and what to change if it is not.

Common mistakes

• Writing outcomes that can never be measured.
• Confusing the Definition of Outcome Done with the Definition of Done.

Outcomes & Impact (Scrum Guide Expansion Pack)

Outcomes confirm changes for customers and users; impact confirms results for the organisation. Examples: customer satisfaction, changed user behaviour, business results, reduced risk and improved team capability.

In detail

Outcomes show changes for customers and users: they are more satisfied, they behave differently or they achieve their goals faster. Impact shows results for the organisation: revenue, cost, reduced risk or a stronger, more capable team.

Looking at both helps a team avoid local success. A feature might delight users but cost too much to run, or improve a business metric while frustrating customers. Good decisions balance outcomes and impact.

Example

A team simplifies its returns process. Outcome: customers complete returns in two minutes instead of ten, and satisfaction rises. Impact: the cost of handling returns falls and repeat purchases increase.

Using AI

AI can show how outcome and impact measures move together over time and flag when one improves while the other gets worse. Interpreting what this means for the product strategy remains a human task.

Common mistakes

• Measuring only business impact and ignoring what happens to users.
• Choosing too many measures, so nobody knows which ones matter.

Result Feedback & Evidence (Scrum Guide Expansion Pack)

Quantitative and qualitative data that results from changes to the product or its environment. It flows back to stakeholders, the Product Goal and the Product Backlog, closing the empirical loop.

In detail

Result feedback is the quantitative and qualitative data that comes from changes to the product or its environment: usage figures, customer comments, sales numbers, error reports and observations.

It flows back to stakeholders, the Product Goal and the Product Backlog. This closes the empirical loop: the team builds something, releases it, sees what really happens, and uses that evidence to decide what to build next or whether the Product Goal itself should change.

Example

After a new pricing page goes live, sales data shows more sign-ups but also more cancellations in the first week. The result feedback leads the Product Owner to revisit the Product Goal, which now focuses on keeping new customers, not only attracting them.

Using AI

AI can collect and connect result feedback from many sources and highlight surprising changes, such as a sudden drop in a key measure. The team must decide what the evidence means and how to respond.

Common mistakes

• Collecting data that nobody looks at.
• Only looking at feedback that confirms what the team already believes.

The Scrum Team

The Scrum Team (Scrum Guide 2020)

The fundamental unit of Scrum: one Scrum Master, one Product Owner and Developers. A cohesive unit of professionals focused on one Product Goal, with no sub-teams or hierarchies. Cross-functional, self-managing and typically ten or fewer people.

In detail

The Scrum Team is the fundamental unit of Scrum: a small team of people made up of one Scrum Master, one Product Owner and Developers. There are no sub-teams or hierarchies; it is one cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills needed to create value each Sprint, and self-managing, meaning they decide internally who does what, when and how. The team is typically ten or fewer people, small enough to stay nimble and large enough to complete significant work.

Example

A team of seven builds a customer app: a Product Owner, a Scrum Master and five Developers who between them cover design, front-end, back-end, testing and data. They can take an item from idea to released feature without waiting for other departments.

Using AI

AI tools can extend what a small team can do, for example by helping with tasks outside one person's main skill. They do not change accountabilities: the Product Owner, Scrum Master and Developers remain responsible for their work.

Common mistakes

• Splitting the team into a design team, a development team and a test team.
• Teams so large that communication becomes slow and meetings drag on.

Scrum Master (Scrum Guide 2020)

Accountable for establishing Scrum and for the Scrum Team’s effectiveness. A true leader who serves the Scrum Team, the Product Owner and the organisation: coaching self-management, causing the removal of impediments and keeping events positive, productive and within the timebox.

In detail

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness. They help everyone understand Scrum theory and practice, both within the team and across the organisation.

Scrum Masters are true leaders who serve. They coach the team in self-management and cross-functionality, help it focus on creating high-value Increments, cause the removal of impediments, and make sure all events take place and are positive, productive and kept within the timebox. They also help the Product Owner and lead the organisation in its Scrum adoption.

Example

A team's Sprint Reviews are poorly attended. Instead of sending more reminders, the Scrum Master talks to stakeholders, learns the reviews feel like demos, and coaches the team to run a hands-on session around one key question. Attendance and useful feedback both rise.

Using AI

AI can help a Scrum Master prepare events, analyse flow data and summarise retrospective themes, freeing time for coaching. The core of the role, building trust, facilitating hard conversations and helping people grow, still needs a person.

Common mistakes

• Acting as a meeting secretary or project manager who assigns tasks.
• Fixing every impediment personally instead of helping the team learn to solve problems.

Developers (Scrum Guide 2020)

The people committed to creating any aspect of a usable Increment each Sprint. They create the Sprint Backlog, instil quality by adhering to the Definition of Done, adapt their plan each day toward the Sprint Goal and hold each other accountable as professionals. The Expansion Pack calls them Product Developers.

In detail

Developers are the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint. The word covers anyone doing the work: programmers, testers, designers, analysts, data specialists and others.

Developers are accountable for creating the plan for the Sprint (the Sprint Backlog), building quality in by following the Definition of Done, adapting their plan each day toward the Sprint Goal and holding each other accountable as professionals. The Expansion Pack calls them Product Developers.

Example

During the Sprint, a tester sees that the team is behind on the Sprint Goal. Rather than waiting for code to test, she pairs with a programmer to write automated tests first. The Developers share the work instead of staying in their specialist lanes.

Using AI

AI coding and testing assistants can make Developers faster, but they remain accountable for everything they deliver. Developers should understand, review and test AI-generated work and keep sensitive code and data out of tools that are not approved.

Common mistakes

• Thinking only programmers are Developers.
• Each person working only on their own tasks, so items stay half-finished.

Artifacts & events

Scrum Artifacts & Commitments (Scrum Guide 2020)

Artifacts represent work or value and maximise transparency. Each has a commitment that gives focus and a way to measure progress: Product Backlog and Product Goal, Sprint Backlog and Sprint Goal, Increment and Definition of Done. The Expansion Pack adds Product and the Definition of Outcome Done.

In detail

Scrum's artifacts represent work or value. They are designed to make key information transparent, so everyone inspecting them has the same basis for decisions.

Each artifact has a commitment that gives it focus and a way to measure progress: the Product Backlog has the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done. The Expansion Pack adds the Product, whose commitment is the Definition of Outcome Done.

Example

A new stakeholder asks how the team is doing. The Product Owner shows the Product Goal and the ordered backlog, the Scrum Master points to the Sprint Goal on the board, and the Developers show the latest Done Increment. Three artifacts answer the question without a status report.

Using AI

AI can keep artifacts tidy and readable, for example by summarising the backlog or linking items to the Product Goal. The artifacts are only valuable if they reflect reality, so teams should check AI-generated updates.

Common mistakes

• Artifacts that are hidden in tools only one person can access.
• Artifacts without their commitments, so they lose focus.

Scrum Events (Scrum Guide 2020)

The Sprint is a container for Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Each event is a formal opportunity to inspect and adapt Scrum artifacts, held at a regular cadence to reduce complexity.

In detail

Scrum has five events. The Sprint is the container for the other four: Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. Each event is a formal opportunity to inspect and adapt Scrum artifacts.

The events are designed to create regularity and to reduce the need for other meetings. Holding them at the same time and place each Sprint reduces complexity. Each has a maximum duration, or timebox, so that time is used well.

Example

A team with two-week Sprints holds Sprint Planning on the first Monday morning, the Daily Scrum at 9:30 every day, and the Sprint Review and Retrospective on the second Friday afternoon. Because the rhythm is predictable, stakeholders can plan to attend.

Using AI

AI can help prepare and follow up events, such as producing notes, collecting feedback and tracking actions. It should support the events, not replace the conversations they exist for.

Common mistakes

• Skipping events when the team is busy.
• Adding many extra meetings because the Scrum events are not working well.

Scrum Values

Scrum Values (Scrum Guide 2020)

Commitment, Focus, Openness, Respect and Courage. When the Scrum Team and the people it works with embody these values, transparency, inspection and adaptation come to life and build trust.

In detail

Scrum has five values: Commitment, Focus, Openness, Respect and Courage. Successful use of Scrum depends on people becoming more skilled in living these values.

The values guide the Scrum Team's choices, actions and behaviour. When the team and the people it works with embody them, the empirical pillars of transparency, inspection and adaptation come to life and build trust.

Example

At a Sprint Review, a Developer openly says the new feature is slower than expected (openness and courage). The stakeholders thank her rather than blame the team (respect), and everyone agrees to fix performance before adding more features (focus and commitment).

Using AI

AI cannot hold values; people do. But how a team uses AI shows its values, for example being open about which work was AI-assisted, respectful of users' data and courageous enough to question an AI suggestion.

Common mistakes

• Printing the values on a poster without living them.
• An environment where bad news is punished, which destroys openness and courage.

Commitment (Scrum Guide 2020)

The Scrum Team commits to achieving its goals and to supporting each other.

In detail

Commitment means the Scrum Team commits to achieving its goals and to supporting each other. It is not a promise to finish a fixed amount of work regardless of what happens.

Committed teams care about the Sprint Goal and the Product Goal, help each other when someone is stuck, and keep their agreements, such as the Definition of Done. Commitment grows when people have a say in the goals they are asked to reach.

Example

Two days before the end of the Sprint, one Developer is ill. The rest of the team re-plans together, drops a nice-to-have task and makes sure the Sprint Goal is still met.

Using AI

AI can help a team spot early when the Sprint Goal is at risk, so it can respond together. Commitment itself is a human choice that no tool can create.

Common mistakes

• Treating commitment as a fixed scope that must be delivered even if quality suffers.
• Goals imposed on the team, which people feel no ownership of.

Focus (Scrum Guide 2020)

The primary focus is on the work of the Sprint, to make the best possible progress toward its goals.

In detail

Focus means the primary attention is on the work of the Sprint, to make the best possible progress toward its goals. It means finishing work rather than starting more of it.

Focus is protected by a clear Sprint Goal, limited work in progress and a Product Owner who shields the team from constant new requests. It also means avoiding too many parallel projects for each team member.

Example

A team agrees that urgent requests during the Sprint go to the Product Owner, not straight to Developers. The Product Owner decides whether each one is more important than the Sprint Goal; most can wait for the next Sprint.

Using AI

AI can reduce distraction by handling routine tasks such as meeting notes and status summaries. Be careful that new AI tools do not create a stream of notifications that breaks focus.

Common mistakes

• People spread across several teams and projects at once.
• Constant interruptions that break the team's flow.

Openness (Scrum Guide 2020)

The Scrum Team and its stakeholders are open about the work and the challenges.

In detail

Openness means the Scrum Team and its stakeholders are open about the work and the challenges. Problems, risks and mistakes are shared early, while there is still time to do something about them.

Openness is the basis of transparency. If people hide bad news, inspection is based on false information and adaptation will be wrong. Openness requires an environment where honesty is safe.

Example

Midway through the Sprint, the Developers realise an integration is much harder than expected. They tell the Product Owner the same day, together they adjust the scope, and the stakeholders hear about the change before the Sprint Review, not at it.

Using AI

Teams should be open about how they use AI: which parts of the work were AI-assisted, what was checked and what risks remain. This keeps trust with stakeholders and users.

Common mistakes

• Showing only good news at the Sprint Review.
• Keeping problems hidden until the last day of the Sprint.

Respect (Scrum Guide 2020)

Scrum Team members respect each other as capable, independent people, and are respected as such by those they work with.

In detail

Respect means Scrum Team members respect each other as capable, independent people, and are respected as such by the people they work with. It includes respecting different skills, backgrounds and opinions.

Respect shows in everyday behaviour: listening, trusting people to do their work, giving feedback kindly and directly, and respecting decisions such as the Product Owner's ordering of the backlog or the Developers' plan for the Sprint.

Example

A stakeholder disagrees with the Product Owner's priorities. Instead of going around her to a Developer, he raises it at the Sprint Review. The discussion is honest, the Product Owner explains her reasoning and the decision is respected.

Using AI

Respect includes users and colleagues: protecting personal data, not using AI to monitor individuals, and giving credit honestly when work was produced with AI.

Common mistakes

• Managers overriding the team's decisions about how to do its work.
• Blaming individuals for problems that come from the system.

Courage (Scrum Guide 2020)

Scrum Team members have the courage to do the right thing and to work on tough problems.

In detail

Courage means Scrum Team members have the courage to do the right thing and to work on tough problems. That includes saying no, admitting mistakes, challenging the status quo and delivering bad news.

Courage is easier when there is trust and psychological safety. Leaders support courage by thanking people for raising problems instead of punishing them.

Example

A senior manager asks the team to skip testing to meet a launch date. The Scrum Master and Developers explain the risk clearly and propose releasing a smaller, fully tested version on time instead.

Using AI

It takes courage to question an AI recommendation that looks convincing, or to stop using a tool that produces biased or poor-quality results. Teams should feel safe to do both.

Common mistakes

• Saying yes to every request to avoid conflict.
• Staying silent in meetings when something is clearly wrong.

Empiricism

Empiricism (Scrum Guide 2020)

Knowledge comes from experience, and decisions are based on what is observed. Scrum implements empiricism through three pillars: transparency enables inspection, and inspection enables adaptation.

In detail

Empiricism means that knowledge comes from experience and that decisions are based on what is observed. In complex work, you cannot plan everything in advance; you learn by doing, checking and adjusting.

Scrum puts empiricism into practice through three pillars: transparency, inspection and adaptation. Transparency enables inspection, and inspection without adaptation is pointless. The Scrum events give a regular rhythm for all three.

Example

A team is unsure whether customers want a mobile app or a better website. Instead of a long debate, they release a small mobile prototype to a test group, observe how it is used and decide based on the evidence.

Using AI

AI can make empiricism faster and sharper by analysing data quickly. But it can also produce confident-sounding guesses; the team must keep checking what is observed, not just what is predicted.

Common mistakes

• Making decisions based on opinions or seniority instead of evidence.
• Collecting data but never using it to change course.

Transparency (Scrum Guide 2020)

The emergent process and the work must be visible to those doing the work and those receiving it. Decisions are based on the perceived state of the artifacts, so low transparency diminishes value and increases risk.

In detail

Transparency means the emergent process and the work are visible to those doing the work and those receiving it. Important decisions are based on the perceived state of the three artifacts, so the artifacts must reflect reality.

Low transparency leads to decisions that reduce value and increase risk. Transparency enables inspection; inspection without transparency is misleading and wasteful.

Example

A team makes its board, Product Goal, Definition of Done and release dates visible to everyone in the company. When a stakeholder asks for a date, they can see the real state of work and have an informed conversation.

Using AI

AI can improve transparency by summarising complex data into clear dashboards. It can also reduce it, if teams rely on summaries nobody checks. Keep the underlying data accessible.

Common mistakes

• Showing a green status report while the real work is in trouble.
• Information kept in private documents or individual inboxes.

Inspection (Scrum Guide 2020)

Artifacts and progress toward agreed goals are inspected frequently and diligently to detect undesirable variances or problems. The five events provide the cadence for inspection.

In detail

Inspection means the Scrum artifacts and the progress toward agreed goals are inspected frequently and diligently, to detect undesirable variances or problems early.

The five Scrum events provide the cadence for inspection. Inspection should be regular but not so frequent or heavy that it gets in the way of the work.

Example

At the Daily Scrum, the Developers inspect the board and notice that no item has reached Done in four days. They decide to stop starting new work and focus on finishing the two items closest to Done.

Using AI

AI can watch for variances continuously, such as rising defect rates or slowing cycle time, and bring them to the team's attention at the right event. People still decide what the variance means.

Common mistakes

• Inspecting only at the end of a long project, when it is too late to change.
• Inspection that becomes blame instead of learning.

Adaptation (Scrum Guide 2020)

If any aspect of the process deviates outside acceptable limits, or the product is unacceptable, the process or materials are adjusted as soon as possible to minimise further deviation.

In detail

Adaptation means that if any aspect of the process deviates outside acceptable limits, or if the resulting product is unacceptable, the process or materials are adjusted as soon as possible to minimise further deviation.

Adaptation becomes harder when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns something new through inspection.

Example

At the Sprint Review, stakeholders say the new report answers the wrong question. The same afternoon, the Product Owner reorders the backlog, and the team's next Sprint Goal focuses on the report users actually need.

Using AI

AI can suggest adaptations, such as a different order for the backlog or a change to the team's workflow. The team decides which changes make sense, tries them and inspects the result.

Common mistakes

• Seeing a problem at the Retrospective and changing nothing.
• Needing approval from several managers before any change can be made.

Supporting theory

Lean Thinking (Scrum Guide 2020)

Scrum is founded on empiricism and lean thinking. Lean thinking reduces waste and focuses on the essentials; the Expansion Pack adds flow of value, continuous improvement and respect for people.

In detail

Scrum is founded on empiricism and lean thinking. Lean thinking reduces waste and focuses on what is essential: doing only the work that adds value for customers.

The Expansion Pack adds key lean ideas: a smooth flow of value, continuous improvement and respect for people. In practice, this means limiting work in progress, removing delays and hand-offs, and improving the system rather than pushing people harder.

Example

A team maps how a feature travels from idea to release and finds that it waits five days for a separate approval step. By bringing the approver into refinement, they remove most of the waiting time without anyone working harder.

Using AI

AI can analyse flow data and show where work waits longest, which is often the biggest source of waste. Removing that waste usually needs a change in how people and teams work together.

Common mistakes

• Treating lean as cutting people or cost instead of removing waste.
• Keeping people busy instead of keeping work flowing.

Complexity (Scrum Guide Expansion Pack)

In complex work there are more unknowns than knowns, and cause and effect are only clear in hindsight. Expertise helps but is not enough, which is the case for an empirical approach such as Scrum.

In detail

In complex work there are more unknowns than knowns, and cause and effect are often only clear afterwards. Building new products, changing organisations and working with new technology are usually complex.

Expertise helps, but it is not enough to predict the result. That is why an empirical approach such as Scrum works well: instead of planning everything up front, the team takes small steps, observes what happens and adjusts.

Example

A team building a new AI-based feature cannot know in advance how accurate it will be with real customer data. They release a small version to a few users, measure the results and decide the next step from there.

Using AI

AI products themselves often add complexity, because their behaviour can change with new data. Teams should expect surprises, test with real data early and keep humans able to override results.

Common mistakes

• Treating complex work as if it were simple and fully plannable.
• Blaming people when a detailed upfront plan turns out to be wrong.

Emergence (Scrum Guide Expansion Pack)

Meaningful patterns arise from interactions that cannot be predicted from the parts. Scrum guides emergence with enabling constraints such as timeboxes, roles and feedback loops instead of prescribing outcomes.

In detail

Emergence describes how meaningful patterns arise from interactions between people and parts of a system, in ways that cannot be predicted by looking at the parts alone. Good team culture, product ideas and solutions often emerge this way.

Scrum guides emergence with enabling constraints, such as timeboxes, clear accountabilities, goals and feedback loops, instead of prescribing exactly what must happen. These constraints give enough structure for good patterns to appear and for the team to notice them.

Example

A team does not plan a design system up front. After a few Sprints, the Developers notice they keep building the same components and agree to turn them into a shared library. The design system emerged from the work.

Using AI

AI can help notice emerging patterns, for example recurring themes in feedback or code. Teams should treat these as signals to explore together, not as instructions to follow.

Common mistakes

• Trying to design every detail in advance.
• Removing all structure and hoping good results appear on their own.

Self-Management (Scrum Guide 2020)

The Scrum Team decides internally who does what, when and how. The Expansion Pack adds that a self-managing team checks whether it is on track, acts when it is not and resolves its own problems, with aligned autonomy.

In detail

Self-management means the Scrum Team decides internally who does what, when and how. Nobody outside the team tells the Developers how to turn Product Backlog items into Increments.

The Expansion Pack adds that a self-managing team checks whether it is on track, acts when it is not and resolves its own problems, with aligned autonomy: freedom in how it works, aligned with the organisation's goals and constraints.

Example

When a key Developer leaves, the team decides itself how to share her knowledge: two people pair on her work for a week and they update the documentation. The manager supports them but does not dictate the solution.

Using AI

AI can give a self-managing team better information, such as forecasts and quality trends, so it can make its own decisions well. It should not become a hidden manager that assigns work to people.

Common mistakes

• Calling a team self-managing while a manager still assigns all the tasks.
• Autonomy without alignment, so the team works hard on the wrong things.

Product Thinking (Scrum Guide Expansion Pack)

People consume products, not projects. Product thinking balances short-term growth with long-term concerns such as technical debt, total cost of ownership and customer lifetime value.

In detail

People use products, not projects. Product thinking means focusing on the product and the value it gives over its whole life, rather than on finishing a project with a fixed end date.

Product thinking balances short-term growth with long-term concerns, such as technical debt, the total cost of ownership and the lifetime value of customers. A decision that wins this quarter but damages the product next year is not a good product decision.

Example

A team could add a quick workaround to win a big customer this month, but it would make the product harder to maintain. They choose a slightly slower, cleaner solution that serves this customer and many others in future.

Using AI

AI can help estimate long-term effects, such as maintenance cost or customer retention, from historical data. These estimates support product thinking but should not hide the uncertainty behind them.

Common mistakes

• Disbanding the team when the project ends, so nobody looks after the product.
• Ignoring technical debt until it slows everything down.

Systems Thinking (Scrum Guide Expansion Pack)

Elements of an organisation are interconnected, so a change in one place ripples elsewhere. Avoid local optimisation and consider upstream, cross-stream and downstream effects.

In detail

Systems thinking recognises that the parts of an organisation are connected. A change in one place ripples elsewhere, often in unexpected ways.

It warns against local optimisation: making one team or step faster can make the whole system slower. Teams consider upstream effects (where their work comes from), cross-stream effects (other teams) and downstream effects (who receives their work).

Example

A development team doubles its release speed, but the support team is not ready for the new features and customer complaints rise. Looking at the whole system, they agree to involve support in Sprint Reviews and release notes.

Using AI

AI can map dependencies between teams, systems and processes and show how a change in one area affects others. Changing the system still needs people from different parts of the organisation to work together.

Common mistakes

• Measuring each team separately and rewarding local speed.
• Fixing symptoms in one team while the root cause sits elsewhere.

Leadership (Scrum Guide Expansion Pack)

A set of qualities, not a management position. It cultivates the environment for self-managing teams, clarity and trust, and is shown by Product Owners, Scrum Masters, Developers and Supporters alike.

In detail

In Scrum, leadership is a set of qualities, not a management position. It is about creating an environment where self-managing teams can thrive: clear purpose, trust, support and the removal of obstacles.

Leadership is shown by Product Owners, Scrum Masters, Developers and Supporters alike. A Developer who mentors a colleague or speaks up about quality is showing leadership just as much as a senior manager.

Example

A director stops asking teams for weekly status reports and instead attends Sprint Reviews to see working products and ask how she can help. The teams spend less time reporting and more time delivering value.

Using AI

Leaders set the tone for responsible AI use: clear guidelines, approved tools, time to learn and a culture where people can question AI outputs. Leadership in the age of AI is about judgement and trust, not just adopting tools.

Common mistakes

• Command-and-control behaviour labelled as agile leadership.
• Believing only people with a title can lead.

Cadence (Scrum Guide Expansion Pack)

Working in Sprints gives a consistent rhythm that supports regular inspection and adaptation and, over time, a sustainable pace and better predictability.

In detail

Cadence is the steady rhythm created by working in Sprints of a consistent length. Every Sprint has the same events at roughly the same times.

This rhythm supports regular inspection and adaptation, makes it easier for stakeholders to take part and, over time, helps the team work at a sustainable pace and become more predictable.

Example

A team keeps two-week Sprints for a year. Stakeholders know the Sprint Review is every second Thursday, the team's delivery becomes steadier, and forecasts for the Product Goal become more reliable.

Using AI

AI can use the data from a steady cadence, such as how much work the team completes per Sprint, to produce better forecasts. Forecasts are guides, not promises, and the team should share their uncertainty.

Common mistakes

• Changing Sprint length every few weeks.
• Working overtime every Sprint, which is not a sustainable pace.

People & Change (Scrum Guide Expansion Pack)

Adopting Scrum is hard and emergent: it has a direction, not a predefined destination. It needs intentional change agents and continual small improvements within people’s grasp.

In detail

Adopting Scrum is hard and emergent. It has a direction, not a fixed destination, because every organisation discovers its own path as it learns.

Successful change needs intentional change agents, such as Scrum Masters and Supporters, and continual small improvements that are within people's reach. Large, top-down programmes that try to change everything at once often fail.

Example

A company starts with two volunteer Scrum Teams, learns from their experience for three months, then shares the stories with other departments. New teams join when they see real results.

Using AI

AI is itself a major change for many teams. The same principles apply: start small, experiment, learn and support people with training instead of expecting instant adoption.

Common mistakes

• Announcing an agile transformation with a fixed end date.
• Changing team names and job titles while keeping the old way of working.

AI in Scrum

Artificial Intelligence in Scrum (Scrum Guide Expansion Pack)

The Expansion Pack treats AI as part of the work environment that may expand a Scrum Team’s capabilities in discovery, decision-making, product development and value realization, while human accountability stays unchanged.

In detail

The Expansion Pack treats artificial intelligence as part of the work environment that may expand what a Scrum Team can do. AI can help in discovery, decision-making, product development and value realization.

Human accountability does not change. The Product Owner is still accountable for value, the Developers for the quality of the Increment and the Scrum Master for the team's effectiveness. AI is a powerful assistant, used deliberately and inspected regularly.

Example

A team agrees simple working rules for AI: approved tools only, no customer data in public tools, every AI-generated change is reviewed and tested, and the team inspects its use of AI at each Retrospective.

Using AI

Use AI where it saves time or improves insight, and inspect its results like any other work. Start with small, low-risk uses, learn what works and expand gradually.

Common mistakes

• Using AI because it is fashionable, without a clear problem to solve.
• Letting AI decisions replace accountable human judgement.

AI for Sharper Empiricism (Scrum Guide Expansion Pack)

AI-driven analytics can improve transparency, inspection and adaptation, for example by surfacing trends in usage, flow and quality data faster than people can.

In detail

AI-driven analytics can strengthen Scrum's empirical pillars. They can make more information transparent, support more frequent and thorough inspection and help the team adapt faster.

For example, AI can surface trends in usage, flow and quality data much faster than people can by hand. The team still needs to ask whether the data is reliable and what it really means.

Example

An AI analytics tool notices that customers who use a new feature are more likely to cancel within a month. The team investigates, finds a confusing message in the feature and fixes it in the next Sprint.

Using AI

Pair every AI insight with a human check: look at the raw data behind it, talk to a few users and confirm the pattern before making big decisions.

Common mistakes

• Trusting an AI insight without checking the data behind it.
• Producing more dashboards but making no better decisions.

Cognitive Augmentation (Scrum Guide Expansion Pack)

AI takes on routine cognitive work so that human Scrum Team members can focus on strategic, creative and ethical considerations.

In detail

Cognitive augmentation means AI takes on routine thinking work, such as summarising, drafting, sorting and checking, so that people can focus on strategic, creative and ethical questions.

The goal is not to replace people but to give them more time and better information for the work that needs human judgement: understanding customers, making trade-offs and building trust.

Example

A Product Owner uses AI to draft release notes and summarise 200 survey responses. That saves her a day each Sprint, which she now spends talking to customers and stakeholders.

Using AI

Choose tasks for AI that are routine, easy to check and low risk if wrong. Keep tasks that involve sensitive judgement, relationships or ethics firmly with people.

Common mistakes

• Using AI to produce more output instead of better thinking.
• Losing skills because people no longer understand the work AI does for them.

AI for Systems Insight (Scrum Guide Expansion Pack)

AI can identify hidden interdependencies and deliberately challenge existing thinking, improving data-informed decisions.

In detail

AI can help reveal hidden connections in complex systems: dependencies between teams, components or processes that people may not see. It can also deliberately challenge existing assumptions by offering alternative views.

Used well, this improves data-informed decisions. Used carelessly, it can create false confidence. Treat AI insights as questions to explore, not as answers.

Example

An AI tool analysing a company's code and tickets shows that three teams keep changing the same payment module, causing frequent conflicts. Leaders use this insight to reorganise ownership of the module.

Using AI

Ask AI to argue the opposite of your current plan, or to list risks you may have missed. Then discuss its points as a team and decide which ones matter.

Common mistakes

• Accepting a dependency map from AI without checking it with the people involved.
• Using AI to confirm decisions already made instead of to challenge them.

AI in Discovery (Scrum Guide Expansion Pack)

Discovery is one of the areas the Expansion Pack says AI may expand. AI can synthesise research, interviews and market signals and help validate assumptions faster; the Scrum Team still judges what is valuable.

In detail

Discovery is one of the areas where the Expansion Pack says AI may expand a team's capabilities. AI can synthesise research, interview notes and market signals and help validate assumptions faster.

The Scrum Team still judges what is valuable. AI can speed up the analysis, but direct contact with real customers and users remains essential, because AI summaries can miss nuance or reflect bias in the data.

Example

A team records ten customer interviews. AI transcribes them and groups the comments into five themes in an hour. The team then reads the original notes for the top two themes before deciding what to explore next.

Using AI

Use AI to prepare interview guides, summarise findings and generate experiment ideas. Get consent before recording interviews and keep personal data out of tools that are not approved.

Common mistakes

• Replacing real user research with AI-generated personas.
• Treating AI summaries as complete without reading any original feedback.

AI-assisted Backlog Insight (Scrum Guide Expansion Pack)

AI can help refine Product Backlog items, discover ambiguities in text, and suggest updates or re-ordering informed by live user feedback and trends, making ordering more transparent.

In detail

AI can help keep the Product Backlog clear and useful. It can help refine items, spot ambiguities in the text, find duplicates and suggest updates or re-ordering based on live user feedback and trends.

This can make ordering decisions more transparent, because the reasons behind a suggested order can be shown. The Product Owner remains accountable for the content and order of the backlog.

Example

Before refinement, AI flags that three backlog items describe the same problem in different words and that one item uses the unclear word quickly without a measure. The team merges the items and adds a clear target.

Using AI

Ask AI to explain why it suggests an order, and compare that reasoning with the Product Goal. Discard suggestions that conflict with what you know about customers.

Common mistakes

• Letting AI re-order the backlog automatically.
• Adding many AI-generated items that nobody has discussed.

AI in Planning (Complementary practice (not part of Scrum))

AI can support Sprint Planning with forecasts, capacity scenarios and dependency checks. This is a practitioner use that the Expansion Pack does not name specifically; the Scrum Team still owns the Sprint Goal and the plan.

In detail

AI can support Sprint Planning with forecasts based on past delivery, capacity scenarios that account for holidays and leave, and checks for dependencies between items.

This is a practitioner use: the Expansion Pack does not name AI for planning specifically. Whatever tools are used, the Scrum Team still owns the Sprint Goal, and the Developers own the plan and how much work they take on.

Example

Before Sprint Planning, an AI tool shows that the team usually completes about 30 points per Sprint, but two people are on leave this time. The team uses this as one input and selects slightly less work than usual.

Using AI

Present forecasts as ranges, not single numbers, and talk about what could change them. A forecast is a starting point for the conversation, not a target.

Common mistakes

• Turning AI forecasts into commitments imposed on the team.
• Ignoring the team's own knowledge of the work in favour of a model.

AI in Build & Test (Scrum Guide Expansion Pack)

Product development is one of the areas the Expansion Pack says AI may expand. AI assistance in design, coding and testing augments people so they can focus on strategic, creative and ethical work. The Definition of Done still applies to everything produced.

In detail

Product development is one of the areas where the Expansion Pack says AI may expand a team's capabilities. AI assistants can help with design, coding, testing and documentation, augmenting people so they can focus on strategic, creative and ethical work.

The Definition of Done still applies to everything produced, whether by a person or with AI. AI-generated code, tests and designs must be reviewed, understood and verified before they become part of an Increment.

Example

A Developer uses an AI assistant to write a first version of a data-import function and its tests. A colleague reviews the code, finds that it ignores empty files, and they fix it together before the item is Done.

Using AI

Agree team rules: which tools are approved, what may and may not be shared with them, and how AI-generated work is reviewed. Watch quality measures to check that AI is helping, not adding hidden defects.

Common mistakes

• Accepting AI-generated code without review because it looks correct.
• Sharing confidential code or customer data with unapproved tools.

AI for Feedback & Evidence (Scrum Guide Expansion Pack)

AI-driven analytics can improve transparency, inspection and adaptation by analysing usage, feedback and trends, and can reveal hidden interdependencies that improve data-informed decisions.

In detail

AI-driven analytics can analyse usage data, feedback and trends to improve transparency, inspection and adaptation. They can also reveal hidden connections that lead to better data-informed decisions.

This is especially useful for result feedback after a release, when there may be large amounts of data from many sources. The team still decides which signals matter and what to do about them.

Example

After a release, AI groups 1,500 app-store reviews and shows that most complaints are about a slow login, not the new feature. The team makes login performance the next Sprint Goal.

Using AI

Check AI-grouped feedback against a sample of the original comments, and be aware that the loudest feedback is not always the most representative.

Common mistakes

• Measuring sentiment scores without reading what customers actually said.
• Analysing feedback but never sharing the findings with stakeholders.

AI in the Retrospective (Complementary practice (not part of Scrum))

AI can surface patterns in flow, quality and feedback data as input to the Sprint Retrospective. This is a practitioner use that the Expansion Pack does not name specifically; the conversation and the improvements belong to the Scrum Team.

In detail

AI can provide input to the Sprint Retrospective by surfacing patterns in flow, quality and feedback data, for example how long items waited, where defects came from or recurring themes in team surveys.

This is a practitioner use: the Expansion Pack does not name AI for retrospectives specifically. The conversation, the trust and the improvements belong to the Scrum Team.

Example

Before the Retrospective, an AI summary shows that items waited an average of two days for code review. The team discusses why, agrees to review work before starting new tasks and checks the effect next Sprint.

Using AI

Use AI for data and anonymous input, not to judge individuals. Make sure people feel safe; a Retrospective only works when people can speak honestly.

Common mistakes

• Replacing the team conversation with an AI report.
• Using AI data to rank or blame individual team members.

Guardrails: Human in the Loop (Scrum Guide Expansion Pack)

AI is a powerful but supervised partner. The Scrum Team remains accountable for outcomes, evidence and ethics; it experiments with AI in small, reversible trials and continuously inspects AI recommendations for bias, errors and unintended consequences.

In detail

AI is a powerful but supervised partner. The Scrum Team remains accountable for outcomes, evidence and ethics, whatever tools it uses.

Teams experiment with AI in small, reversible trials and continuously inspect AI recommendations for bias, errors and unintended consequences. A human checks important outputs before they affect customers, decisions or the product.

Example

A team uses AI to draft replies to customer support emails. Every draft is reviewed by a person before sending, and the team checks a sample each week for tone, accuracy and fairness. After a month they agree which simple replies can be sent with lighter checks.

Using AI

Set clear guardrails: who reviews AI output, which decisions AI may never make alone, how data is protected and how problems are reported. Inspect these guardrails at the Retrospective like any other part of the way of working.

Common mistakes

• Fully automating decisions that affect customers before trust is earned.
• Assuming AI output is neutral and free of bias.

This map is original teaching language from The Agile Forum, grounded in the Scrum Guide (2020). It is not a substitute for the Guide, and it is not a certification syllabus. Source: scrumguides.org.

Put Scrum into practice: Scrum Master Live Project Mentorship · Scrum Master interview questions