27 Agile & Scrum Interview Questions for Developers (2026)

Process questions can catch developers off guard. An interviewer may ask how you respond when scope changes, what the Daily Scrum is for, or whether velocity measures productivity. A strong answer separates the official Scrum framework from practices a particular team has added.

This guide uses the current official Scrum Guide, released in November 2020 and still current in September 2026. It focuses on what a developer needs in day-to-day product work rather than certification trivia.

Table of Contents

1. Agile fundamentals
2. Scrum framework
3. Scrum events
4. Planning and estimation
5. Kanban and flow
6. Developer collaboration
7. Behavioral questions
8. Frequently asked questions

Agile fundamentals

1. What is the Agile Manifesto?

The Manifesto for Agile Software Development expresses four value choices: people and collaboration over process and tools, working software over exhaustive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The items on the right still have value.

Its twelve principles emphasize early and continuous delivery, sustainable work, technical excellence, frequent reflection and adapting to new information. Agile therefore does not mean no plan, no documentation, no architecture or constant unfiltered change. It means using feedback to adjust the way value is delivered.

2. What is the difference between Agile and Waterfall?

“Agile” and “Waterfall” are often used as shorthand, but real delivery systems are more varied than a binary table suggests.

Regulation, contracts and hardware do not automatically require a purely sequential process. Agile delivery also does not remove governance. Choose feedback cadence, evidence, controls and release strategy based on risk, reversibility and product constraints.

3. What is Scrum?

Scrum is a lightweight framework for generating value through adaptive solutions to complex problems. It is based on empiricism—transparency, inspection and adaptation—and the values commitment, focus, openness, respect and courage.

Scrum intentionally does not specify engineering practices, ticket formats, story points, release frequency or tools. Teams add suitable practices while retaining the framework's accountabilities, events and artifacts.

Scrum framework

4. What are the Scrum accountabilities?

The 2020 Scrum Guide describes one Scrum Team with three accountabilities, not three hierarchical roles:

• Product Owner: accountable for maximizing product value and effective Product Backlog management, including communicating the Product Goal and ordering items. The work may be delegated, but accountability remains.
• Scrum Master: accountable for establishing Scrum as defined in the guide and for the Scrum Team's effectiveness. They coach and help cause the removal of impediments; they are not automatically the team's manager or meeting secretary.
• Developers: accountable for creating a usable Increment each Sprint, creating and adapting the Sprint Backlog, instilling quality through the Definition of Done and holding one another accountable as professionals.

The team is cross-functional and self-managing, with no sub-teams or internal hierarchies. The guide says Scrum Teams are typically ten or fewer people; that is guidance, not a staffing formula.

5. What is a Sprint?

A Sprint is a fixed-length event of one month or less that contains all other Scrum events. A new Sprint starts immediately after the previous one. During it:

• no change is made that would endanger the Sprint Goal;
• quality does not decrease;
• the Product Backlog is refined as needed;
• scope may be clarified and renegotiated with the Product Owner as more is learned.

The Sprint Goal creates coherence. Developers forecast the work they believe will achieve it; they do not sign a fixed-scope contract. An Increment may be delivered before the Sprint ends, and the Sprint Review is not a release gate.

6. What are Scrum's artifacts and commitments?

The commitments improve focus and provide a basis for inspection. “Commitment” here does not mean a promise that every initially selected backlog item will be completed regardless of new evidence.

7. What is the difference between Product Backlog and Sprint Backlog?

The Product Backlog is the single source of work undertaken by the Scrum Team. The Product Owner is accountable for its effective management and ordering, while the Scrum Team contributes to refinement.

The Sprint Backlog is a plan by and for the Developers. It contains why the Sprint is valuable (the Sprint Goal), what may be done (selected Product Backlog items) and how the Increment will be created. It is updated throughout the Sprint as more is learned.

flowchart LR
    PG[Product Goal] --> PB[Ordered Product Backlog]
    PB --> SP[Sprint Planning]
    SP --> SG[Sprint Goal]
    SP --> SB[Sprint Backlog: why + what + how]
    SB --> I[Done Increment]
    I --> PG
    DS[Daily Scrum] -->|inspect and adapt| SB

8. How do the Increment, Definition of Done and acceptance criteria differ?

An Increment is a concrete stepping stone toward the Product Goal. It must be usable and meet the Definition of Done. Multiple increments may be created and delivered during a Sprint.

The Definition of Done is the formal, shared quality boundary for the Increment. If the organization has a standard, every Scrum Team must follow it at minimum; teams working on one product must mutually define and comply with the same Definition of Done.

Acceptance criteria are a common optional practice for expressing item-specific examples or conditions. They are not a Scrum artifact or commitment. Meeting them does not override the Definition of Done, and Product Owner sign-off is not automatically part of “Done.” A team may include review, security, documentation or deployment evidence in its Definition of Done when those are genuine product quality measures.

Scrum events

9. What happens in Sprint Planning?

The entire Scrum Team creates the Sprint plan around three topics:

1. Why is this Sprint valuable? The team defines a Sprint Goal.
2. What can be Done this Sprint? Developers select items through discussion with the Product Owner, considering past performance, capacity and the Definition of Done.
3. How will the chosen work get Done? Developers plan enough detail to start creating the Increment.

Sprint Planning is timeboxed to at most eight hours for a one-month Sprint and is usually shorter for shorter Sprints. A realistic forecast accounts for leave, on-call work, dependencies, operational load and uncertainty—not just a velocity number.

10. What should happen in the Daily Scrum?

The Daily Scrum is a 15-minute event for the Developers. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, producing an actionable plan for the next day of work.

The Scrum Guide no longer prescribes “yesterday, today, blockers.” Developers may choose any structure that improves focus and self-management. A useful update might be:

“The payment callback now passes integration tests. Today I will connect it to order completion. The provider timeout threatens the Sprint Goal, so I need someone to pair on the retry boundary after this meeting.”

Detailed problem-solving can continue immediately afterward. Developers may adjust their plan at any time; they do not need to wait for the Daily Scrum to collaborate or raise an impediment.

11. What happens in the Sprint Review?

The Scrum Team and key stakeholders inspect the Sprint outcome and changes in the environment, then collaborate on what to do next. The Product Backlog may be adapted to capture new opportunities.

It is a working session, not merely a demo, status report, acceptance gate or slide presentation. Working product evidence and stakeholder feedback are useful, but the format should serve inspection and adaptation. The maximum timebox is four hours for a one-month Sprint.

12. What happens in the Sprint Retrospective?

The Scrum Team inspects how the Sprint went across people, interactions, process, tools and the Definition of Done. It explores assumptions and causes, then plans changes that improve quality and effectiveness.

The most helpful improvements should be addressed as soon as possible and may be added to the next Sprint Backlog. A useful action has an owner or collaboration model, an observable result and a review point—for example, “For the next Sprint, review work-item age daily and swarm when it exceeds our service-level expectation.” The maximum timebox is three hours for a one-month Sprint.

13. Is Product Backlog refinement a Scrum event?

No. Refinement is an ongoing activity in which Product Backlog items are broken down and further defined with details such as description, order and size. The people doing the work are responsible for sizing; the Product Owner may influence them by explaining trade-offs.

The Scrum Guide prescribes neither a separate “grooming ceremony” nor a fixed percentage or two-hour meeting. A team may schedule refinement when that supports readiness and shared understanding, but should inspect whether the cadence is useful.

14. How do you handle changing requirements during a Sprint?

Start with the Sprint Goal, not a blanket “no changes” rule.

1. Clarify the new information and urgency with the Product Owner.
2. Assess its effect on the Sprint Goal, quality, risk and current plan.
3. Developers and Product Owner renegotiate scope when necessary.
4. Update the Sprint Backlog and communicate material effects.

There is no official rule requiring an equal-sized swap. If the Sprint Goal becomes obsolete, only the Product Owner has authority to cancel the Sprint. Cancellation should be rare because it consumes resources and requires Done work to be reviewed.

Planning and estimation

15. Are story points better than hours?

Neither is required by Scrum, and neither is universally better.

• Hours or days may help with near-term scheduling, operational work or small, understood tasks, but uncertainty makes precise-looking numbers misleading.
• Relative sizing can expose different assumptions about complexity, effort and uncertainty without pretending to predict elapsed time precisely.

Story points are team-defined categories, not a physical unit or a dependable ratio scale. A two-point item is not guaranteed to take exactly twice the effort or time of a one-point item. Estimate only when the decision benefits from the estimate, and compare forecasts with actual outcomes.

16. What are velocity and capacity?

Velocity is a team-created metric commonly calculated from the story points completed under that team's Definition of Done in previous Sprints. Capacity is the availability and constraints of the current Sprint.

Velocity is not part of Scrum and should not become a target. Changing point scales, carrying partial work forward, comparing teams or rewarding higher numbers destroys its informational value. Forecast using a range of relevant history plus capacity, dependencies, risk and work mix. Teams can instead or additionally use throughput, cycle time and probabilistic forecasts.

17. What is Planning Poker?

Planning Poker is an optional collaborative relative-sizing technique:

1. Discuss the item and its acceptance examples or risks.
2. Participants select a size independently.
3. Reveal estimates together to reduce anchoring.
4. Explore the assumptions behind meaningful differences.
5. Re-estimate if a shared size will support a decision.

Consensus is not the real objective; shared understanding is. If discussion reveals an unknown dependency, the best outcome may be a discovery task or smaller item rather than a forced number.

18. How do you split a large backlog item?

Prefer thin, testable vertical slices that provide an observable outcome. Useful split dimensions include:

• a simple workflow before exceptions;
• one user or business rule at a time;
• one data variation or channel;
• one operational capability, such as audit or recovery;
• a walking skeleton before richer behavior.

Avoid defaulting to horizontal “frontend,” “backend” and “database” tickets that cannot independently produce a usable Increment. INVEST is a helpful mnemonic, not a Scrum requirement.

Kanban and flow

19. What is Kanban?

Kanban is a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress-limited pull system. A board alone is only visualization; explicit workflow policies, WIP control and active flow management make it useful.

A Scrum Team may add Kanban practices without changing Scrum's accountabilities, events or artifacts.

flowchart LR
    R[Ready] -->|pull when capacity exists| D[Development]
    D --> V[Verification]
    V --> X[Done]
    D -. WIP limit .-> D
    V -. WIP limit .-> V

20. Why do WIP limits and flow metrics matter?

WIP limits constrain how many work items are started but not finished. When a stage reaches its limit, the policy encourages collaboration to finish or unblock existing work instead of starting more. Limits should be explicit and adapted from evidence, not assigned mechanically per developer.

Four useful flow metrics are:

Use distributions and trends rather than a single average. Different item types may require separate policies or service-level expectations.

21. What is the difference between Scrum and Kanban?

Scrum defines a framework around Sprints, three accountabilities, five events, three artifacts and their commitments. Kanban focuses on flow through a visual, WIP-limited pull system and does not prescribe Scrum's structure.

Do not reduce the choice to “Scrum for product teams, Kanban for support.” Product and operations work can both benefit from feedback loops and flow practices. “Scrumban” is an informal label with no single authoritative definition; explain the actual policies instead. If a team says it uses Scrum with Kanban, Scrum still applies unless it has deliberately chosen a different process.

Developer collaboration

22. How do Developers participate effectively in Scrum?

Developers jointly own the plan for producing a Done Increment. Effective participation includes:

• connecting daily decisions to the Sprint Goal;
• making work, risk and uncertainty transparent;
• collaborating across specialties rather than protecting personal queues;
• maintaining and adapting the Sprint Backlog;
• instilling quality through the Definition of Done;
• asking for help early and helping finish shared work;
• contributing evidence and improvement ideas at reviews and retrospectives.

Scrum does not assign analysis, testing, UX or operations to a separate lower-status group. Anyone creating any aspect of the usable Increment is accountable as a Developer within the Scrum Team.

23. How do you work effectively with a Product Owner?

Respect the Product Owner's accountability for value and ordering while contributing technical, operational and discovery evidence. Explain choices as outcomes and trade-offs:

“Real-time synchronization adds a new failure mode and likely delays the learning we need. A one-hour batch would let us validate demand this Sprint. If the experiment succeeds, we can measure whether lower latency is worth the added complexity.”

Raise risks early, offer options, clarify the Product Goal and acceptance examples, and avoid presenting estimates as certainty. Developers decide how to turn selected work into a Done Increment; the Product Owner does not assign individual tasks.

24. What are common Agile and Scrum anti-patterns?

• treating the Sprint Backlog as an immutable contract;
• using velocity as a target or individual performance score;
• turning the Daily Scrum into a manager status meeting;
• treating the Sprint Review as a release or acceptance gate;
• having a Scrum Master assign tasks or act as the team's manager;
• separating development and testing into sequential mini-waterfalls;
• repeatedly carrying unfinished work without investigating causes;
• lowering the Definition of Done to “finish” more work;
• running events without inspecting evidence or adapting anything;
• calling a task board “Kanban” while allowing unlimited work in progress.

Behavioral questions

25. How do you handle a blocker?

Make the impact visible quickly rather than waiting for a scheduled meeting. Describe the goal at risk, evidence gathered, attempts already made, the decision or expertise needed and a sensible timebox. Swarm or switch only when that improves the team's outcome; starting unrelated work can increase WIP and hide the bottleneck.

A strong interview answer gives a real example and explains the result: whether the team changed scope, removed a dependency, improved an operational policy or learned to detect the problem earlier.

26. How do you answer a question about disagreeing with a product decision?

Use a real, concise situation and show professional disagreement:

• identify the shared product outcome;
• provide technical or user evidence rather than authority;
• state options and their costs, risks and reversibility;
• clarify who owns the decision;
• commit to the chosen path unless it creates an ethical, legal or safety issue;
• explain what the team learned from the outcome.

STAR can organize the answer, but do not invent metrics or present a fictional “80/20” result as personal experience.

27. What should you do when your selected work finishes early?

Optimize for the Sprint Goal and team flow, not personal utilization. Verify the work meets the Definition of Done, respond to review feedback, help finish or unblock active items, review work-item age and then coordinate with the Developers and Product Owner about the next valuable action.

Pulling another Product Backlog item can be appropriate, but it should preserve the Sprint Goal, quality and WIP policy. “My ticket is done” is weaker than “the team produced a usable Increment.”

Quick reference

Shorter Sprints usually use shorter event timeboxes. Product Backlog refinement is an activity, not a sixth Scrum event.

Frequently Asked Questions

What is the difference between Scrum and Kanban?

Scrum is a framework with a Scrum Team, accountabilities, five events and three artifacts, organized around Sprints of one month or less. Kanban is a strategy for optimizing flow through a visual, work-in-progress-limited pull system. They are not mutually exclusive: a Scrum Team can add Kanban practices without replacing Scrum.

What should I say in the Daily Scrum?

There is no mandatory three-question script. Developers choose any structure that helps them inspect progress toward the Sprint Goal and adapt the Sprint Backlog. A useful contribution states what changed, what you will do next, whether the goal is at risk, and what collaboration or help is needed.

Are story points required in Scrum?

No. Scrum does not prescribe story points, hours, Planning Poker or velocity. A team may use relative sizing when it improves shared understanding, but it should validate whether the practice helps forecasting and delivery. Points are team-local planning data, not a productivity score or a valid basis for comparing people or teams.

What is the Definition of Done?

The Definition of Done is a formal description of the state of the Increment when it meets the product's quality measures. Work that does not meet it is not part of the Increment and returns to the Product Backlog. It is broader than story-specific acceptance criteria and does not automatically require Product Owner acceptance or deployment to staging.

Can the Sprint Backlog change during a Sprint?

Yes. The Sprint Backlog is a plan by and for the Developers and is updated throughout the Sprint as more is learned. Scope may be clarified and renegotiated with the Product Owner, provided no change endangers the Sprint Goal and quality does not decrease. Only the Product Owner can cancel a Sprint, when its goal becomes obsolete.

How should velocity be used?

If a team uses story points, its historical completed points can inform a forecast together with current capacity, risk and dependencies. Velocity is not required by Scrum, is not a commitment, and should not be compared across teams or used to evaluate individuals. Forecast ranges and flow data are often safer than a single average.

Related articles

• Soft Skills Interview Guide
• Testing Strategies Interview Guide
• CI/CD and GitHub Actions Interview Guide

Sources

• The Scrum Guide — official current version and translations
• The 2020 Scrum Guide
• Scrum Guide revision history
• Manifesto for Agile Software Development
• Principles behind the Agile Manifesto
• Kanban Guide for Scrum Teams
• Scrum with Kanban: practices and flow metrics