Project / delivery manager interview questions

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.

A developer has been stuck on access for two days and has not said so. What do you do first?

The strongest answer: I make the stuck visible on the board and I take the access as my work today — I do not praise silent struggle

Why it works: Exactly. An impediment that stays private is a delivery defect. Make it visible and move it.

• Make the stuck visible.
• Take the impediment as work.
• Do not reward silence.
• Do not wait for Friday.

The team deployed the new checkout to production on Tuesday behind a feature flag that is still off.

Has the feature been released?

The strongest answer: No — deployed means the code is in production; released means users can use it; separating the two lets us deploy safely and choose the go-live moment and audience deliberately

Why it works: Exactly — deploy and release are different events, and the flag is what gives you a controlled go-live and an instant way back.

• Deploy is not release.
• Deploy: code is in production.
• Release: users can use it.
• Flags separate the two on purpose.

A stakeholder asks “when will it ship?” You have a rough slice and unknowns. Strongest answer?

The strongest answer: A range with what would move the ends — “sooner if the dependency lands, later if it does not” — not a single Tuesday I cannot defend

Why it works: Exactly. A range plus the movers. A single date you cannot defend is a promise, not a forecast.

• Give a range, not a Tuesday.
• Name what moves the ends.
• Do not pick the midpoint as the date.
• Do not invent certainty.

A sponsor fixes the scope, the date and the budget on day one. What do you say?

The strongest answer: Something has to flex — if all three are fixed, quality or team health gives silently, so I ask which one the sponsor would move first and write that down

Why it works: Exactly — scope, time and cost are linked; naming the one that flexes up front is what keeps the plan honest.

• One constraint must flex.
• Name scope, time and cost together.
• Ask which one moves first.
• Write the agreed flex down.

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.

Product asks for an estimate for a new feature. How do you produce it?

The strongest answer: With the people who will build it: break it down together, note the unknowns, and give a range rather than a day

Why it works: Exactly. The builders estimate, and the unknowns are part of the answer.

• The builders estimate.
• Break it down, name unknowns.
• Give a range.
• Never adopt someone else’s date.

What goes in a RAID log, and how is an issue different from a risk?

The strongest answer: Risks, assumptions, issues and dependencies, each with an owner and a review date; a risk might happen, an issue already has — so it needs action now, not a probability

Why it works: Exactly — the four lists plus owners and dates; the risk-to-issue distinction is what tells you whether to plan or to act.

• Risks, assumptions, issues, dependencies.
• Owner and review date on each.
• Issue: a risk that happened.
• Review it; do not archive it.

Two developers are blocked on another team’s access approval. What is your day?

The strongest answer: Unblocking them is my top priority today — I chase the approval myself and find them useful work meanwhile

Why it works: Exactly. Clearing blockers is the lead’s core work, not an interruption to it.

• Blockers are your work.
• Chase cross-team asks yourself.
• Keep people usefully busy meanwhile.
• Escalate as a step, not a reflex.

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.

A team labels a release with MoSCoW. What do the four labels mean, and which one does the work?

The strongest answer: Must, Should, Could and Won’t-this-time. Must means the release is not worth shipping without it, and the label that does the work is Won’t, because it is a decision written down

Why it works: Exactly — if Must is not “the release fails without this”, the method is a ranked list with nicer words.

• Must: the release fails without it.
• Should: painful, not fatal.
• Could: the first thing dropped.
• Won’t: agreed, written, this release.

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.

A VP asks when the project will ship. What do you give them?

The strongest answer: A range, the assumptions behind it, the things that would move it, and the date by which I will narrow it

Why it works: Exactly. Ranges with named movers are honest and still useful to plan around.

• Range plus assumptions.
• Name what would move it.
• Say when you will narrow it.
• Do not quote the happy end.

Which delivery metrics do you look at, and what for?

The strongest answer: Lead time, deployment frequency, change-failure rate, and time to restore — as a team-level trend we discuss, never for ranking individuals

Why it works: Exactly. Flow and stability metrics belong to the team and guide the system, not the appraisal.

• Flow and stability, at team level.
• Trend, not target.
• Never per-person.
• Never for ranking.

The daily has gone quiet — people say “same” and look down. How do you facilitate?

The strongest answer: I change the prompt: walk the board right-to-left, ask what is stuck, and I do not fill the silence with my own status

Why it works: Exactly. Change the shape. Walk the work. Do not become the narrator.

• Walk the board, stuck first.
• Change the prompt.
• Do not narrate for them.
• Do not replace the talk with a dashboard only.

Cycle time looks fine but people mention night work and “quick favors.” What do you suspect?

The strongest answer: Hidden WIP — work that is not on the board — and I make it visible before I praise the numbers

Why it works: Exactly. Favors and nights are WIP. Visibility first; the number second.

• Hunt hidden WIP.
• Put favors on the board.
• Do not praise a number that excludes nights.
• Do not raise limits to match the shadow.

You have a few months of finished slices and a new, lumpier ask. How do you forecast?

The strongest answer: I show a range from what we have actually finished and I widen it for the new lumpiness — I do not quote a single week as if the past were a law

Why it works: Exactly. Observed finishes, as a range, widened for new uncertainty. No fake precision.

• Start from observed finishes.
• Keep a range; widen for new work.
• Do not multiply tickets into a date.
• Do not wait for a perfect breakdown.

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.

A slice is waiting on another team. The team wants to start three more tickets. What do you do?

The strongest answer: We name the wait, we pick one unblock action, and we only pull if we still have capacity — we do not start a pile to feel busy

Why it works: Exactly. Name the wait. One unblock. Pull only with capacity.

• Name the wait on the board.
• One next unblock action.
• Do not start a pile.
• Do not mark waiting work done.

A senior developer is allocated half-time to your project and half-time to another. Both project plans assume her full-time.

What do you do?

The strongest answer: I surface the double-booking to both project owners and their manager this week, replan with her real capacity, and agree who gets priority when the two collide

Why it works: Exactly — the conflict is between the two plans, not inside the person; fix it where it lives, with the people who can decide.

• Over-allocation is a plan defect.
• Surface it to both owners.
• Plan with real capacity.
• Agree the priority rule.

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.

The sprint burndown has been flat for four days, although the team says it has finished several stories.

What is going on, and what would you look at instead?

The strongest answer: Scope is being added as fast as work finishes, so the remaining line does not move; a burn-up plots done and total scope as two lines, so the growth is visible instead of hidden

Why it works: Right — a burndown collapses scope change and progress into one line; a burn-up separates them, which is why you reach for it whenever scope moves.

• Flat burndown: suspect scope growth.
• Burndown hides added work.
• Burn-up: done and scope lines.
• Never edit the chart to slope.

Sales wants a single launch date for a conference. You have a range. Strongest comms?

The strongest answer: I give the range, I name the conference as a constraint, and I say which end we would have to protect — I do not convert the early end into a promise

Why it works: Exactly. Constraint plus range plus what we would protect. The early end is not a gift.

• Keep the range.
• Name the conference as a constraint.
• Say what you would protect.
• Do not donate the early end.

Your feature depends on another team’s API that does not exist yet. How do you manage it?

The strongest answer: Agree the interface and a date early, name an owner on both sides, build against a stub, and track it as a risk with regular check-ins

Why it works: Exactly. Contract first, owners named, stub to keep moving, and the risk visible.

• Agree the interface early.
• Owners on both sides.
• Build against a stub.
• Track it as a risk.

The team hits dates by staying late in the last week of every sprint. What do you change?

The strongest answer: The system: WIP, slice size, and when we say a range — I do not thank the late nights as the plan

Why it works: Exactly. Recurring heroics are a design smell. Change WIP and honesty, not snacks.

• Treat late nights as a smell.
• Change WIP and slice size.
• Say the range earlier.
• Do not fund heroics with pizza.

Five “top priority” initiatives share one team. Forecasts keep slipping. Strongest move?

The strongest answer: I make the WIP visible at the initiative level and I ask leadership which two we stop starting — I do not ask the team to go faster

Why it works: Exactly. Portfolio WIP is the constraint. Stop starting. Speed is not the lever.

• Show initiative-level WIP.
• Stop starting; pick what waits.
• Do not split into five theatre teams.
• Do not hide slip in phase 2.

How do you forecast a lump of work without inventing a velocity?

The strongest answer: From the distribution of what this team has actually finished, as a range, and I say when the work is unlike that history — I do not invent a points-per-sprint law

Why it works: Exactly. Observed finishes. A range. A caveat when the work is unlike the past. No invented law.

• Use this team’s finished history.
• Keep a range.
• Say when the work is unlike the past.
• Do not invent a velocity law.

A permissions change is spread across twenty-two stories. In refinement nobody can say what an admin experiences end to end, and QA keeps finding gaps between the stories.

What do you write?

The strongest answer: A use case for the flow: the actor, the precondition, the main path step by step, and the alternate and failure paths — and keep the stories as the slices we deliver against it

Why it works: Right — stories slice delivery, a use case describes the whole interaction including what happens when it goes wrong. This needs both.

• Stories slice; use cases connect.
• Name the actor and precondition.
• Write the main path in steps.
• Write the alternates and failures.

Legal risk and launch pressure disagree. What conversation do you run with the sponsor?

The strongest answer: I name both risks, I ask which they are willing to hold, and I write the choice — I do not silently pick launch and hope legal sleeps

Why it works: Exactly. Appetite is a choice in the open. Silent launch is how you get both a miss and a finding.

• Name both risks.
• Ask what they will hold.
• Write the choice.
• Do not silently ship past legal.

Testers receive finished stories in the last two days of every sprint, and something always spills.

What do you change?

The strongest answer: I move quality left: testers join refinement and write tests with the acceptance criteria, stories are sliced small enough to test the day they are built, and testing is everyone’s work, not a final stage

Why it works: Exactly — the late-testing pattern is a slicing and collaboration problem; a test phase at the end just moves the queue.

• Test alongside, not after.
• Testers in refinement.
• Slice to testable-in-a-day.
• Quality is the whole team’s job.

Discovery and delivery keep colliding on the same people in the same week. How do you design the cadence?

The strongest answer: I make the collision visible and I reserve capacity for both tracks — a thin discovery WIP and a delivery WIP — I do not hope people “find time”

Why it works: Exactly. Dual-track needs reserved capacity and visible WIP on both. Hope is not a cadence.

• Reserve capacity for both tracks.
• Show discovery WIP and delivery WIP.
• Do not put discovery on nights.
• Do not hide the collision in one list.

You must facilitate a two-hour planning with twelve people, six remote. What do you design first?

The strongest answer: How every person will contribute in writing and in speech, who holds the board, and the decision you need by the end — I do not “share my screen and hope”

Why it works: Exactly. Remote facilitation is designed: lanes, board, decision. Screen-share hope is not a plan.

• Design written and spoken lanes.
• Name the decision and the board owner.
• Do not rely on one room mic.
• Do not replace the workshop with a deck.

How do you plan a quarter for two teams?

The strongest answer: Plan to real capacity — minus on-call, leave and debt — commit to a few outcomes as ranges, and leave room for what we do not know yet

Why it works: Exactly. Real capacity, few outcomes, ranges, slack for the unknown.

• Real capacity, not nominal.
• Few outcomes, as ranges.
• Leave slack.
• Stretch is not commitment.

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.

You are sending the same status essay to execs, the team, and a vendor. What is wrong?

The strongest answer: Each audience needs a different decision — I write the range and the ask for each, I do not blast one essay and call it stakeholder management

Why it works: Exactly. Same facts, different ask. One essay is how nobody knows what you need.

• Same facts, different ask.
• Give each audience a decision.
• Do not blast one essay.
• Do not replace an ask with adjectives.

You lead a programme spanning four teams. How do you keep it coherent?

The strongest answer: Shared milestones, agreed interface contracts between teams, one risk list, and a short regular sync of the leads

Why it works: Exactly. Milestones, contracts, one risk view, and the leads talking.

• Shared milestones.
• Interface contracts.
• One risk list.
• Leads sync, not everyone.

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.

The portfolio starts every good idea. Teams are “busy” and nothing lands. What do you install?

The strongest answer: A visible limit on initiatives in progress, a replenishment that stops starting, and a kill/wait list — I do not ask squads for more velocity

Why it works: Exactly. Portfolio WIP is strategy. Stop starting. Velocity is not the lever.

• Limit initiatives in progress.
• Replenish by stopping starts.
• Keep a kill or wait list.
• Do not invent a velocity pool.

You run several teams. What tells you one of them is in trouble, before somebody resigns?

The strongest answer: On-call load and the share of unplanned work, how long changes wait, whether problems get raised in the open, who never takes leave — read together and checked in 1:1s, never as one score

Why it works: Right — load, flow, safety and leave, cross-checked with what people actually say; no single number carries that.

• Watch load, flow, safety, leave.
• Read the signals together.
• Confirm them in 1:1s.
• No single team score.

Dates keep slipping and people have learned to give a single number they do not believe. What culture do you set?

The strongest answer: That a defendable range is the professional answer, that narrowing has a check, and that a costume date is a defect — I do not reward the bravest Tuesday

Why it works: Exactly. Ranges are the culture. Rewarding bravery is how you buy fiction.

• Reward defendable ranges.
• Narrowing needs a check.
• Treat costume dates as defects.
• Do not reward the bravest Tuesday.

Every squad is blocked by the same change-advisory wait. Local SMs keep “following up.” What is your job?

The strongest answer: I treat it as one systemic impediment: I show the wait across teams and I change the policy with the owner — I do not fund twenty follow-up heroes

Why it works: Exactly. Same wait, one policy change. Hero follow-ups are the smell.

• One impediment, one policy owner.
• Show the wait across teams.
• Do not fund follow-up heroes.
• Do not skip the control in silence.

You inherit a programme with eight hundred open defects, some three years old, and a quarterly “bug bash” nobody believes in.

What policy do you set?

The strongest answer: Every new defect is triaged within days and either scheduled or closed with a reason; the old pile gets the same rule in a time-box, and the age of open defects becomes a visible metric

Why it works: Exactly — a defect policy is a flow rule: decide fast, keep the queue honest, watch the age; a one-off purge refills within a year.

• Decide fast, watch the age.
• Triage every new defect quickly.
• Schedule or close with a reason.
• Make defect age visible.

Twelve product teams are told to “do dual-track.” Discovery becomes a central research team with a six-week queue. What is the caution?

The strongest answer: Dual-track dies when learning is a distant queue — I keep discovery close to the squad with a thin WIP, I do not centralise it into a bottleneck and call it mature

Why it works: Exactly. At scale the caution is distance. A six-week queue is not dual-track.

• Keep learning close to the squad.
• Thin discovery WIP, not a distant queue.
• Do not centralise and call it mature.
• Do not count workshops as dual-track.

A sponsor says: “ship it now, we will fix the quality after launch.” The team says the release is not stable.

How do you frame the decision?

The strongest answer: I make the trade explicit: which quality attributes we cut, what that costs after launch in incidents, support and rework, who carries the risk — and the sponsor’s decision goes on record

Why it works: Exactly — quality is the constraint that gives silently; a senior makes it visible, priced and owned rather than deciding it alone.

• Price the quality trade.
• Name the attributes being cut.
• Name the post-launch cost.
• Get the risk owner on record.

The company is remote-first and leadership still designs rooms for the HQ table. What do you change at the org level?

The strongest answer: Default artifacts and decisions that work in writing first, overlap hours for the few talks that need voices, and I do not treat HQ as the real room

Why it works: Exactly. Remote-first is designed defaults, not a camera policy. HQ-as-real is the defect.

• Writing-first artifacts and decisions.
• Overlap only where voices are needed.
• Do not make HQ the real room.
• Do not tax people with travel-as-planning.

Leadership has cancelled the product your team has been building for two quarters. You hear on Thursday; it is public on Monday.

How do you handle it with the team?

The strongest answer: Tell them myself, early and face to face, with the real reason; let them be angry; say what happens to them and to the work; then decide together what is worth keeping

Why it works: Right — first-hand, honest, and followed by what happens to them. People remember how the news arrived for years.

• Tell them yourself, first.
• Give the real reason.
• Let them react.
• Then say what happens next.

After two quiet misses, stakeholders now demand daily date changes. What are you actually repairing?

The strongest answer: Trust — I give a stable range, I say when it will move, and I stop surprising them — I do not add more slides to look busy

Why it works: Exactly. The asset is trust. A stable, honest range repairs it. Daily costume dates spend it.

• Repair trust with a stable range.
• Say when the range will move.
• Do not surprise them again.
• Do not add slide theatre.

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.