Agile Interview Questions

Agile methodology questions are among the most commonly asked in software engineering interviews. Interviewers assess both theoretical understanding and practical experience with Agile practices. This guide covers questions ranging from fundamental concepts to advanced scenarios that test your ability to apply Agile thinking in real-world situations.

Fundamental Agile Questions

Q: What is Agile methodology and what problem does it solve?

A: Agile is an iterative, incremental approach to software development that prioritizes collaboration, working software, customer feedback, and adaptability. It solves the fundamental problem of traditional development where requirements change during long development cycles, resulting in software that no longer meets user needs by the time it is delivered. Agile addresses this through short iterations with continuous feedback, enabling course correction throughout the project.

Q: Explain the four values of the Agile Manifesto.

A: The Agile Manifesto values: (1) Individuals and interactions over processes and tools — talented, communicating people matter more than rigid processes. (2) Working software over comprehensive documentation — functioning code is the primary measure of progress. (3) Customer collaboration over contract negotiation — ongoing partnership with customers produces better outcomes than adversarial contracting. (4) Responding to change over following a plan — adaptability to new information trumps blind adherence to outdated plans. These values do not reject the items on the right but prioritize the items on the left.

Q: What is the difference between Agile and Scrum?

A: Agile is a philosophy and set of values/principles for software development. Scrum is a specific framework that implements Agile principles through defined roles (Product Owner, Scrum Master, Development Team), events (Sprint Planning, Daily Scrum, Sprint Review, Retrospective), and artifacts (Product Backlog, Sprint Backlog, Increment). Other Agile frameworks include Kanban, XP, and Lean. Scrum is the most popular implementation, but Agile is broader.

Scrum-Specific Questions

Q: What are the responsibilities of a Scrum Master?

A: The Scrum Master serves as a servant-leader responsible for: ensuring the team understands and practices Scrum correctly, facilitating Scrum events, removing impediments that block the team's progress, coaching the team on self-organization, shielding the team from external disruptions, helping the Product Owner maintain an effective backlog, and facilitating organizational Agile adoption. They are not a project manager — they do not assign tasks or make technical decisions.

Q: What happens if the team cannot complete all sprint backlog items?

A: Incomplete items return to the Product Backlog for reprioritization by the Product Owner. The sprint is never extended. The team should discuss during the retrospective why completion was not achieved — was the estimate wrong, were there unexpected impediments, or was the scope insufficiently understood? Consistent failure to meet commitments indicates a systemic issue requiring adjustment to velocity expectations or refinement practices.

Q: How do you handle scope creep during a sprint?

A: Within a sprint, the scope is protected. New requests go to the Product Backlog for prioritization in future sprints. If a genuinely critical issue emerges (production outage), the Product Owner may negotiate with the team to exchange items — removing planned work of equivalent size to accommodate the urgent item. Only the Product Owner can cancel a sprint entirely if the sprint goal becomes obsolete.

Estimation and Planning Questions

Q: What are story points and why use them instead of hours?

A: Story points measure relative complexity, effort, and uncertainty rather than absolute time. A 5-point story is roughly 2.5 times the effort of a 2-point story. Advantages over hours: they remain consistent as team composition changes, they account for uncertainty naturally (larger numbers in Fibonacci reflect greater unknowns), they prevent micromanagement of individual developer time, and they focus discussions on complexity rather than developer speed.

Q: Explain Planning Poker.

A: Planning Poker is a consensus-based estimation technique. Each team member holds numbered cards. For each story: the Product Owner explains the requirement, the team discusses and asks questions, each member privately selects a card representing their estimate, all cards reveal simultaneously, outliers explain their reasoning, and the team discusses until reaching consensus. Simultaneous reveal prevents anchoring bias where early estimates influence others.

Q: What is velocity and how is it used?

A: Velocity is the average number of story points completed per sprint, typically calculated from the last three to five sprints. It serves as a capacity planning tool — the team plans to complete approximately their average velocity in the next sprint. Velocity should not be used to compare teams (different teams calibrate points differently) or as a performance metric (this incentivizes gaming rather than delivery).

Advanced Scenario Questions

Q: How would you introduce Agile to a team accustomed to Waterfall?

A: Start with education about Agile values and the problems it solves. Begin with a pilot project rather than organization-wide transformation. Introduce practices incrementally — start with daily standups and iterative delivery before adding the full Scrum framework. Identify champions within the team who are enthusiastic. Celebrate early wins to build momentum. Address fears directly — Agile does not mean no planning or no documentation. Expect the first few sprints to be rough as the team calibrates.

Q: A stakeholder insists on a detailed 12-month project plan. How do you reconcile this with Agile?

A: Acknowledge their need for predictability while explaining Agile's approach to planning. Provide a product roadmap showing quarterly goals and themes without committing to specific features on specific dates. For the immediate quarter, provide more detail. Explain that Agile planning happens at multiple horizons: release planning (quarterly), sprint planning (every two weeks), and daily planning. Show data from similar projects demonstrating that Agile delivers more value over time because of adaptability, even though individual feature timelines are less predictable.

Q: How do you measure Agile team performance?

A: Focus on outcome metrics rather than output metrics. Valuable measures include: customer satisfaction and NPS scores, lead time from idea to production, deployment frequency, change failure rate, time to recover from incidents (the four DORA metrics), predictability (planned vs. delivered per sprint), and quality metrics (defect escape rate, production incidents). Avoid measuring individual developer productivity — this undermines collaboration and team dynamics.

Q: What are common reasons Agile transformations fail?

A: Common failure modes include: lack of management commitment (mandating Agile without changing organizational structure or incentives), doing "Agile in name only" (renaming meetings without changing practices), not providing coaching and training, maintaining traditional project management alongside Scrum (dual reporting), ignoring technical practices (Agile without automated testing and CI/CD), and failing to adjust organizational culture (silos, blame culture, rigid hierarchies remain unchanged).

Kanban Questions

Q: When would you choose Kanban over Scrum?

A: Choose Kanban when: work is highly variable and unpredictable (support teams, operations), the team handles mixed work types with different urgencies, fixed sprint commitments are impractical due to frequent interruptions, or you want to improve an existing process without wholesale change. Scrum is better for dedicated product teams with predictable capacity and the ability to commit to sprint goals.

Q: What are WIP limits and why are they important?

A: Work-In-Progress limits cap the number of items allowed in each workflow stage simultaneously. They prevent overloading (reducing context-switching waste), create a pull system (work moves when capacity exists), expose bottlenecks (stages that are always at limit need attention), and ultimately reduce lead time by ensuring items flow through rather than accumulating in queues.