Top 49 Agile / Scrum Interview Questions & Answers (2026)

Agile methodology is an iterative and incremental approach to software development and project management that emphasizes flexibility, collaboration, and continuous delivery of working software. Rather than planning and delivering a complete product all at once (as in Waterfall), Agile breaks work into small, manageable cycles called iterations or sprints, each producing a potentially shippable increment. The Agile philosophy emerged in 2001 with the publication of the Agile Manifesto, which prioritizes individuals and interactions over processes, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Agile encompasses multiple frameworks including Scrum, Kanban, XP (Extreme Programming), and SAFe.

The Agile Manifesto (2001) defines four core values: (1) Individuals and interactions over processes and tools — people and communication are more important than following rigid processes or using specific tools; (2) Working software over comprehensive documentation — functional software that delivers value is more important than extensive written documentation, though documentation still has value; (3) Customer collaboration over contract negotiation — ongoing collaboration with the customer throughout development is more valuable than negotiating fixed requirements upfront; (4) Responding to change over following a plan — being able to adapt to changing requirements is more important than rigidly following a plan. The manifesto states: "while there is value in the items on the right, we value the items on the left more."

The 12 Agile principles guide practitioners: (1) Satisfy the customer through early and continuous delivery of valuable software; (2) Welcome changing requirements, even late in development; (3) Deliver working software frequently (weeks rather than months); (4) Business people and developers must work together daily; (5) Build projects around motivated individuals with needed support and trust; (6) The most efficient communication is face-to-face conversation; (7) Working software is the primary measure of progress; (8) Agile promotes sustainable development (constant pace indefinitely); (9) Continuous attention to technical excellence and good design; (10) Simplicity — maximizing work not done; (11) Self-organizing teams produce the best architectures, requirements, and designs; (12) Regularly reflect and adjust behavior. These principles are framework-agnostic — they apply to Scrum, Kanban, XP, and other Agile approaches.

Scrum is the most widely adopted Agile framework for developing, delivering, and sustaining complex products. It is defined by a lightweight set of rules in the Scrum Guide (maintained by Ken Schwaber and Jeff Sutherland, its co-creators). Scrum organizes work into Sprints (time-boxed iterations of 1–4 weeks), uses three accountabilities (Product Owner, Scrum Master, Developers), maintains three artifacts (Product Backlog, Sprint Backlog, Increment), and conducts five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). Scrum's core theory is built on empiricism (decisions based on observation and experience) and lean thinking (reduce waste, focus on essentials). It is intentionally incomplete — prescribing only what is essential and leaving the rest to practitioners.

Scrum defines three accountabilities (the 2020 Scrum Guide replaced "roles" with "accountabilities"): (1) Product Owner — accountable for maximizing the value of the product. Manages and prioritizes the Product Backlog, defines product goals, and ensures the Developers understand backlog items. Is one person (not a committee) and has final say on what gets built; (2) Scrum Master — accountable for establishing Scrum as defined in the Scrum Guide, serving the Scrum Team, the Product Owner, and the organization. Removes impediments, facilitates Scrum events, and coaches on Scrum theory and practices; (3) Developers — the skilled professionals who create the Increment. Self-managing, cross-functional, typically 3–9 people. Accountable for creating a plan for the Sprint (Sprint Backlog) and adhering to the Definition of Done.

A Sprint is the heartbeat of Scrum — a time-box of one month or less during which the Scrum Team creates a valuable, useful Increment. Key characteristics: (1) Fixed duration — once chosen (1, 2, 3, or 4 weeks), Sprint length stays consistent to create rhythm and predictability; (2) Sprint Goal — a single objective that gives the Sprint purpose and focus; (3) No changes during Sprint — Scope changes that endanger the Sprint Goal are discouraged, though Developers can renegotiate scope with the Product Owner; (4) Potentially releasable increment — every Sprint produces something potentially valuable enough to release; (5) Sprints can be cancelled — only the Product Owner can cancel a Sprint, only if the Sprint Goal becomes obsolete (rare). Sprints create a consistent cadence that enables accurate velocity measurement and predictable planning.

The Product Backlog is an ordered list of everything needed to improve the product — it is the single source of work for the Scrum Team. It is maintained by the Product Owner, who is responsible for its content, availability, and ordering. Key characteristics: (1) Dynamic — constantly evolves as the product and market evolve; (2) Ordered by value — higher-priority items are at the top, more refined, and smaller; lower-priority items are coarser; (3) Items — called Product Backlog Items (PBIs); often expressed as User Stories (though not required by Scrum); (4) Estimates — items typically have effort estimates (story points, days); (5) Product Goal — the long-term objective embedded in the Product Backlog. Backlog Refinement is the ongoing process of adding detail, estimates, and order to backlog items.

The Sprint Backlog is the plan created by the Developers for the current Sprint, consisting of three elements: (1) Sprint Goal (the why); (2) Selected Product Backlog Items (the what) — the items chosen during Sprint Planning that the Developers commit to completing; (3) Plan to deliver the Increment (the how) — the tasks and technical steps the Developers identify to complete the selected items. The Sprint Backlog is a highly visible, real-time picture of the work the Developers plan to accomplish during the Sprint. It belongs entirely to the Developers — they own and update it throughout the Sprint. Unlike the Product Backlog (owned by PO), no one else can add or change Sprint Backlog items during the Sprint without the Developers' consent. It is updated as new information emerges during development.

The Daily Scrum is a 15-minute time-boxed event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. It is held at the same time and place every working day. The Developers choose the format and questions — the classic (and now just one suggested approach) asks: What did I do yesterday? What will I do today? Are there any impediments? The 2020 Scrum Guide removed these specific questions, leaving it to the Developers to structure the meeting as long as it focuses on the Sprint Goal and produces an actionable plan. The Scrum Master does not run the Daily Scrum — Developers do. The Product Owner and Scrum Master participate as Developers if they're actively working on Sprint items. Key purpose: promote communication, identify impediments early, and eliminate the need for other status meetings.

The Sprint Review is a time-boxed event (max 4 hours for a 1-month Sprint, proportionally less for shorter Sprints) held at the end of the Sprint. Its purpose is to inspect the Increment and adapt the Product Backlog. It is NOT a demo or status report — it is a collaborative working session. Attendees: entire Scrum Team + invited stakeholders. What happens: (1) The Product Owner explains which Product Backlog items have been Done and which have not; (2) Developers discuss what went well, what problems were encountered; (3) Developers demonstrate Done work; (4) Stakeholders and the Product Owner discuss what to do next, adjusting the Product Backlog based on market feedback, new insights, and product performance data. Output: a revised Product Backlog reflecting new priorities based on the Sprint's learnings. The Sprint Review is an opportunity for feedback and course correction, not a gate/approval process.

The Sprint Retrospective is a time-boxed event (max 3 hours for 1-month Sprint) held after the Sprint Review and before the next Sprint Planning. Its purpose is for the Scrum Team to plan ways to increase quality and effectiveness. The team inspects: how the last Sprint went (individuals, interactions, processes, tools, DoD); what went well; what problems occurred; how problems were solved. The outcome: identifies the most helpful changes and adds them as improvements to the next Sprint. The Retrospective is the team's opportunity for continuous improvement — a structured reflection ritual. Common formats: Start/Stop/Continue, Mad/Sad/Glad, 4Ls (Liked, Learned, Lacked, Longed For), Prime Directive reminder ("Everyone did the best job they could given the circumstances"), and dot voting on action items. At least one high-priority improvement should become a Sprint Backlog item in the next Sprint.

Sprint Planning initiates the Sprint by planning the work to be performed. It is time-boxed to a maximum of 8 hours for a 1-month Sprint (proportionally shorter for shorter Sprints). The entire Scrum Team attends. Sprint Planning answers three questions: (1) Why is this Sprint valuable? — The Product Owner proposes how the Sprint can increase the product's value. The team collaborates to define the Sprint Goal; (2) What can be Done this Sprint? — Developers select items from the top of the Product Backlog. Only Developers decide how much they can take on — the Product Owner cannot force more work; (3) How will the chosen work get done? — Developers decompose selected PBIs into tasks/hours, creating the Sprint Backlog. The Sprint Goal is finalized, and the selected PBIs and plan to deliver them constitute the Sprint Backlog.

The Scrum Master is a servant-leader who helps the Scrum Team and the organization understand and enact Scrum. Their responsibilities: Serving the Scrum Team: coaching Developers in self-management and cross-functionality, helping focus on creating high-value Increments, removing impediments, ensuring productive Scrum events. Serving the Product Owner: helping define the Product Goal and manage the Product Backlog effectively, facilitating stakeholder collaboration. Serving the organization: leading and coaching Agile adoption, planning and advising Scrum implementations, helping employees and stakeholders understand empirical product development. The Scrum Master is NOT a project manager, doesn't assign tasks, doesn't make product decisions, and doesn't boss the team. They are a coach, facilitator, and impediment remover. Their influence comes from expertise and service, not authority.

The Product Owner (PO) is accountable for maximizing the value of the product resulting from the Scrum Team's work. Key responsibilities: (1) Product Goal — developing and explicitly communicating the long-term product objective; (2) Backlog management — creating and clearly communicating Product Backlog items, ordering them to maximize value; (3) Stakeholder management — representing stakeholder needs to the Developers, ensuring they understand what needs to be built and why; (4) Acceptance — deciding whether each increment meets the Definition of Done and is acceptable. The PO is a single person (not a committee) with final authority on backlog ordering. They may delegate work but remain accountable. Effective POs are available to answer Developer questions, decisive about priorities, and skilled at balancing business, technical, and user needs. The PO role bridges business and technology.

In the 2020 Scrum Guide, the development team is called simply the Developers — skilled professionals who create the Increment. Key characteristics: (1) Self-managing — internally decide who does what, when, and how. No one (not even the Scrum Master) tells them how to turn backlog items into increments; (2) Cross-functional — collectively have all skills necessary to create value each Sprint (design, development, testing, DevOps); (3) Accountable together — success and failure belong to the whole team, not individuals; (4) 3–9 members — small enough for agility, large enough to complete significant work. Fewer than 3 lacks cross-functionality; more than 9 requires too much coordination; (5) No sub-teams or titles — everyone is a "Developer" regardless of specialization; (6) Pull work — select Sprint Backlog items themselves during Sprint Planning based on capacity and the Sprint Goal.

A User Story is a lightweight format for capturing a product requirement from the user's perspective. The classic template: "As a [type of user], I want [some goal] so that [some reason]." Example: "As a registered customer, I want to save my shipping address so that I don't have to re-enter it on future orders." User Stories are NOT a Scrum requirement — the Scrum Guide doesn't mention them — but they are widely used as a practical format for Product Backlog Items. Good user stories follow the INVEST criteria: Independent (can be developed independently), Negotiable (details are negotiable, not a contract), Valuable (delivers value to the user), Estimable (can be sized), Small (fits in a Sprint), Testable (has clear acceptance criteria). User Stories are completed with Acceptance Criteria that define when the story is done from the user's perspective.

Velocity is the amount of work a Scrum Team completes during a Sprint, measured in story points (or other estimation units). It is calculated as the sum of story points for all completed (Done) Product Backlog Items in a Sprint. For example, if a team completes items totaling 34 story points in a Sprint, their velocity for that Sprint is 34. Velocity is used for forecasting: if a team has an average velocity of 30 points/sprint and the remaining backlog has 120 points, they can forecast approximately 4 more sprints to complete it. Velocity stabilizes after a few sprints and becomes a useful planning tool. Important caveats: velocity is a planning tool, not a performance metric — comparing velocities between teams is meaningless (different definitions of story points). Velocity naturally varies ±20%; trends are more meaningful than individual sprint numbers.

The Definition of Done (DoD) is a formal description of the state a Product Backlog Item must reach to be considered complete. It creates a shared understanding of quality across the Scrum Team. A typical DoD might include: code is written and peer-reviewed, unit tests pass with ≥80% coverage, integration tests pass, documentation updated, security scan passed, code deployed to staging, product owner accepted. The DoD is created by the Scrum Team (if not specified by the organization) and is applied consistently to all increments. It evolves over time as the team's standards improve. DoD is different from Acceptance Criteria (which are item-specific conditions) — DoD applies universally to every item. If a Product Backlog Item does not meet the DoD, it cannot be included in the Sprint's Increment and returns to the Product Backlog. A strong DoD is the foundation of quality and trust in Scrum.

A burndown chart is a visual representation of work remaining in a Sprint or project over time. The Y-axis shows work remaining (story points or hours), and the X-axis shows time (Sprint days). An ideal burndown line connects the starting total to zero at the Sprint end. The actual burndown line shows daily progress. If the actual line is above the ideal, the team is behind schedule; below the ideal means ahead of schedule. Sprint burndown tracks daily remaining Sprint Backlog work. Release burndown tracks Sprint-over-Sprint remaining Product Backlog work. Common patterns: a flat line indicates blocked work; a sudden drop indicates a batch completion; a line going up means work was added mid-Sprint. Burndown charts are a transparency tool, not a management weapon — teams should use them for self-inspection, not pressure. Kanban uses Cumulative Flow Diagrams as an alternative.

Story Points are a relative estimation unit used to measure the effort, complexity, and uncertainty of Product Backlog Items — NOT time or hours. They capture three factors: (1) Effort — how much work is involved; (2) Complexity — how complicated the problem is; (3) Uncertainty/Risk — how much is unknown. The key insight: story points are relative. A 2-point story should take roughly twice as much overall work as a 1-point story. Typical scales: Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 40, 100) or T-shirt sizes (XS, S, M, L, XL). The Fibonacci scale is popular because the gaps grow as uncertainty grows — there's no meaningful difference between 6 and 7 hours of work, but 5 vs. 8 points reflects meaningfully different complexity levels. Story points decouple estimates from calendar time, making them more stable across team members with different speeds. They enable velocity tracking without committing to specific hours.

Planning Poker (also called Scrum Poker) is a consensus-based estimation technique using playing cards to size Product Backlog Items. Each participant has a deck of cards with values (typically Fibonacci: 1, 2, 3, 5, 8, 13, 21, ?, ∞, ☕). The process: the Product Owner reads a User Story and answers clarifying questions. All estimators simultaneously reveal their cards (hiding selections until reveal prevents anchoring). When estimates diverge, the highest and lowest estimators explain their reasoning. Discussion reveals different assumptions, leading to a shared understanding. The team re-estimates and converges on a number. The simultaneous reveal prevents anchoring bias (where an early estimate anchors everyone else's thinking). Planning Poker surfaces assumptions, domain knowledge gaps, and technical risk discussions that wouldn't emerge from individual estimates. Tools like PlanningPoker.com, Jira, and Azure DevOps support online Planning Poker for distributed teams.

Agile vs. Waterfall represent fundamentally different philosophies: Waterfall is sequential — Requirements → Design → Implementation → Verification → Maintenance. Each phase completes before the next begins. Requirements are defined upfront and locked. Customer sees the product only at the end. Works well for stable, well-understood requirements (construction, manufacturing). Agile is iterative — requirements, design, and testing happen continuously within each iteration. Customer sees working software every Sprint. Requirements evolve based on feedback. The core difference: Waterfall treats requirements change as failure (controlled via change management); Agile treats requirements change as inevitable and desirable. Waterfall excels for fixed-scope, fixed-price contracts with regulatory requirements (medical devices, aerospace). Agile excels for software products with evolving requirements and available customer collaboration. The choice depends on: requirement stability (Waterfall: stable; Agile: evolving), customer availability, delivery timeline preferences, and team culture.

SAFe (Scaled Agile Framework) is a framework for applying Agile and Lean principles at enterprise scale, coordinating multiple Agile teams working toward a common goal. It operates at four levels: (1) Team level — individual Scrum/Kanban teams working in 2-week Sprints; (2) Program level (ART) — Agile Release Train (ART) aligns 5–12 teams around a Program Backlog, synchronizing via PI Planning (Program Increment planning, a quarterly all-hands event); (3) Large Solution level — for very large solutions requiring multiple ARTs; (4) Portfolio level — strategy and investment funding aligned with enterprise objectives. Key SAFe concepts: PI (Program Increment) — a 10-week development timebox (5 Sprints); IP Sprint — innovation and planning Sprint at end of PI; Inspect & Adapt — quarterly retrospective and problem-solving workshop. SAFe is popular in large enterprises but criticized for being heavyweight and reintroducing waterfall-like planning. Alternatives: LeSS (Large Scale Scrum), Nexus.

The Increment is the sum of all completed Product Backlog Items in a Sprint plus the accumulated value of all previous Sprints. Each Increment must: (1) Be usable — valuable to stakeholders even if the Product Owner doesn't release it; (2) Meet the Definition of Done — fully tested, integrated, and complete according to the team's quality standards; (3) Be additive — it adds to the existing product; (4) Work together with all previous Increments. Multiple Increments may be created during a Sprint. The 2020 Scrum Guide explicitly states that work cannot be considered part of the Increment unless it meets the DoD. The decision to release the Increment is the Product Owner's — the Increment's readiness shouldn't depend on PO permission. The Increment embodies the concept that Scrum's output is a potentially releasable product, not a project phase or report.

Technical debt is the implied cost of future rework arising from choosing a quick/easy solution now instead of the better but slower approach. Ward Cunningham coined the metaphor: like financial debt, small amounts are manageable and sometimes strategic; uncontrolled debt accumulates interest (slower development, more bugs) until it becomes crippling. Types: intentional (deliberate shortcuts to meet a deadline), unintentional (code written without knowledge of best practices), and bit rot (code that worked but degraded as the system evolved). Agile handles technical debt through: (1) Technical backlog items — add debt paydown items to the Product Backlog and prioritize them alongside features; (2) Definition of Done — a strong DoD prevents new debt accumulation; (3) Regular refactoring — Agile principles emphasize continuous attention to technical excellence; (4) Sprint capacity — reserve 10–20% of Sprint capacity for tech debt; (5) Hardening Sprints (controversial) — some teams dedicate full Sprints to tech debt paydown.

The Sprint Goal is the single objective for the Sprint. It is created during Sprint Planning through collaboration between the Product Owner and Developers. The Sprint Goal: (1) Provides focus and flexibility — it's the WHY of the Sprint. Developers can adjust their technical approach within the Sprint to meet it; (2) Is a commitment — the Scrum Team commits to the Sprint Goal, not to completing every Sprint Backlog item; (3) Enables scope negotiation — if something unexpected arises, the team can renegotiate Sprint Backlog scope with the PO as long as the Sprint Goal is not endangered; (4) Cancellation trigger — the Sprint can be cancelled only if the Sprint Goal becomes obsolete; (5) Example: "Enable users to complete checkout with PayPal integration" — specific enough to guide decisions but flexible enough to allow implementation choices. A good Sprint Goal is achievable, valuable, and cohesive — not just "complete these 8 tickets."

Backlog Refinement (previously called "Grooming") is the ongoing activity of decomposing and further defining Product Backlog Items. It ensures that higher-priority items are ready (well-defined, estimated, small enough) before they are selected in Sprint Planning. Activities: adding detail, estimates, and order to items; splitting large items (Epics) into smaller user stories; removing outdated items; reprioritizing based on changing business needs. The Scrum Guide suggests refinement consumes no more than 10% of Developers' capacity. It's not a formal Scrum event with a fixed timebox — it happens as needed, often in a regular weekly session. Who attends: usually the Product Owner (mandatory), interested Developers (often Senior/Tech Lead), and sometimes stakeholders. Outputs: a backlog where the top items are "Ready" for Sprint Planning — well-defined, estimated, and small enough to complete in a Sprint. The term "grooming" was deprecated because it has inappropriate connotations in some cultures.

Acceptance Criteria are specific conditions that a Product Backlog Item must satisfy to be accepted by the Product Owner. They are item-specific and define what "done" means for that particular story. Example for "As a user, I want to filter products by category": (1) Products list updates immediately when a filter is selected; (2) Multiple filters can be applied simultaneously; (3) A "No results" message shows when no products match; (4) Filter selections persist on page refresh. Definition of Done (DoD) applies universally to every Product Backlog Item — it's the quality standard that every increment must meet (code reviewed, tests passed, deployed to staging, etc.). The relationship: an item must satisfy BOTH its acceptance criteria AND the DoD to be considered complete. Acceptance criteria answer "did we build the right thing?"; DoD answers "did we build it right?" A PBI can meet acceptance criteria but fail DoD (e.g., works correctly but has no tests written).

CI/CD are engineering practices that enable Agile's goal of delivering working software frequently. Continuous Integration (CI): developers integrate code changes into a shared repository multiple times daily. Each integration triggers automated builds and tests. Benefits: detect integration conflicts early, reduce "integration hell" at release time, maintain a consistently working codebase. Continuous Delivery (CD): every code change that passes CI is automatically deployed to a staging environment and can be released to production on demand with one click. Continuous Deployment: every passing change is automatically deployed to production without manual intervention. CI/CD supports Agile by enabling: Sprint-end deployments (potentially every 2 weeks), feature flags for incremental rollouts, rapid feedback from production, reduced manual testing burden. Without CI/CD, Agile teams often face a "last mile" problem: code is written Agile but release is Waterfall (a long integration and testing phase at the end). CI/CD removes this bottleneck.

An Epic is a large body of work that cannot be completed in a single Sprint and must be broken down into smaller User Stories. Epics represent significant business objectives or features: "Implement single sign-on (SSO)", "Build mobile app", "Migrate to microservices". They sit above User Stories in the hierarchy: Epic → Feature → User Story → Tasks/Subtasks (this hierarchy varies by tool and framework). Epics help with: (1) Long-range planning — tracking large initiatives across multiple Sprints; (2) Roadmap communication — communicating high-level plans to stakeholders without story-level detail; (3) Progress tracking — seeing how many stories within an Epic are complete. Epics are split into User Stories during Backlog Refinement. A Story is typically small enough to complete in ≤3 days; an Epic may span multiple Sprints. In Jira, Epics are a specific issue type that parent Stories; in SAFe, Epics are portfolio-level work items that span multiple Program Increments.

A Theme is a collection of related User Stories or Epics that share a common business objective, area, or category. Themes are the highest level of the agile work hierarchy (Theme → Epic → Feature → Story). They help organizations organize the Product Backlog by business domain or strategic goal. Examples: "User Experience Improvement" theme (containing Epics for better navigation, search, and checkout); "Performance" theme (Epics for database optimization, CDN implementation, caching). Themes are useful for: (1) Portfolio-level planning — allocating budget and team capacity to different strategic areas; (2) Roadmap communication — showing stakeholders the major areas of investment; (3) Prioritization — ensuring different strategic areas get appropriate attention. Unlike Sprints (timeboxed) and Epics (a specific feature), Themes are open-ended categories that never formally "complete." Not all organizations use Themes — they're a practical planning tool, not a formal Scrum concept.

A Scrum Coach (sometimes synonymous with Agile Coach) works at an organizational level to drive Agile adoption and transformation, whereas a Scrum Master works at the team level. Key differences and responsibilities: (1) Scope — a Scrum Coach works across multiple teams, departments, and leadership levels; (2) Focus — coaching executives on Agile leadership, helping middle management transition from command-and-control to servant leadership, removing organizational impediments that block teams; (3) Skills — requires deep Agile expertise, coaching competencies (ICF or similar), organizational change management, and often experience in multiple frameworks (Scrum, SAFe, LeSS, Kanban); (4) Engagement model — often a temporary role brought in during transformation, then phasing out as capability matures; (5) Metrics — coaches organizational metrics (lead time, delivery frequency, team health) rather than team-level velocity. A Scrum Master can evolve into an Agile Coach through experience and additional coaching training (ICP-ACC, CAC certifications).

Impediments are any obstacles that prevent the Scrum Team from making progress. Managing them effectively is a primary Scrum Master responsibility. Process: (1) Surface — impediments are raised during Daily Scrum, directly to the Scrum Master, or tracked on an impediment board visible to the team; (2) Categorize — team-level (Developers can resolve with Scrum Master support) vs. organizational (require management/stakeholder action); (3) Track — maintain an impediment backlog with owner, date raised, and target resolution date; (4) Escalate — the Scrum Master escalates organizational impediments to the appropriate level (manager, director) with urgency and business impact; (5) Resolve and verify — confirm the impediment is actually removed, not just addressed. Common impediments: unclear requirements (PO availability), environment issues (broken CI/CD), external team dependencies, missing access/permissions, interpersonal conflicts. An effective Scrum Master distinguishes impediments (external blocks) from problems (team-solvable) and handles each appropriately.

Work in Progress (WIP) limits are constraints on the maximum number of items that can be actively in progress simultaneously in each stage of a workflow. They are a core Kanban principle and are also applied in Scrum via Sprint scope. Why WIP limits work: Little's Law states that cycle time = WIP / throughput. Reducing WIP reduces cycle time — items flow faster when the system isn't overloaded. WIP limits: (1) Force collaboration — when a stage is full, upstream workers help unblock items rather than starting new ones; (2) Reveal bottlenecks — if "In Review" hits its limit constantly, it reveals insufficient review capacity; (3) Reduce multitasking — cognitive switching cost from task-switching is eliminated when people focus on fewer items; (4) Improve quality — focused attention produces higher quality work. Setting WIP limits: start with ≥1.5 × team size, then tune based on flow observations. Violating WIP limits should be a conscious team decision, not the norm — it signals a system problem.

A Cumulative Flow Diagram (CFD) is a stacked area chart that shows the number of items in each workflow stage over time. The X-axis is time; the Y-axis is total work items. Each stage is a colored band. The width of any band at a point in time represents the number of items in that stage. The vertical distance between two stages at a point in time represents the amount of WIP between them. Key insights from CFD: (1) Bottlenecks — a widening band indicates work accumulating (too much WIP, capacity constraint); (2) Cycle time — the horizontal distance between when an item enters the first stage and the last stage; (3) Throughput — the slope of the top line (items per time); (4) Ideal flow — smooth, parallel bands with steady slopes. Distortions reveal process problems: steep slopes indicate burst activity, horizontal plateaus indicate stoppage. CFDs are the primary flow metric tool in Kanban and complement burndown charts in Scrum teams using hybrid approaches.

Pair programming is an Extreme Programming (XP) practice where two developers work together at one computer — one "drives" (types code) and one "navigates" (reviews, thinks strategically). They switch roles regularly. Benefits: (1) Higher quality code — continuous review catches bugs immediately; (2) Knowledge transfer — junior/senior pairing builds skills faster than any training; (3) Reduced debugging time — fewer bugs produced means less time fixing later; (4) Better design — two people thinking through design produces better solutions; (5) Onboarding — new team members learn codebase faster through pairing. Relation to Agile: pairs directly embodies Agile values of individuals and interactions, self-organizing teams, and technical excellence. Contrary to intuition, studies show pairing increases productivity (despite using 2 people for one task) because quality improvements and bug reduction more than compensate. Not all tasks benefit equally — repetitive/simple tasks may not need pairing. Mob programming (whole team, one screen) is the extreme extension.

Test-Driven Development (TDD) is a software development practice (from XP) where tests are written before the code they test. The TDD cycle: (1) Red — write a failing test for a small piece of functionality; (2) Green — write the minimum code to make the test pass; (3) Refactor — improve code quality while keeping tests green. TDD in Agile context: (1) Supports Definition of Done — DoD often includes passing unit tests; TDD ensures tests exist; (2) Enables confident refactoring — comprehensive test suite makes Sprint-level refactoring safe; (3) Supports continuous integration — TDD's automated tests enable CI pipelines; (4) Enables sustainable pace — the 8th Agile principle; code with tests is faster to maintain long-term; (5) Living documentation — tests document what the code does. TDD reduces defects by 15-35% and development time by 15-35% (research by Nagappan et al.). Combined with BDD (Behavior-Driven Development) using Gherkin syntax (Given/When/Then), it creates tests readable by non-technical stakeholders.

Scaling Scrum requires coordination mechanisms beyond single-team Scrum. Approaches: (1) Scrum of Scrums (SoS) — representatives from each team (typically Scrum Masters or technical leads) meet 2-3x/week to coordinate, remove cross-team impediments, and manage dependencies. Not a reporting ceremony — a collaborative coordination. (2) Nexus — the official Scrum Guide extension for scaling (3–9 teams). Adds a Nexus Integration Team (NIT), a shared Sprint Backlog, and Nexus-level events that wrap individual team events. (3) LeSS (Large Scale Scrum) — minimal roles and rules; uses feature teams (end-to-end capability teams), one Product Backlog, one Product Owner, multi-team Sprint Planning and Retrospectives. (4) SAFe — adds Program Increment Planning (PI Planning) quarterly events, Release Train Engineers, and a layered hierarchy. (5) Shared Definition of Done — all teams must agree on and meet a shared DoD for integrated increments. Key challenge in all approaches: feature teams (preferred over component teams) reduce coordination overhead by enabling end-to-end delivery without cross-team handoffs.

LeSS (Large Scale Scrum) applies Scrum principles to multiple teams with minimal additional roles and processes, following the Agile principle of maximizing simplicity. LeSS Basic (2–8 teams): one Product Owner, one Product Backlog, one Sprint for all teams, one integrated Increment. LeSS Huge (8+ teams): adds Area Product Owners for areas of the product. LeSS vs. SAFe differences: (1) Complexity — LeSS adds minimal prescriptions (a few additional roles/events); SAFe adds extensive roles, ceremonies, and a layered hierarchy; (2) Philosophy — LeSS pursues organizational simplicity (fewer roles, fewer meetings); SAFe adds structure for enterprise governance; (3) Organizational change — LeSS requires significant organizational change (feature teams, flattened management); SAFe adapts to existing org structure; (4) Adoption difficulty — LeSS demands more fundamental change but produces leaner outcomes; SAFe is easier to "install" over existing structures but may not realize full Agile benefits; (5) Prescription — LeSS is less prescriptive, trusting teams; SAFe provides detailed guidance for every aspect. LeSS is preferred by Agile purists; SAFe by large traditional enterprises transitioning to Agile.

Measuring Agile transformation success requires multi-dimensional metrics: (1) Business outcomes (most important) — revenue impact of delivered features, customer satisfaction (NPS, CSAT), market response time, feature adoption rates. Agile transformation succeeds when business outcomes improve, not when ceremonies are followed; (2) Flow metrics — deployment frequency (DORA), lead time for changes, change failure rate, time to restore service. These measure technical Agile maturity; (3) Team health — psychological safety surveys, team stability (attrition), Spotify-style health check models; (4) Process efficiency — reduction in defect rates, reduction in time from idea to production, reduction in rework; (5) Predictability — forecast accuracy (planned vs. actual delivered story points); (6) Customer collaboration — frequency of stakeholder feedback, product discovery activity. Anti-patterns to avoid: measuring "Agile adoption" by counting ceremonies, measuring velocity as a performance KPI (teams game it), comparing team velocities. The ultimate measure: does the organization deliver more value faster with higher quality and happier people?

Common Agile adoption failures: (1) Cargo Cult Agile — following ceremonies mechanically without understanding principles. Daily Standups become status reports; Sprints become mini-Waterfalls with phases within; (2) Wagile — Waterfall planning (fixed scope, fixed date, fixed team) with Agile reporting (Sprint burndowns). The worst of both worlds; (3) SAFe theater — large PI Planning events with impressive wall coverage but Gantt chart thinking underneath; (4) Product Owner bottleneck — PO unavailable to teams, decisions delayed, backlog not maintained, Sprints miss goals because teams can't get answers; (5) Feature factory — measuring success by features shipped, not outcomes achieved. Teams optimize for velocity, not value; (6) Technical debt accumulation — skipping Definition of Done adherence to "move faster" creates slowing problems; (7) No retrospective action — retrospectives happen but identified improvements are never implemented; (8) Management command-and-control — managers tell Developers what to do rather than enabling self-organization; (9) Unengaged stakeholders — Sprint Reviews with empty rooms; no customer feedback loop; (10) Skipped refinement — Sprint Planning fails because backlog isn't ready, starting Sprints with unclear goals.

Fixed-deadline Agile requires managing the Iron Triangle trade-off (Scope/Quality/Time — fix two, the third is variable): (1) Fix time, flex scope — the Agile approach. Deadline is fixed; the team delivers the most valuable work within that time. Ruthless backlog prioritization ensures the must-haves are done first; nice-to-haves are deferred. Release the best possible product on the fixed date; (2) Release planning — create a release plan by dividing backlog by velocity. If 200 story points remain and velocity is 25/sprint, forecast 8 sprints. Regularly reforecast as velocity stabilizes; (3) MoSCoW prioritization — categorize requirements as Must Have, Should Have, Could Have, Won't Have. Guarantee Must Haves; be clear about what's in the Won't Have category; (4) Early de-risking — tackle risky, high-uncertainty stories first so scope adjustments can be made with maximum time available; (5) Scope negotiation — maintain ongoing conversations with stakeholders about scope vs. deadline tradeoffs. Never promise fixed scope AND fixed date — this is the root cause of Waterfall death marches; (6) Technical quality protection — never sacrifice quality (DoD) to meet deadlines; technical debt compounds interest and makes future sprints slower.

Nexus is the official Scrum.org framework for scaling Scrum to 3–9 teams working on a single product. It adds minimal overhead over standard Scrum: (1) Nexus Integration Team (NIT) — the new accountability: includes a Product Owner (shared), a Scrum Master, and members from Development Teams. Accountable for ensuring Teams integrate their work into a single valuable Increment each Sprint; (2) Nexus Sprint Goal — an overall Sprint objective that all teams contribute to; (3) Extended events — Nexus wraps Scrum's events: Nexus Sprint Planning (overall integration planning), Daily Nexus Scrum (NIT-level coordination of cross-team dependencies), Nexus Sprint Review (all teams demonstrate integrated Increment), Nexus Sprint Retrospective (multi-team retrospective); (4) One Product Backlog — single PO, single ordered backlog for all teams; (5) Integration Increment — all teams integrate their work into one Increment per Sprint. Nexus is leaner than SAFe and more structured than ad-hoc Scrum of Scrums. It preserves Scrum's empirical process and team autonomy while adding just enough coordination structure.

OKRs (Objectives and Key Results) and Agile are complementary: OKRs provide strategic direction and measurable outcomes; Agile provides the delivery framework. Integration approach: (1) Alignment — company OKRs cascade to team OKRs. Team OKRs inform the Product Goal and sprint goals (Sprint Goals should advance Key Results); (2) Quarterly cadence — OKRs typically align with quarters (13 weeks ≈ 6-7 two-week Sprints). PI Planning in SAFe is a natural OKR-to-team alignment moment; (3) Outcome-focused backlog — Product Backlog items should be framed around customer outcomes (Key Results) rather than feature output. "Users complete checkout in <2 minutes" rather than "add one-click checkout button"; (4) Sprint Review alignment — Sprint Reviews evaluate increment value in terms of OKR progress, not just feature demos; (5) Avoiding conflicts — OKRs set the "what" (outcomes); Agile teams determine "how" (implementations). Don't use OKRs to prescribe features — they should prescribe outcomes. Challenge: OKR grading (40-70% achievement is "healthy") conflicts with the Scrum team's commitment to Sprint Goals. Treat Sprint commitments as execution plans for OKR achievement, not independent commitments.

Lean and Agile are closely related philosophies with different origins and emphasis. Lean originated in Toyota's manufacturing (Toyota Production System) in the 1950s, formalized by Womack and Jones in "Lean Thinking" (1996). Core Lean principles: eliminate waste (7 wastes: defects, overproduction, waiting, non-utilized talent, transportation, inventory, motion), amplify learning, decide late (defer decisions to the last responsible moment), deliver fast, empower the team, build integrity in, optimize the whole. Agile originated in software development (Agile Manifesto, 2001). It applies many Lean principles to software: eliminating waste (unnecessary documentation, handoffs), delivering incrementally, empowering teams. Key differences: (1) Origin — Lean: manufacturing; Agile: software; (2) Scope — Lean is a complete business philosophy (extends to finance, HR, supply chain); Agile focuses on software development; (3) Emphasis — Lean: waste elimination and flow efficiency; Agile: iterative delivery and customer collaboration; (4) Frameworks — Lean: Kanban, Value Stream Mapping; Agile: Scrum, XP. Kanban bridges both philosophies — a Lean tool applied in Agile software contexts.

Cross-team dependency management is the biggest challenge in scaled Agile. Approaches: (1) Identify dependencies early — during backlog refinement, tag stories with team dependencies. Use a dependency visualization tool (Jira, Miro dependency boards, or physical big visible charts); (2) Inter-team backlog alignment — teams refine related stories together, ensuring all prerequisites are planned in the same or earlier Sprint; (3) Scrum of Scrums — Scrum Masters or tech leads from dependent teams meet 2-3x/week to surface and resolve cross-team blockers; (4) Feature teams over component teams — redesign teams to be cross-functional end-to-end feature teams rather than component-specialized. Eliminates most dependencies by design; (5) PI Planning (SAFe) — the quarterly event explicitly identifies and risks cross-team dependencies using the Program Board (a physical/digital board showing team tracks and dependency arrows); (6) Architecture runway — invest in shared technical foundations (APIs, shared services) that reduce coupling; (7) Communities of Practice — cross-team technical guilds create consistency in interfaces, reducing integration friction; (8) Kanban + FIFO — dependent teams commit to FIFO processing of cross-team requests to prevent starvation.