All jobs / Project / delivery manager
Agile interview questions
Agile questions a Project / delivery manager can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What is the daily for, in a room like this?
The strongest answer: For the team to see the board, name blockers, and decide the next slice — not a status report to me or the manager
Why it works: Exactly. The daily is the team’s. Status theatre is a different meeting.
- The daily is for the team.
- Name blockers, not biographies.
- Look at the board together.
- Do not turn it into a report to you.
The board is at the WIP limit and someone wants to start a “quick” extra ticket. What do you do?
The strongest answer: We finish or we swarm the stuck work — we do not start the extra because it is small
Why it works: Exactly. A limit that yields to “quick” is not a limit. Finish or help.
- Stop starting.
- Finish or swarm.
- Do not raise the limit for comfort.
- Do not hide the extra ticket.
What makes a retrospective worth the hour?
The strongest answer: One change we will actually try, with a name on it — not a mural of stickies we never reopen
Why it works: Exactly. A retro that does not change the work is a ceremony. One owned experiment is the job.
- Leave with one owned change.
- Speaking is not the outcome.
- Do not collect unowned “shoulds.”
- Do not skip because it feels familiar.
The sprint backlog is a list of twenty tickets and no sentence at the top. What is missing?
The strongest answer: A goal — the one outcome we would still protect if we had to drop work — not a shopping list we pretend is a plan
Why it works: Exactly. A goal is what you protect. A list is inventory.
- Write one protectable outcome.
- The list is not the goal.
- Drop work against the goal, not at random.
- Do not confuse “all tickets done” with aim.
What is the sprint review for?
The strongest answer: For the team and stakeholders to inspect the increment together and adapt the product backlog — a working session that changes what comes next, not a sign-off gate
Why it works: Exactly — the Scrum Guide frames it as inspecting the outcome and deciding future adaptations; the backlog should look different afterwards.
- Inspect, then adapt the backlog.
- Show working product, not slides.
- Invite the stakeholders who decide.
- Leave with backlog changes.
In the daily someone says “no blockers, just busy.” What do you listen for?
The strongest answer: Whether “busy” is three tickets in progress, a wait they have not named, or actual flow — busy is not a status
Why it works: Exactly. Busy hides WIP and waits. Ask what is in progress and what is waiting.
- Unpack “busy.”
- Count what is in progress.
- Name the wait if there is one.
- Do not treat busy as healthy.
A manager wants you to assign the next five tickets so nobody is idle. Strongest reply?
The strongest answer: We pull the next ready slice when a person has capacity — assigning a pile creates hidden WIP and fake idleness
Why it works: Exactly. Pull when there is capacity. A pile of assignments is push.
- Pull against capacity.
- Do not assign a pile.
- Idle can be healthy if WIP is honest.
- Explain pull; do not hide from the manager.
The team wants to “do the whole feature in one go” so users are not confused. What do you push for?
The strongest answer: A thin slice a user can complete — confusion is a design problem, not a reason to sit on a batch for weeks
Why it works: Exactly. A completable slice. Batching “for clarity” is how you learn late.
- Ship a completable thin slice.
- Confusion is design, not a batch excuse.
- Flags need a learning plan.
- Do not confuse deploy theatre with a slice.
A refinement has run long and people are arguing a design that is not this slice. What do you do?
The strongest answer: I time-box the leftover, park the design, and end on what we can play this slice — I do not “just another twenty minutes”
Why it works: Exactly. Time-boxes protect energy. Park what is not this slice.
- Honor the time-box.
- Park off-slice design.
- Leave with playable work.
- Do not end refinement as a habit.
In Scrum, who decides what the team works on next, and who decides how much fits in a sprint?
The strongest answer: The product owner orders the product backlog, so what comes next is theirs; the developers decide how much they can take on and how — the scrum master owns neither, they serve the process
Why it works: Right — ordering belongs to the product owner, sizing the sprint to the developers, and the scrum master is accountable for the team’s effectiveness with Scrum.
- PO orders, developers size.
- Product owner: what comes next.
- Developers: how much and how.
- Scrum master: the process, not the plan.
What is “ready” for in this interview?
The strongest answer: A short conversation that the slice is understood, sized enough to start, and unblocked — not a checklist used to refuse work
Why it works: Exactly. Ready is a talk: understood, startable, unblocked. A weaponized checklist is a delay.
- Ready = understood and startable.
- Talk first; template second.
- Ready is not a freeze.
- Do not wait for every signature.
The sprint felt busy. Someone suggests skipping the retro “just this once.” What do you do?
The strongest answer: We keep a short retro and pick one change — busy is the reason to look, not the reason to skip
Why it works: Exactly. Busy is the input. A short, owned change still counts.
- Keep a short retro.
- Busy is a reason to look.
- Do not donate the hour to planning.
- Do not hide it in a survey.
Two tickets are almost done and someone wants to start a third. Strongest call?
The strongest answer: Finish the two — starting the third raises WIP and makes “almost done” last another week
Why it works: Exactly. Finish. “Almost done” plus a new start is how nothing lands.
- Finish before start.
- Swarm the almost-done.
- Do not start to kill idle.
- Do not fake-close cards.
A new product owner asks you what the three Scrum artefacts are actually for.
What do you tell them?
The strongest answer: Each artefact carries a commitment — product backlog: the product goal; sprint backlog: the sprint goal; increment: the Definition of Done — and the commitment is what makes each one inspectable
Why it works: Exactly — the 2020 Scrum Guide pairs each artefact with a commitment; without the goal or the DoD you cannot judge the artefact.
- Artefact plus commitment.
- Product backlog — product goal.
- Sprint backlog — sprint goal.
- Increment — Definition of Done.
Last retro’s action never appeared on the board and nobody mentions it. What do you do?
The strongest answer: I put it on the board as work, I ask what blocked it, and I do not add three new actions on top
Why it works: Exactly. Make the last change visible. Learn why it died. Do not pile new wishes.
- Last action goes on the board.
- Ask what blocked it.
- Do not pile new actions.
- Do not blame in the room.
Mid-sprint the goal is at risk. People want to add “just one more” ticket that is not the goal. What do you do?
The strongest answer: We protect the goal — we drop or stop the extra and we tell stakeholders the goal is at risk, we do not quietly widen the sprint
Why it works: Exactly. Protect the goal. Say the risk. Do not widen in silence.
- Protect the goal.
- Say the risk now.
- Do not extend the sprint quietly.
- Do not add “just one more.”
A team does interrupt-driven production support and a forced two-week sprint. What is your judgement?
The strongest answer: Kanban with explicit policies and WIP may fit this flow better than a sprint that keeps failing — I do not recite Scrum as the only adult method
Why it works: Exactly. Method follows the work. Forcing a sprint onto interrupts is ceremony, not judgement.
- Match the method to the flow.
- Interrupts plus a failing sprint is a smell.
- Do not “Scrum harder” as the fix.
- Do not hide interrupts in spikes.
The team spans eight time zones. A single daily forces two people to join at midnight. What do you do?
The strongest answer: I design an async board update plus a shorter overlap for blockers — I do not keep a midnight ceremony to say we “have a daily”
Why it works: Exactly. Remote facilitation is design: async for status, overlap for stuck. Ceremony at midnight is not Scrum.
- Async for the update.
- Overlap for blockers.
- Do not keep midnight ceremony.
- Do not rotate pain as fairness.
A director says the WIP limit is “slowing us down” and asks you to lift it for the quarter. Strongest reply?
The strongest answer: I show what is already in progress and what is waiting — I offer to finish or drop work, I do not lift the limit so we can start more
Why it works: Exactly. Show the in-progress and the waits. Finish or drop. Lifting is how you get slower.
- Show current WIP and waits.
- Offer finish or drop.
- Do not lift to look faster.
- Explain; do not preach sacred.
On a Kanban board, a stakeholder wants every ticket treated as “expedite.” What do you do?
The strongest answer: I explain that expedite is a rare class — if everything is expedite, nothing is — and I ask which one item truly interrupts
Why it works: Exactly. Classes of service only work if expedite is scarce. Everything-urgent is no system.
- Expedite is rare.
- Ask which one item interrupts.
- Do not mark everything urgent.
- Do not hide a second lane.
A team wants to move from two-week to four-week sprints “so we can finally finish things.”
What is your judgement?
The strongest answer: Longer sprints delay feedback and grow the batch; I first ask why two weeks feels short — items too big, a heavy DoD, mid-sprint interrupts — and fix that before touching the length
Why it works: Right — carry-over is a symptom of slicing or interrupts; a longer timebox hides it and halves the number of chances to inspect.
- Diagnose before lengthening.
- Check slicing and the DoD.
- Check mid-sprint interrupts.
- Shorter feedback beats bigger batches.
The same “handoffs hurt us” sticky appears in four retros. What does a senior retro do?
The strongest answer: It changes a policy — who may start, how WIP is shared, or how we hand off — and we check that change next time, we do not add a fifth sticky
Why it works: Exactly. A repeating sticky is a policy problem. Change the rule and inspect it.
- Change a policy, not a sticky.
- Inspect the change next retro.
- Do not hide in a document.
- Do not stop at naming the other team.
A Kanban team still runs a two-hour “sprint planning” that assigns two weeks of work. What do you change?
The strongest answer: I move to a shorter replenishment against the WIP and the ready column — we pull when there is a slot, we do not assign a fortnight
Why it works: Exactly. Replenish against WIP. A fortnight assignment is a sprint wearing Kanban labels.
- Replenish against WIP.
- Pull when there is a slot.
- Do not assign a fortnight.
- Keep a short ready conversation.
Leadership wants every team on the same two-week Scrum “for alignment.” One team is a flow-of-requests desk. Your judgement?
The strongest answer: Alignment is shared language and visible work, not the same ceremony — I offer Kanban with the same board truths, I do not force a failing sprint
Why it works: Exactly. Alignment is honesty, not identical rituals. Method follows the work.
- Match method to flow.
- Share board truths, not identical ceremonies.
- Do not fake a sprint report.
- Do not exile the flow team.
The board has columns but no policies on when a card may move. What do you add?
The strongest answer: Explicit exit rules — what “ready,” “in progress,” and “done” require — so WIP and forecasts mean the same thing to everyone
Why it works: Exactly. Policies make the board a system. Extra columns without rules are furniture.
- Write exit rules on the board.
- Ready, in progress, and done must mean one thing.
- Do not add columns instead of policies.
- Do not replace rules with screenshots.
A new CTO asks you to “standardise on Scrum” across twenty teams. Strongest first page?
The strongest answer: Which work is interrupt-driven, which is a goal-shaped bet, and what we will standardise (visibility, ranges, WIP) versus what we will not (the same ceremony) — I do not sell one religion
Why it works: Exactly. Standardise honesty, not ritual. Method follows the work.
- Standardise visibility, ranges, and WIP.
- Let method follow the work.
- Do not force one ceremony.
- Do not punish Kanban into Scrum.
Retros across the org produce stickies and no policy moves. What do you install?
The strongest answer: A path from a repeating team signal to a named policy owner and a check — I do not collect more murals
Why it works: Exactly. Retros are a change engine or they are décor. Signal, owner, check.
- Path from signal to policy owner.
- Check the change.
- Do not collect murals.
- Do not replace team retros with an offsite.
A mature flow team is forced through sprint planning, review, and a fake goal every two weeks. The board already shows the work. Your call?
The strongest answer: Scrum is the impediment here — I keep the inspect-and-adapt habits and I drop the ceremonies that only produce theatre
Why it works: Exactly. When the ritual hides the work, the ritual goes. Habits stay.
- Drop ceremonies that are theatre.
- Keep inspect and adapt.
- Do not coach a fake sprint.
- Do not require the event to be allowed to look.
A Kanban program copies Scrum’s full set of meetings “so we have cadence.” What do you keep?
The strongest answer: Only the cadences that make a decision or a replenishment — I drop the ones that exist to look like Scrum
Why it works: Exactly. Cadence is as needed. Cargo-cult Scrum on a Kanban board is still ceremony.
- Keep decision and replenishment cadences.
- Drop meetings that only look like Scrum.
- Do not equate calendar fill with maturity.
- Do not mash every room into one long hour.
A reorg lands and last quarter’s retro changes vanish with the old teams. What do you preserve?
The strongest answer: The few policy changes that were working — written as org rules, not team folklore — I do not start from a blank mural
Why it works: Exactly. Changes that mattered become org rules. Folklore dies in a reorg.
- Promote working changes to org rules.
- Do not start from a blank mural.
- Do not archive stickies and stop.
- Do not confuse names with policies.