What Does a Scrum Master Do? (And Does a Small Team Need One)

A Scrum Master is the person on a Scrum Team who is accountable for the team’s effectiveness and for Scrum being practiced as the Scrum Guide describes it. They coach the team, make sure the events happen and stay within their timeboxes, get impediments removed, help the Product Owner keep a clear backlog, and help the wider organization understand how the team works. They do not assign work, set deadlines or manage people; the Developers decide who does what. Whether a small team needs one depends on whether it is really running Scrum. A team of five can share the accountability or give it to one Developer part-time, and a team that works in a continuous flow can drop Scrum, and the role, altogether.

What the Scrum Guide says a Scrum Master is

The 2020 Scrum Guide↗ (opens in a new tab) gives a Scrum Team one Scrum Master, one Product Owner and Developers, with no sub-teams or hierarchies. It makes the Scrum Master accountable for two things: establishing Scrum as the guide defines it, by helping everyone understand Scrum theory and practice, and the Scrum Team’s effectiveness, by enabling the team to improve its practices within the framework. It calls Scrum Masters “true leaders who serve the Scrum Team and the larger organization.”

That wording is newer than many job ads. The Scrum Guide revision notes↗ (opens in a new tab) show that the 2017 edition called the Scrum Master a “servant-leader” for the Scrum Team, and the 2020 edition moved to the language of accountability. The change matters in practice: the role answers for results, not only for being helpful.

The guide then lists who the Scrum Master serves and how. In its words, the Scrum Master serves:

• The Scrum Team: coaching members in self-management and cross-functionality, helping them focus on high-value Increments that meet the Definition of Done, “causing the removal of impediments” to progress, and ensuring that all Scrum events take place and are “positive, productive, and kept within the timebox.”
• The Product Owner: helping find techniques for defining the Product Goal and managing the Product Backlog, helping the team understand why backlog items must be clear and concise, helping establish empirical product planning, and facilitating stakeholder collaboration when asked.
• The organization: leading, training and coaching it in its Scrum adoption, planning and advising Scrum implementations, helping people understand an empirical approach to complex work, and removing barriers between stakeholders and Scrum Teams.

What a Scrum Master does day to day

The guide says what the role is for, not what fills a Tuesday. On a single team running two-week Sprints, a typical week looks something like this:

• Keeps the events honest. Sprint Planning ends with a Sprint Goal, the Daily Scrum stays at 15 minutes and stays about the goal, the Sprint Review shows working product to the people who asked for it, and the Retrospective produces a change the team will actually try. The daily standup, sprint planning meeting and sprint review vs retrospective posts cover each event.
• Chases impediments. A blocked API key, a stakeholder who keeps adding work mid-Sprint, a test environment that is down half the week. The guide says “causing the removal,” not “removing”: the Scrum Master often gets the right person to fix it rather than fixing it personally.
• Works with the Product Owner on the backlog, helping run backlog refinement so the top items are small and clear enough to plan.
• Coaches rather than decides. When the team asks “who should take this?”, a good Scrum Master hands the question back; the guide says the team internally decides who does what, when and how.
• Watches the numbers the team chose, such as how often the Sprint Goal was met or how long items sit in progress, and brings patterns to the Retrospective rather than to a manager.
• Talks to the rest of the company, explaining why the team will not take a new request until the next Sprint Planning, or why the Product Owner is the person to convince.

What a Scrum Master is not

• Not the team’s manager. The guide gives the Scrum Master no authority over what Developers work on, and a Scrum Team has no hierarchy.
• Not the Product Owner. The Product Owner orders the backlog and decides what is worth building; the Scrum Master helps that process work. On a small team one person sometimes tries to hold both, and the backlog usually wins.
• Not the note-taker or meeting booker. Those tasks may land on the Scrum Master, but they are not the accountability.
• Not a project manager with a new title. The Agile Alliance glossary↗ (opens in a new tab) lists as a common pitfall “assuming that you can just slide project managers who are used to command and control type leadership into a scrum master role and expect them to be effective.”

Agile project manager vs Scrum Master

People search this pairing because both titles show up in agile job ads. The difference is what each one answers for. A project manager, in the US Department of Labor’s O*NET description of project management specialists↗ (opens in a new tab), analyzes and coordinates the schedule, timeline, procurement, staffing and budget of a product or service on a per-project basis, and leads the work of technical staff. A Scrum Master answers for how well the team works and whether Scrum is practiced properly, and holds none of the schedule or budget.

An “agile project manager” is a project manager who runs delivery with agile practices, and the Scrum Guide has no such accountability. Some organizations employ both: the project manager handles contracts, budgets and cross-team dates, and the Scrum Master works inside the team. For the broader method, see agile project management for small teams; for the product side of the split, see product owner vs project manager.

Does a team of five need a Scrum Master?

If you are running Scrum, someone must hold the accountability. The guide says a Scrum Team has one Scrum Master, and it is blunt about partial adoption: the framework is immutable, and while implementing only parts of Scrum is possible, “the result is not Scrum.” It does not say the role must be full-time or a separate hire. It even allows for overlap: if the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they take part in the Daily Scrum as Developers.

So a five-person team has three honest options:

1. One Developer holds the accountability part-time. This works when that person has the respect of the team and the time to follow up on impediments. It works less well if they are also the team’s busiest engineer.
2. Share an experienced Scrum Master with another team. Common in larger companies, and fine if that person can attend every event you run.
3. Stop running Scrum. If your work arrives unplanned, Sprints are torn up every week, or nobody wants to own the events, a flow-based method with no required roles may fit better. Kanban vs Scrum sets out that choice, and what is Scrumban covers the middle ground.

Some signs you need someone in the role, whatever you call it: Retrospectives produce the same complaints every time; the Daily Scrum has become a 40-minute status meeting; outside requests land on Developers directly; or nobody can say what the current Sprint Goal is. Some signs you do not: the team is two or three people who talk all day, the work is mostly support and fixes, and nothing about your process is currently getting in the way.

Rotating the role every Sprint is popular on small teams and has a cost. Everyone learns the job, but nobody follows up on an impediment raised two Sprints ago. If you rotate, write down open impediments where the next person will see them.

When some of the team are AI assistants

AI coding assistants now pick up real backlog items on many teams, and they add a new kind of impediment: an assistant stuck on a permission, a task written too vaguely to act on, two assistants working on the same file. Keeping that visible is squarely Scrum Master work. The accountability itself stays with a person, because it is about coaching people and changing how a team works together. Kanban for AI agents covers how flow policies change when some workers are agents, and how to write a task for an AI agent covers the vague-task problem.

Where fenbs fits

To be plain: fenbs is not a Scrum tool. A board has four fixed lanes, To Do, Next Up, In Progress and Completed, and it has no sprints, no story points, no burn-down chart, no due dates and no assignee field you can set. Roles are defined per company, so you can create one called Scrum Master if that helps, but the board will not run your events for you. What it does give a Scrum Master is a few useful raw materials:

• History records who changed what on every task, including moves between lanes and which AI assistant made them, which is the evidence a Retrospective needs.
• Working agreements live on the Decisions and rules page. A rule is a decision that holds from now on, the decider is always a person, and every connected AI assistant reads the rules before it starts work.
• Each task carries a note for the problem, a plan, a test status with test notes, a priority from 1 to 10 and an optional size from XS to XL, so refinement has somewhere to land.

Teams that run Sprints on fenbs usually treat To Do as the Product Backlog and Next Up as the current Sprint. If you rely on generated Sprint reports or velocity charts, a dedicated Scrum tool will serve you better.