Scrum Master / Agile Tech Project Manager Interview Questions

I frame the role as accountability for Scrum effectiveness: coaching the team and organization, removing impediments, and facilitating events only as a means to inspect and adapt. I contrast that with project-manager command-and-control. A strong close is one example where coaching changed behavior outside the ceremony room.

Scrum Master is a Scrum accountability focused on empiricism, team health, and process coaching. Agile TPM often owns cross-team delivery outcomes, dependency risk, and stakeholder reporting for a tech initiative. Overlap is facilitation and delivery hygiene; difference is where accountability for “project success” vs “Scrum effectiveness” sits. Be explicit about which hat you wore in past roles.

Use STAR: situation (team skipping refinement), action (data + working agreement proposal, not mandates), result (measurable drop in carry-over or clearer Sprint Goals). Interviewers want influence through trust and evidence, not escalation as the first move.

I coach value ordering: Product Goal, outcome metrics, and transparent trade-offs. I facilitate stakeholder conversations so the PO stays accountable for ordering while stakeholders see impact of inserting work. If needed I offer a short backlog health workshop (INVEST, slicing, DoR) rather than taking over prioritization.

Protect focus and psychological safety under pressure: clarify Sprint Goal, surface risks early, shield the team from thrash while keeping stakeholders informed with options. Servant leadership is not doing the team’s work — it is removing blockers and enabling ownership.

I pause and restate capacity and Sprint Goal. New asks go to the Product Backlog with explicit trade-offs; we do not silently inflate commitment. I offer a short follow-up with the PO and requester if the ask is strategic, so Planning stays a plan the Developers can own.

I stop answering as a manager. I coach the Developers to inspect progress toward the Sprint Goal and replan the next 24 hours. Practical resets: standing agenda focused on Goal, “talk to each other,” and parking status for a separate stakeholder sync.

Limit to one or two experiments with owners and a check-in date. Bring evidence (cycle time, escaped defects, interruption count). Follow through next Sprint so the team sees retros matter. Rotate formats so remote teams stay engaged.

Keep sessions short and frequent. Split discovery vs sizing. Ensure acceptance criteria and DoR are clear before Planning. Pair juniors with seniors on slicing. As Scrum Master I facilitate clarity; I do not become the proxy Product Owner.

Async-first prep (shared board, written updates), tight timeboxes, rotating facilitation roles, and explicit decision logs. Prefer overlapping “core hours” for decisions. Record outcomes, not just meetings. Watch for silent participants and use round-robins or breakout rooms.

I explain velocity is a planning aid for the team, not a performance KPI. Rising velocity can mean inflation, not more value. I offer better outcome and flow measures: Sprint Goal success rate, cycle time, escaped defects, and customer/business outcomes.

Cycle time and lead time for predictability, WIP for focus, throughput for capacity conversations, and aging WIP for stuck work. For tech teams I may reference DORA signals (deployment frequency, change fail rate, MTTR) alongside team health — never in isolation.

Stabilize WIP, improve DoR, reduce mid-Sprint interrupts, slice smaller, and make risks visible early. Forecast with ranges and historical cycle time, not single-point promises. Empiricism stays intact: inspect outcomes each Sprint.

Check Goal clarity, capacity honesty, mid-Sprint scope changes, dependency delays, and quality escapes. Use data plus a blameless retro. Fix the system (interrupts, unclear AC, overcommitment) before blaming individuals.

Make debt visible as product risk. Help the PO allocate capacity for hardening (policy like 15–20% or debt stories tied to outcomes). Improve DoD and CI signals. Avoid “debt Sprint” as the only strategy — continuous repayment beats big-bang freezes.

Make the cost visible: impact to Sprint Goal and cycle time. Offer a transparent intake path through the Product Owner. Escalate with options, not complaints. Protect the agreement that committed Sprint work changes only through the Product Owner.

Separate people from problem. Hold a private facilitated conversation, agree on working agreements, and if needed use a mediated 1:1 then a team reset. Do not let conflict linger into silent sabotage. Escalate to management only if psychological safety or HR boundaries are crossed.

Early, factual, and option-based: what changed, impact on outcomes/dates, and 2–3 recovery paths with trade-offs. Avoid surprise. Bring data (board aging, dependency risks). Invite the PO to own product trade-offs while you own process transparency.

Pick a concrete anti-pattern (mandatory 15-field tickets, vanity dashboards, approval theater). Describe how you proposed a lighter alternative tied to outcomes, ran an experiment, and measured impact. Interviewers want courage plus systems thinking.

Safety means people can raise risks without punishment; accountability means commitments and quality standards are clear. I separate learning conversations from performance management, and I insist on transparent working agreements so expectations are not personal.

Visualize dependencies early, negotiate interfaces/contracts, create integration checkpoints, and escalate systemic blockers. As TPM I may own a dependency board; as Scrum Master I coach the team to surface risks in Planning and to the PO for scope trade-offs.

Be honest about depth. Explain what problem the framework solved (alignment, dependencies) and what you adapted. Interviewers prefer “we used X practices because of Y constraint” over certification name-dropping.

I align on quality bars, career growth vs delivery pressure, and architectural runway needs. I bring flow/quality data; they bring technical strategy. Healthy partnership prevents Scrum Master vs EM turf wars.

Enough to ask sharp questions about risks, testability, and CI/CD constraints — not enough to replace engineers. I can read a pipeline failure trend, discuss feature flags, and facilitate trade-offs. I never fake deep expertise.

Maintain a living risk register (probability/impact/owner), review in a regular sync, link risks to milestones, and convert risks into backlog work or mitigation spikes. Communicate residual risk clearly to sponsors.

Add WIP limits, visualize blocked work, and manage flow inside Sprints. Keep Sprint Goal and events if they still create focus. Hybrid works when the problem is flow interruption — not when leadership wants to skip empiricism.

Give specifics: summarizing long Jira threads before standup, drafting acceptance criteria for human edit, clustering retro notes, or generating first-pass test case outlines. State where AI helps (drafting, summarizing) and where it hurts (false confidence in estimates).

Treat it as a clarity and DoR issue, not a morality play. Coach better prompts and mandatory human review against DoR/AC quality. Celebrate speed only when outcomes improve. Update working agreements so AI drafts are labeled and owned.

Trust, conflict navigation, ethical judgment, and reading the room when the team is afraid to speak. AI can capture notes; it cannot rebuild psychological safety after a failed release.

Expand Definition of Done: tests still required, security review for generated code, no secrets in prompts, pair on complex changes. Track escaped defects and rework. Make AI usage transparent so mentoring still happens.

I push back on surveillance framing. Sentiment scraped from chat is biased and damages safety. I propose voluntary health checks, better retros, and outcome metrics instead. If required, involve HR/legal and insist on consent and purpose limitation.

Prepare one 60-second story: a real AI-assisted practice, the boundary you kept human, and a metric or qualitative outcome. Avoid hype (“AI runs my retros”) and denial (“AI has no place”). Bring a working-agreement example.