Nobody is hired for knowing that a sprint retrospective happens at the end of a sprint.
Agile and scrum interviews are unusual in that the correct textbook answer is worth almost nothing — everyone has it, it's in the certification, and the interviewer has heard it forty times. What they're paying for is the thing the textbook can't describe: what you do when the ceremony isn't working, when the team doesn't want it, or when someone senior wants to skip it.
So each group below pairs the questions with the answer that scores nothing and the one that does.
When the ceremonies stop working
- Your standup has turned into a status report to you. What do you do?
- The retrospective produces the same three complaints every time. Now what?
- Sprint planning routinely runs two hours over. How do you fix it?
- A developer says the ceremonies are a waste of time. Respond.
| The answer that scores nothing | What they're listening for |
|---|---|
| "I'd remind the team of the purpose of the standup and facilitate a discussion about its value" | A specific change you made, and whether it worked |
Question 4 is the sorting question. The defensive answer — explaining why the ceremonies matter — is the wrong instinct, because the developer is usually partly right and everyone in the room knows it.
Saying it out loud: "First I'd want to know which ones and why, because 'the ceremonies' usually means one specific meeting that's genuinely bad. When I've had this, it was almost always planning — two hours of people listening to estimates for work they'll never touch. We split it: fifteen minutes with everyone on what the sprint is for, then estimation in smaller groups. Standup stayed because they wanted it once it was five minutes and not aimed at me."
Question 2's strong answer names why the same complaints recur: they're usually about something the team can't fix, so nothing happens, so it comes back. The move is to either escalate it or explicitly take it off the board — "we agreed to stop discussing the release process because none of us control it, and I took it to the platform lead instead."
When the estimates are wrong
- The team consistently commits to more than it finishes. What's happening?
- How do you handle a story that turns out to be three times bigger mid-sprint?
- Someone senior asks why velocity went down. What do you say?
- Do you use story points or hours, and why?
| The answer that scores nothing | What they're listening for |
|---|---|
| "Velocity is a capacity signal, not a performance metric, and shouldn't be compared across teams" | True, and everyone says it. What did you do when someone compared them anyway? |
Question 7 is a political question dressed as a metrics question. The answer they want doesn't lecture:
Saying it out loud: "I'd answer the question before correcting the premise. It went down because two people were on the incident for three days and one story turned out to need a schema change we hadn't seen. Then, if it's a recurring conversation, I'd want to change what we report — velocity invites exactly this question, and 'what shipped and what's blocked' invites a better one."
Question 5's honest answer usually isn't about estimation at all. Teams over-commit because someone rewards commitment, or because unplanned work isn't counted. Naming the unplanned work — "about a third of our capacity was support and we were planning as though it were zero" — is the answer of someone who has actually measured it.
The instinct being tested across this whole group is whether you defend the process or the outcome. A scrum master who protects the ceremony against the team is the failure mode every engineering manager has lived through, and the interview is largely built to detect it. Every strong answer in this section involves changing the process to fit the team — which is, awkwardly for the certification, the actual agile position.
When the roles blur
- The product owner isn't available. How do you run a sprint?
- Who decides what goes into the sprint — you, the PO, or the team?
- A tech lead is assigning work directly to developers. Is that a problem?
- What's the difference between a scrum master and a project manager, in practice?
Question 12 gets asked constantly and the textbook answer — servant leadership, removing impediments, the team is self-organising — is the weakest thing you can say, because it describes an ideal rather than a job.
Saying it out loud: "In practice the difference is what I'm accountable for. A project manager is accountable for the date and will trade scope, people and process to hit it. As a scrum master I'm accountable for the team being able to work — if the date is at risk my job is to make that visible early, not to absorb it by pushing people. In smaller companies I've done both jobs at once, and the honest answer is that they conflict sometimes."
That last clause is what separates a real answer from a memorised one.
Question 11's trap is the word "problem". A tech lead assigning work is sometimes exactly right — a new team, an incident, a piece of work with one obvious owner. The answer that scores names when it's fine and when it isn't, rather than treating self-organisation as a rule.
When someone wants to skip it
- Sales has promised a feature by a date you didn't agree to. What now?
- An executive wants a fixed scope and a fixed date. How do you respond?
- The team wants to drop retrospectives. Do you let them?
- How do you handle work that arrives mid-sprint and can't wait?
Question 14 is the most common real situation in this list and the one where idealism is most costly. "That's not how agile works" is a true sentence that loses you the room and the argument.
Saying it out loud: "I'd take the date seriously, because usually there's a real reason behind it — a contract, a conference, a competitor. What I'd push back on is fixing both. So I'd come back with what we're confident we can have by that date, what's likely, and what definitely isn't — and I'd want to agree in advance what we drop if we're behind at the halfway point, because that decision is much easier to make now than in the last week."
Question 15 has a counterintuitive right answer: often yes, temporarily. A team that hates retrospectives is usually telling you the retrospective isn't producing change. Pausing it and fixing one thing they raised buys more credibility than defending the ceremony.
When it isn't really scrum
- You've joined a team that says it does scrum but doesn't. What do you change first?
- How do you run agile with a team spread across four time zones?
- Kanban or scrum for a team doing mostly support work?
- What part of scrum do you think is overrated?
Question 20 is a trap for the over-certified and a gift to anyone with real experience. Refusing to criticise the framework signals that you've only read about it.
Saying it out loud: "Story point estimation, in a lot of contexts. On a stable team doing similar work it's a useful conversation and a bad number — the value is entirely in the disagreement about sizing, not in the total. I've run teams where we replaced it with counting stories and forecasting from throughput, and the planning got faster and the forecasts got no worse."
Question 17's strong answer starts with what you'd not change. Arriving and reinstating every ceremony in week one is the most common way to lose a team that has already decided the process is theatre.
Correct and forgettable
“The scrum master is a servant leader who facilitates the ceremonies, removes impediments and coaches the team towards self-organisation.”
Word-perfect, and it describes a role rather than a person who has done it. The interviewer's next question will be "tell me about a time that didn't work" — and this answer has given them no material to work with.
A specific team, behaving badly
“Planning was two hours of people listening to estimates for work they'd never touch. We split it. Standup stayed, because once it was five minutes they wanted it.”
One real team, one change, and an outcome including what the team thought. It also quietly demonstrates the thing the role is for: adapting the process to the people rather than the reverse.
What to prepare
Two stories, not twenty answers.
A team you changed something for, including what you tried first that didn't work. Nearly half the questions above can be answered from it.
A time you were overruled — a date imposed, a scope fixed, a ceremony cut by someone above you. What you did next is the answer to most of the "when someone wants to skip it" group, and it's the story that distinguishes people who have held this role in a difficult company from people who have held it in an easy one.
The behavioural half of a delivery interview — the five stories about projects, stakeholders and failure — is a separate set: project manager interview questions. If the loop includes a presentation round, the worked version is here: the project manager interview presentation.
Practical target: answer question 20 out loud — what part of scrum is overrated — and check that your answer contains a specific alternative you have actually used. "Some of it can be dogmatic" is a non-answer. Naming a practice, saying what you replaced it with, and admitting what got worse is the version that makes an interviewer relax, because it's what their own team sounds like.
