Scrum Master course and interview preparation, 1‑on‑1 with a working Scrum Master.

A Scrum Master is accountable for the Scrum Team’s effectiveness. They coach the team and the wider organisation on Scrum, help remove impediments and make sure the events happen and are useful. A project manager usually owns scope, schedule and budget and assigns work. A Scrum Master doesn’t assign tasks: the Developers decide how to do the work, and the Product Owner decides what gets built.

The Sprint, which contains all the others; Sprint Planning; the Daily Scrum, 15 minutes for the Developers to check progress toward the Sprint Goal; the Sprint Review, where the team and stakeholders look at what was built; and the Sprint Retrospective, where the team decides how to improve. Expect a follow-up on what each event is for, not just its name.

The Product Backlog, committed to the Product Goal; the Sprint Backlog, committed to the Sprint Goal; and the Increment, committed to the Definition of Done. The commitments were added in the 2020 Scrum Guide, so it’s worth mentioning them.

The Definition of Done is a quality standard that applies to every item, such as “code reviewed, tested and deployed to staging”. Acceptance criteria belong to one backlog item and describe what that item must do. An item is done only when it meets both.

Change the format and bring evidence: items that rolled over, interruptions, how long work actually took. Ask about a specific moment instead of “what went wrong?”, and try anonymous input if people aren’t comfortable speaking up. Interviewers want to hear what you changed, and what happened in the next Sprint.

Find out why before fixing anything. Usually it’s too much pulled into planning, items that are too big, hidden dependencies or unplanned work. The fixes follow: smaller items, planning against what the team actually finished recently, and making interruptions visible so the Product Owner can make the trade-off.

Make the cost of each change visible, help the Product Owner keep the next few Sprints’ worth of backlog refined, and agree that new requests go into the next Sprint unless they’re genuinely urgent. It’s a coaching conversation with the Product Owner, not a rule you enforce on them.

Make it visible, take it to the person who can actually fix it, and describe the impact in their terms, such as days lost or a release at risk. Keep tracking it, and help the team find a workaround in the meantime. Saying “I escalated it” isn’t enough; interviewers ask what happened next.

One Product Backlog and one Product Owner for the product, a shared Definition of Done, and regular cross-team planning and integration, using ideas from frameworks such as Nexus, LeSS or SAFe. What interviewers really listen for is the problems you’ve dealt with: dependencies between teams, late integration, and too many meetings.

Explain why it hurts the team: people inflate estimates and stop helping each other. Then offer something better, such as team-level delivery, how predictable the team is and quality measures. Senior interviews test whether you can say no to someone more senior and still keep their trust.

Start with one team and a real problem, get leadership to support what that team needs, such as a dedicated team and a Product Owner with real authority, show results and then expand. Expect resistance from people whose roles change, and plan for it.

When most of the work is unplanned and arrives as interruptions, as in support or operations, Kanban often fits better. Scrum also adds little when the work is well understood and rarely changes. Interviewers ask this to see whether you think about the method or just follow it.