20+ Agile & Scrum Interview Questions 2025: Sprints, Ceremonies & Estimation

Process questions catch many developers off guard. You've spent years mastering React or Node.js, but then an interviewer asks: "How do you handle a situation where requirements change mid-sprint?" or "What's the difference between velocity and capacity?"

This guide covers Agile and Scrum concepts from a developer's perspective—not Scrum Master certification depth, but what you need to work effectively in Agile teams and answer process questions confidently.

Table of Contents

1. Agile Fundamentals Questions
2. Scrum Framework Questions
3. Scrum Ceremonies Questions
4. Estimation & Planning Questions
5. Kanban Essentials Questions
6. Developer Role Questions
7. Behavioral Interview Questions
8. Quick Reference

Agile Fundamentals Questions

What is the Agile Manifesto?

The Agile Manifesto defines four core values that guide software development:

Individuals and interactions    over    processes and tools
Working software                over    comprehensive documentation
Customer collaboration          over    contract negotiation
Responding to change            over    following a plan

The items on the right have value, but Agile prioritizes the items on the left. This isn't about abandoning documentation or planning—it's about recognizing that working software and customer collaboration drive better outcomes than comprehensive upfront specifications.

What is the difference between Agile and Waterfall?

When Waterfall makes sense:

• Fixed requirements (regulatory, contractual)
• Well-understood problem domain
• Hardware/physical products
• Short projects with clear scope

When Agile makes sense:

• Evolving requirements
• Complex problem discovery
• Need for early feedback
• Long-term product development

What are the common Agile frameworks?

Most companies use Scrum or a Scrum-Kanban hybrid. XP practices (TDD, pair programming, CI/CD) are often adopted independently of the framework.

Scrum Framework Questions

These questions test your understanding of Scrum's structure and roles.

What are the three Scrum roles?

Product Owner (PO):

• Owns the product backlog
• Defines priorities and acceptance criteria
• Represents stakeholders and customers
• Decides what to build (not how)
• Available to answer questions

Scrum Master:

• Facilitates ceremonies
• Removes blockers
• Coaches team on Scrum practices
• Protects team from distractions
• Not a manager—a servant leader

Development Team:

• Cross-functional (design, dev, QA)
• Self-organizing
• Commits to sprint work together
• Collectively responsible for delivery
• Typically 3-9 people

Example question: "Who decides what goes into a sprint?"

The Product Owner prioritizes the backlog, but the Development Team decides how much they can commit to. Sprint planning is collaborative—the PO presents priorities, and the team selects what they can realistically complete.

What are sprints and timeboxing?

A sprint is a fixed time period (usually 2 weeks) where the team commits to delivering specific work. Timeboxing is the practice of limiting events and activities to fixed durations, which forces focus and prevents scope creep.

Sprint characteristics:

• Fixed length (1-4 weeks, 2 weeks most common)
• Starts with planning, ends with review and retrospective
• Scope is protected once committed
• Results in potentially shippable increment

Timeboxing: All Scrum events have maximum durations:

Timeboxing forces focus and prevents meetings from expanding indefinitely.

What is the difference between Product Backlog and Sprint Backlog?

Product Backlog:

• All desired work for the product
• Ordered by priority (most valuable at top)
• Owned by Product Owner
• Living document—constantly refined
• Items at top are detailed, bottom items are rough

Sprint Backlog:

• Work committed for current sprint
• Owned by Development Team
• Created during Sprint Planning
• Shouldn't change during sprint
• Includes tasks broken down from stories

flowchart LR
    subgraph PB["Product Backlog"]
        direction TB
        P1["1. User login"]
        P2["2. Password reset"]
        P3["3. User profile"]
        P4["4. Settings page"]
        P5["5. Dark mode"]
        P6["6. Export data"]
    end
 
    subgraph SB["Sprint Backlog"]
        direction TB
        S1["User login"]
        S2["Password reset"]
        S3["User profile"]
        Note["Sprint 1 commitment"]
    end
 
    P1 --> S1
    P2 --> S2
    P3 --> S3
 
    style PB fill:#1e1b4b,stroke:#a855f7,stroke-width:2px
    style SB fill:#1e1b4b,stroke:#a855f7,stroke-width:2px
    style P1 fill:#6366f1,stroke:#a855f7
    style P2 fill:#6366f1,stroke:#a855f7
    style P3 fill:#6366f1,stroke:#a855f7
    style P4 fill:#374151,stroke:#6b7280
    style P5 fill:#374151,stroke:#6b7280
    style P6 fill:#374151,stroke:#6b7280
    style S1 fill:#22c55e,stroke:#16a34a
    style S2 fill:#22c55e,stroke:#16a34a
    style S3 fill:#22c55e,stroke:#16a34a
    style Note fill:#7c3aed,stroke:#a855f7

What is the difference between Definition of Done and Acceptance Criteria?

Acceptance Criteria (AC):

• Specific to each story
• Defines what the feature must do
• Written by Product Owner
• Example: "User can reset password via email link"

Definition of Done (DoD):

• Applies to ALL stories
• Defines quality standards
• Agreed by whole team
• Example checklist:

□ Code reviewed and approved
□ Unit tests written and passing
□ Integration tests passing
□ No known bugs
□ Documentation updated
□ Deployed to staging
□ Accepted by Product Owner

Example question: "A story meets all acceptance criteria but tests are failing. Is it done?"

No. The Definition of Done must also be satisfied. AC defines what the feature does; DoD defines how well it's built. Both must be met before a story is considered complete.

Scrum Ceremonies Questions

These questions test your understanding of Scrum events and how to participate effectively.

What happens in Sprint Planning?

Purpose: Decide what to build this sprint and how.

Participants: Whole Scrum team

Outcome:

• Sprint goal (one sentence describing the sprint's purpose)
• Sprint backlog (committed stories)
• Initial task breakdown

Two parts:

1. What: PO presents top backlog items, team asks questions, team selects what they can commit to

2. How: Team breaks stories into tasks, identifies dependencies, raises concerns

Tips for developers:

• Ask clarifying questions—unclear requirements cause delays
• Be realistic about capacity (vacation, meetings, on-call)
• Speak up if something seems too big or risky
• Don't commit to more than your velocity

What should you say in daily standup?

The daily standup (or daily scrum) synchronizes the team and surfaces blockers. Keep it focused and under 15 minutes.

Format: Each person answers three questions:

1. What did I complete yesterday?
2. What will I work on today?
3. What's blocking me?

Duration: 15 minutes maximum

Good standup:

"Yesterday I finished the login API and opened a PR.
Today I'll start on password reset after the PR is reviewed.
No blockers."

Bad standup:

"So yesterday I was looking at the code and I found this
interesting bug where the database connection was timing out,
and I spent like 3 hours debugging it, and then I realized..."
(5 minutes later, still talking)

What NOT to do:

• Give status reports to managers
• Discuss implementation details (take it offline)
• Problem-solve during standup
• Skip mentioning blockers to look good

Handling blockers:

• Say it clearly: "I'm blocked on X"
• Ask for specific help: "I need 30 minutes with someone who knows the auth system"
• Follow up immediately after standup

What happens in Sprint Review?

Sprint Review is where the team demos completed work and gathers feedback from stakeholders. It's not a status meeting—it's a working session focused on the product increment.

Participants: Scrum team + stakeholders

Format:

• Team demos completed stories
• Stakeholders ask questions and provide feedback
• PO updates backlog based on feedback
• NOT a status meeting—it's a working session

For developers:

• Demo your own work
• Show working software, not slides
• Be prepared for questions about trade-offs
• Listen to stakeholder feedback (they're your users)

What is a Sprint Retrospective?

The Sprint Retrospective is where the team inspects their process and identifies improvements. It's the most important ceremony for continuous improvement—without it, teams repeat the same mistakes.

Participants: Scrum team only (no stakeholders)

Common format:

• What went well? (Keep doing)
• What didn't go well? (Stop doing)
• What should we try? (Start doing)

Example action items:

• "We'll limit WIP to 2 items per developer"
• "We'll do code reviews within 24 hours"
• "We'll add a 'ready for dev' column to our board"

For developers:

• Be honest but constructive
• Focus on process, not people
• Suggest specific improvements
• Follow through on action items

What is Backlog Refinement?

Backlog Refinement (formerly called grooming) prepares upcoming stories for sprint planning. Well-refined stories lead to smoother planning sessions and fewer surprises during development.

Activities:

• Break large stories into smaller ones
• Add acceptance criteria
• Estimate story points
• Identify dependencies and risks
• Remove ambiguity

Timing: Usually mid-sprint, 1-2 hours

Why it matters: Well-refined stories lead to smoother sprint planning and fewer surprises during development.

Estimation & Planning Questions

These questions test your understanding of Agile estimation techniques.

What is the difference between story points and hours?

Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21...

Teams use Fibonacci because it forces acknowledging uncertainty. The difference between 5 and 8 is meaningful; the difference between 5 and 6 is false precision.

Example question: "How do you estimate a story you've never done before?"

Compare it to stories you have done. "This feels similar to the payment integration we did—that was a 5. But this has more unknowns, so maybe an 8." Points are relative, not absolute.

What is Planning Poker?

Planning Poker is a consensus-based estimation technique where team members independently estimate story points, then reveal their estimates simultaneously to avoid anchoring bias.

1. PO describes a story
2. Team asks clarifying questions
3. Everyone privately selects a point value
4. Cards revealed simultaneously
5. Discuss outliers (why did you say 2? why 13?)
6. Re-vote if needed until consensus

Why simultaneous reveal: Prevents anchoring bias. If a senior dev says "3" first, others might just agree.

What to do with outliers:

• High estimate might see risks others missed
• Low estimate might know a shortcut
• Discussion reveals assumptions

What is velocity and how is it used?

Velocity is the average number of story points a team completes per sprint, calculated from recent sprints (typically the last 3-5). It's used for sprint planning and forecasting, but should never be used as a performance metric.

Sprint 1: 23 points
Sprint 2: 28 points
Sprint 3: 25 points
Sprint 4: 26 points
────────────────────
Average velocity: ~25 points/sprint

Capacity: Available effort this specific sprint

Capacity varies based on:

• Team member vacations
• Holidays
• Planned meetings/training
• On-call rotations

Using velocity:

• Don't commit to more than your velocity
• Use for forecasting: "At 25 points/sprint, 100-point epic takes ~4 sprints"
• Track trends, not individual sprints

Velocity anti-patterns:

• Comparing velocity across teams
• Using velocity as a performance metric
• Inflating points to look productive
• Pressure to increase velocity sprint-over-sprint

How do you break down user stories?

Breaking large stories into smaller, manageable pieces is essential for accurate estimation and smooth sprint execution. The INVEST criteria define what makes a good user story.

• Independent: Can be developed alone
• Negotiable: Details can be discussed
• Valuable: Delivers user/business value
• Estimable: Team can estimate it
• Small: Fits in a sprint
• Testable: Has clear acceptance criteria

Story too big? Split it:

Original: "User can manage their profile"

Split into:
- User can view their profile
- User can edit their name
- User can change their email
- User can upload a profile photo
- User can delete their account

Splitting techniques:

• By workflow step
• By data variations
• By business rules
• By interface (API, UI, mobile)
• By happy path vs error cases

Kanban Essentials Questions

These questions test your understanding of Kanban and how it compares to Scrum.

What is a Kanban board?

A Kanban board is a visual workflow management tool that shows work items moving through stages from left to right. Each column represents a workflow stage, and cards move through columns as work progresses.

flowchart LR
    subgraph Backlog["Backlog"]
        direction TB
        A["Story A"]
        B["Story B"]
        C["Story C"]
    end
 
    subgraph InProgress["In Progress (WIP: 3)"]
        direction TB
        D["Story D"]
        E["Story E"]
    end
 
    subgraph Review["Review (WIP: 2)"]
        direction TB
        F["Story F"]
        G["Story G"]
    end
 
    subgraph Done["Done"]
        direction TB
        H["Story H"]
        I["Story I"]
    end
 
    Backlog --> InProgress --> Review --> Done
 
    style Backlog fill:#1e1b4b,stroke:#a855f7,stroke-width:2px
    style InProgress fill:#1e1b4b,stroke:#f59e0b,stroke-width:2px
    style Review fill:#1e1b4b,stroke:#3b82f6,stroke-width:2px
    style Done fill:#1e1b4b,stroke:#22c55e,stroke-width:2px
    style A fill:#6366f1,stroke:#a855f7
    style B fill:#6366f1,stroke:#a855f7
    style C fill:#6366f1,stroke:#a855f7
    style D fill:#f59e0b,stroke:#d97706
    style E fill:#f59e0b,stroke:#d97706
    style F fill:#3b82f6,stroke:#2563eb
    style G fill:#3b82f6,stroke:#2563eb
    style H fill:#22c55e,stroke:#16a34a
    style I fill:#22c55e,stroke:#16a34a

What are WIP limits and why do they matter?

Work In Progress (WIP) limits cap how many items can be in a column at any time. They're the key mechanism that makes Kanban work—without WIP limits, you just have a task board.

Why WIP limits matter:

• Prevent context switching
• Surface bottlenecks
• Force completion over starting
• Improve flow and cycle time

Example: If "In Progress" has WIP limit of 3 and already has 3 items, you must finish something before starting new work.

What happens without WIP limits:

Everyone starts new work → Everything is "in progress" →
Nothing gets finished → Deadlines missed → Panic

What is the difference between Scrum and Kanban?

When to use Kanban:

• Support/maintenance work (unpredictable)
• Ops teams with interruptions
• Teams with varying priorities
• When sprints feel artificial

When to use Scrum:

• Product development
• Need for predictable delivery
• Stakeholders want regular demos
• Team benefits from rhythm

What is Scrumban?

Scrumban is a hybrid approach that combines elements of both Scrum and Kanban:

• Keep sprints for planning and retrospectives
• Use Kanban board with WIP limits
• Pull work continuously within sprint
• No sprint commitment—flow-based

Works well for teams transitioning or with mixed work types.

Developer Role Questions

These questions test how you participate in Agile teams as a developer.

How do developers participate effectively in Agile ceremonies?

In Sprint Planning:

• Ask questions until requirements are clear
• Raise concerns about technical risks
• Be realistic about your capacity
• Help break down stories into tasks

In Standups:

• Be brief and focused
• Raise blockers immediately
• Offer help to blocked teammates
• Update board before standup

In Retrospectives:

• Share honest feedback
• Suggest concrete improvements
• Commit to action items
• Follow through on commitments

How do you handle changing requirements mid-sprint?

Mid-sprint scope changes are one of the most common challenges in Agile development. How you handle them reveals your understanding of Agile principles and communication skills.

Stakeholder: "Can we add feature X to this sprint?"

Bad response: "No, we're doing Scrum."

Good response: "We're committed to the current sprint goal.
Let's add it to the backlog for next sprint. If it's urgent,
we can discuss with the PO about swapping something out—
what would you deprioritize?"

Key principles:

• Sprint scope is protected, not sacred
• Trade-offs must be explicit
• PO makes priority decisions
• Team makes capacity decisions

How do you work effectively with Product Owners?

The developer-PO relationship is critical to Agile success. Understanding what POs need helps you collaborate more effectively and influence product decisions.

• Technical feasibility input
• Honest estimates
• Early warning about problems
• Suggestions for simpler alternatives
• Proactive communication

Building a good relationship:

• Understand their pressures (stakeholders, deadlines)
• Explain technical trade-offs in business terms
• Propose solutions, not just problems
• Respect their priority decisions

Example conversation:

Developer: "This feature as specced will take 3 weeks because
of the legacy system integration. But if we skip real-time
sync and do hourly batch updates, we could ship in 1 week.
Would that work for the MVP?"

PO: "Let me check with stakeholders—that might be fine for launch."

What are common Agile anti-patterns?

Recognizing anti-patterns helps you identify dysfunction in teams and avoid common pitfalls. Interviewers often ask about these to gauge your real-world experience.

"Scrummerfall":

• Waterfall in sprint-length chunks
• Big upfront planning, then sprints as deadlines
• No real adaptation or feedback

"Sprint 0 Forever":

• Endless preparation before "real" work
• Architecture, setup, infrastructure... never delivering value

"Estimation Theater":

• Points used to measure developer performance
• Pressure to inflate estimates
• Points become political, not useful

"Standup Status Report":

• Reporting to managers, not syncing with team
• 30+ minute "standups"
• No one listening to each other

"Fake Agile":

• Ceremonies without principles
• No working software each sprint
• No adaptation based on feedback
• "We're Agile because we have a Kanban board"

Behavioral Interview Questions

These are situational questions that test how you apply Agile principles in real scenarios.

How do you answer "Tell me about a time you disagreed with a product decision"?

Structure your answer (STAR):

Situation: "Our PO wanted to add a complex feature mid-sprint
that would require rewriting our authentication system."

Task: "I needed to explain the technical implications without
just saying no."

Action: "I walked through the dependencies and showed it would
delay three other committed features. I proposed an alternative—
a simpler version that met 80% of the need with 20% of the effort."

Result: "The PO appreciated the options and chose the simpler
version. We shipped it that sprint and queued the full version
for later, which we ultimately never needed."

How do you answer "How do you handle a blocker"?

When interviewers ask about handling blockers, they want to see proactive communication and problem-solving skills.

1. Identify and communicate immediately
2. Don't wait for standup if urgent
3. Be specific about what you need
4. Propose solutions if possible
5. Escalate appropriately if unresolved

"When I'm blocked, I first try to solve it myself for a
timeboxed period—maybe 30 minutes. If I can't, I immediately
reach out to whoever can help, either on Slack or by walking
over. I state clearly what I've tried and what I specifically
need. If it's a longer-term block, I raise it in standup and
work on something else while it's being resolved. I don't let
blockers sit silently."

How do you answer "What do you do when you finish early"?

This question tests your initiative and team-first mindset. A good answer shows you think about the team's success, not just your own tasks.

"First, I check if my PR needs any follow-up from review
comments. Then I look at the sprint board—is anyone blocked
where I could help? Any PRs waiting for review? If not, I pull
the next highest priority item. I wouldn't start something
outside the sprint scope without checking with the team. If
the sprint is truly done early, we might pull from the backlog
or use time for tech debt or learning."

Quick Reference

Scrum Events Cheat Sheet

Estimation Reference

Key Terms

Related Articles

• Soft Skills Interview Guide - Communication in teams
• System Design Interview Guide - Architectural discussions
• Testing Strategies Interview Guide - Testing in Agile
• CI/CD & GitHub Actions Interview Guide - Continuous delivery
• Git Interview Guide - Version control workflow