What does a Scrum Master do in a Sprint week when nothing is blocked?

## The visible work and the standing work The Scrum Master is accountable for the **team's effectiveness** and for the framework being used as intended. Removing impediments is the part of that accountability which is loud: someone is blocked, a decision is missing, an environment is down, and the interruption announces itself. The standing part is quiet, and it is most of the work — which is why 'what do you do in a week when nothing is blocked?' separates people who have held the accountability from people who have only watched it. A useful frame: **impediments are the symptoms the team already noticed; the standing work is the causes nobody has had time to notice.** ## What the calm-week work actually is 1. **Coaching self-management.** The test is whether the team resolves its own dependencies, disagreements and daily replanning without routing them through one person. Every dependency personally absorbed is a short-term fix bought with a long-term bottleneck. 2. **Shortening the path from a raised question to a decision.** Who can answer what, how long it takes, and which questions keep needing somebody outside the team — that path is a property of the organisation, and it can be shortened deliberately. 3. **Making the flow of work visible.** Where items sit, how long they have been sitting, what is started but not finishing. A team cannot inspect what it cannot see. 4. **Working the organisation, one layer out.** A three-week access request, a review queue in another department, a stakeholder who arrives mid-Sprint with a new priority: none of these blocks anyone today, and all of them will. 5. **Retiring practices the team has outgrown.** Effectiveness includes subtraction — a check that no longer catches anything, an event with no purpose left, a report nobody reads. ## A worked calm week Take a six-person team building billing for a community-energy supplier, with a Product Backlog of 47 items. Nothing is blocked this week, but an on-call rotation takes three of the six for roughly half their time. A calendar-keeper sees an empty week. The accountability sees three standing problems. First, the items that carried over from the last four Sprints were all items that needed a decision from outside the team, and nobody has looked at why that decision is slow. Second, every request to another department in the last two months went through the Scrum Master personally, so the team still does not know who to ask. Third, nobody has asked whether the interrupt load from the rotation is a fixable thing or a fact of nature. None of that is an impediment today. All of it is effectiveness, and all of it becomes impediments if left alone. ## Reactive against standing work | | Reactive work | Standing work | | --- | --- | --- | | Trigger | Someone is blocked now | Nobody has noticed yet | | Timescale | Hours to days | Weeks to Sprints | | Visible to the team | Immediately | Only through what stops happening | | Failure mode | Absorbing the work permanently | Being crowded out by the urgent | ## The anti-patterns interviewers listen for - **'They run the meetings.'** Facilitation is a means. If the events are the whole answer, the accountability has become a calendar. - **'They chase the tickets.'** Chasing status turns the accountability into a reporting layer and undermines the self-management it exists to build. - **'Nothing much — they help out with the build.'** Not wrong in itself; one person may hold two accountabilities. It becomes wrong when the effectiveness work simply stops happening. - **Permanent absorption.** The friendliest failure: the Scrum Master becomes the single route to every other department, and the team never learns the route. ## How to answer it well Give one reactive example and two standing ones, and attach an outcome to each. Strong answers sound like: 'The same class of impediment came up three Sprints running, so I stopped clearing it item by item and changed the arrangement that produced it, and it has not come back.' That sentence demonstrates the difference between removing an impediment and removing its cause, which is what the question is really asking. If the interviewer moves on to how the accountability should be evaluated, stay away from delivered output. Measured on how much the team ships, the accountability starts pushing work and assigning tasks — the exact behaviour the framework designed it not to have. Better signals are how quickly a raised impediment reaches an owner or a decision, whether agreed improvements are still alive two Sprints later, and whether the team increasingly handles its own dependencies without help.