Do you need a scrum master? An honest answer for a five-person team

A five-person team does not need a scrum master. It needs the scrum master's work done, and those are two different sentences that get treated as one, which is how a perfectly functional team ends up being told it is doing scrum wrong because nobody in the room has a certificate.

That is the claim, and the rest of this is the argument for it. Later on it gets a limit, because there are teams where the part-time version genuinely fails and we should say which ones.

What the Scrum Guide actually requires

Start with the source, because most of the confusion comes from people quoting a training slide instead. The 2020 Scrum Guide says:

Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

And:

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.

So the accountability is not optional. Someone has to hold it. What the Guide never says, anywhere, is that this someone must be a separate person, a full-time person, a hired person, or a certified person. The words full-time, dedicated and certification do not appear in the Scrum Master section at all. What does appear is this:

If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

That sentence exists because the authors expected overlap. A developer holding the scrum master accountability is not a loophole, it is anticipated in the text.

The Guide gives that accountability two definitions worth reading slowly. First, "The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide." Second, and this is the one people skip, "The Scrum Master is accountable for the Scrum Team's effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework." Then it lists twelve concrete services, four to the team, four to the Product Owner, four to the organisation. Nothing in those twelve requires forty hours a week on a team of five. Several of them require somebody's name next to them, permanently.

What a certification is, and what it is not

Being told you are doing scrum wrong because nobody is certified is worth answering precisely, so here is what the two common certifications are.

Scrum.org's Professional Scrum Master I is an online assessment: 80 questions in 60 minutes, an 85% passing score, 200 USD per attempt. Attending a course is not a prerequisite, only "strongly recommended", and the certification is lifetime with no annual renewal fee. Scrum Alliance's Certified ScrumMaster works the other way round: you attend 16 hours of training with a Certified Scrum Trainer, then take a 50-question test where 37 correct answers passes. Scrum Alliance itself puts the course price range at 250 to 2,495 USD, and renewal requires Scrum Education Units every two years.

Both are real credentials and neither is a scam. A good PSM or CSM course is a fast, structured way to learn a framework you would otherwise absorb in fragments over a year. But look at what is actually being measured. One certifies that you answered enough multiple-choice questions about a document you can read for free in an afternoon. The other certifies that you sat in a room for two days and then answered enough multiple-choice questions.

Neither certifies that you can hold a retrospective where someone finally admits the deploy process is the real problem. That skill is not on the test, because it cannot be.

The parts a small team absorbs without noticing

Here is why the contrarian version holds up for five people. A lot of the scrum master's day-to-day exists to move information around a group too large to hold in one head. At five, the group is the head.

Facilitating a fifteen-minute standup does not need a facilitator when everyone can see each other and there is nothing to coordinate beyond who is touching the auth service today. Ensuring the events happen is a calendar invite. Keeping the board honest is a habit, not a role, and it mostly means someone drags cards at the right moment instead of at the end of the week. Removing impediments on a small team usually means one person walking over to IT, which the person who is blocked can do themselves.

Even the harder-sounding items scale down. "Coaching the team members in self-management" reads like a workshop, but on a team of five with short feedback loops it looks like a ten-minute conversation about who is going to own the flaky test suite. If your standups and backlog refinement are already working, that is not luck. It is that a small team can run a light process on shared context alone, and the same reasoning is why scrum for a solo developer collapses to almost nothing.

The three things that rot when nobody owns them

This is the part where the argument has to be fair, because there are jobs a part-time stand-in reliably fails at, and they are not the ones people worry about.

The first is protecting the sprint. The Guide is unambiguous here: "No changes are made that would endanger the Sprint Goal." Scope can be clarified and renegotiated with the Product Owner, and that is a different, narrower thing than a Thursday-afternoon request to squeeze in a feature because a customer asked in a call. Saying no to that is the single hardest piece of the accountability, and it is structurally hard for the person you would naturally hand the role to. A dev lead who reports to the head of product cannot decline a request from the head of product with the same face they use in the one-on-one on Monday. A dedicated scrum master, especially one who is not in your reporting line, absorbs that friction as part of the job description. A part-time stand-in absorbs it as a career risk. Guess which one folds.

The second is following up on retro actions. The Guide says the most impactful improvements "are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint." Notice that it does not say they are discussed. Every team can run a retrospective. Almost no busy team, unprompted, checks in three weeks later on whether the thing they agreed actually changed. There is a specific smell here, and if you have run sprints for a year you have smelled it: the same complaint appearing in three consecutive retros, each time as though it were new. That is not a facilitation failure, it is a follow-through failure, and follow-through is the first thing a part-time holder drops when a release is late. Our retrospective guide is mostly about this, and the difference between the review and the retro exists because one of them is about the product and the other is about you.

The third is coaching a struggling Product Owner. Four of the Guide's twelve services are aimed at the Product Owner: helping with Product Goal definition, with clear and concise backlog items, with empirical planning, with stakeholder collaboration. When the PO is a founder or a part-time domain expert who has never ordered a backlog before, someone has to teach them, patiently, over months. A part-time stand-in who is also a developer does not do this. They route around it instead. They write the stories themselves, guess at priority, and quietly become a second PO. It works for a while, which is the problem, because nobody notices until half a quarter of work turns out to have been built on a guess.

So which teams should actually hire one?

Our starting position was that this role is mostly overhead at small scale, and we still think that is right for five people in one room with one product. What changed our mind about the general case is watching where the failures cluster. They are not about team size at all. They are about power and about hats.

Hire a scrum master, or bring in a coach for a few months, when the pressure comes from outside the team and someone needs standing to push back: dates handed down from above, mid-sprint interrupts from sales, stakeholders who treat the board as a request queue. Hire one when the person who would hold it part-time is already the tech lead and the de facto Product Owner, because protecting the sprint from the Product Owner is part of the job and one person cannot do both sides of that conversation. Hire one when nobody on the team has run scrum before, since a part-time holder can only maintain a process they already understand. And hire one when you have several teams that need to stay in step, which is where coordination work stops being a habit and becomes a genuine full-time load.

If none of those describe you, write one person's name next to the accountability and get on with it. Not by default the most senior person, and preferably not the person who sets priorities. Give it to them for a quarter rather than rotating it weekly, because the two things that rot, sprint protection and retro follow-through, both need continuity to work at all. Then write down the boring parts, the ones nobody remembers: who checks last sprint's retro actions before the next retro starts, and who is allowed to say no on Thursday.

One honest note about tools

Scrumpy models per-team roles, and the ones we ship are Product Owner, Developer, Tester and Stakeholder. There is no scrum master role, and that is not an oversight we plan to fix. The board's roles exist so work can route to the right person automatically, so a card moving into testing lands on the tester without anyone assigning it. That is a model of who does the work, not of who runs the process, and the scrum master accountability is entirely the second thing. No board can hold it for you.

If someone tells you your team is doing scrum wrong, do not argue about certificates. Open the Scrum Guide, read the twelve services under the Scrum Master heading out loud, and ask which of them is currently nobody's job. Usually it is two of them, usually the same two, and the fix costs nothing but a name against a task. What a tool can do is make the rest cheap enough that the accountability is all you are actually spending time on: one board, one sprint, free view-only seats for the stakeholders who only want to watch. Get that part out of the way and the process work shrinks to the handful of things that genuinely need a human to care.