Agile & Scrum Interview Guide: Process Questions for Developers

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.

Agile Fundamentals

The Agile Manifesto

Four values that define Agile:

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.

Agile vs 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

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

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.

Sprints and Timeboxing

A sprint is a fixed time period (usually 2 weeks) where the team commits to delivering specific work.

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.

Product Backlog vs 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

Product Backlog              Sprint Backlog
┌──────────────────┐        ┌──────────────────┐
│ 1. User login    │───────>│ User login       │
│ 2. Password reset│───────>│ Password reset   │
│ 3. User profile  │───────>│ User profile     │
│ 4. Settings page │        └──────────────────┘
│ 5. Dark mode     │        (Sprint 1 commitment)
│ 6. Export data   │
│ ...              │
└──────────────────┘

Definition of Done vs 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

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

Daily Standup (Daily Scrum)

Purpose: Synchronize the team and identify blockers.

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

Sprint Review

Purpose: Demo completed work and gather feedback.

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)

Sprint Retrospective

Purpose: Inspect the team's process and identify improvements.

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

Backlog Refinement (Grooming)

Purpose: Prepare upcoming stories for sprint planning.

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

Story Points vs 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.

Planning Poker

How it works:

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

Velocity and Capacity

Velocity: Average points completed per sprint

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

Breaking Down User Stories

INVEST criteria for good stories:

• 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

Kanban Board

┌─────────────┬─────────────┬─────────────┬─────────────┐
│  Backlog    │ In Progress │  Review     │    Done     │
│             │   (WIP: 3)  │  (WIP: 2)   │             │
├─────────────┼─────────────┼─────────────┼─────────────┤
│ ┌─────────┐ │ ┌─────────┐ │ ┌─────────┐ │ ┌─────────┐ │
│ │ Story A │ │ │ Story D │ │ │ Story F │ │ │ Story H │ │
│ └─────────┘ │ └─────────┘ │ └─────────┘ │ └─────────┘ │
│ ┌─────────┐ │ ┌─────────┐ │ ┌─────────┐ │ ┌─────────┐ │
│ │ Story B │ │ │ Story E │ │ │ Story G │ │ │ Story I │ │
│ └─────────┘ │ └─────────┘ │ └─────────┘ │ └─────────┘ │
│ ┌─────────┐ │             │             │             │
│ │ Story C │ │             │             │             │
│ └─────────┘ │             │             │             │
└─────────────┴─────────────┴─────────────┴─────────────┘

WIP Limits

Work In Progress (WIP) limits cap how many items can be in a column.

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

Scrum vs 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

Scrumban

Hybrid approach combining both:

• 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's Role in Agile

Participating Effectively

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

Handling Changing Requirements

Mid-sprint change request:

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

Working with Product Owners

What POs need from developers:

• 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."

Common Anti-Patterns

"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"

Common Interview Questions

"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 handle a blocker?"

Good answer structure:

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."

"What do you do when you finish early?"

Good answer:

"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

This guide connects to the broader interview preparation:

Technical Skills:

• Soft Skills Interview Guide - Communication in teams
• System Design Interview Guide - Architectural discussions

Development Practices:

• Testing Strategies Interview Guide - Testing in Agile
• CI/CD & GitHub Actions Interview Guide - Continuous delivery
• Git Interview Guide - Version control workflow

Final Thoughts

Agile interview questions test your ability to work in a team, not your certification knowledge. Interviewers want to see:

1. Understanding trade-offs: Sprint protection vs flexibility
2. Communication skills: Raising blockers, explaining technical constraints
3. Team orientation: Collaboration over individual heroics
4. Pragmatism: Adapting principles to reality

The best answer to any Agile question starts with "It depends..." followed by the trade-offs you'd consider. That's the Agile mindset.