Can a Scrum Master also be a Developer?

Small teams ask this question constantly, usually because there is no budget for a dedicated Scrum Master. The short answer is yes, with conditions. The longer answer is about what the person gives up and what the team risks, and whether those costs are visible to anyone.

What the sources say

The Scrum Guide does not forbid it, and it assumes it can happen. In describing the Daily Scrum, it says: if the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. The same sentence tells us that the roles are accountabilities and not people. One person may hold the Scrum Master accountability and also be doing Developer work, and the Guide has a rule for how they behave at that meeting.

The Guide also describes the Scrum Team as having one Scrum Master, one Product Owner and Developers, with no sub-teams or hierarchies. It does not say the Scrum Master must be full-time, or that they cannot build.

The SBOK® Guide goes a step further. It says the Scrum Master is at the same hierarchical level as anyone else in the Scrum Team, and that any person from the Scrum Team who learns how to facilitate Scrum projects can become the Scrum Master for a project or even for a single Sprint. That makes rotation a design option, not an accident.

Neither source gives a percentage for the Scrum Master's time. Common practice says that a healthy team of five to nine needs somewhere between a fifth and a half of someone's time, depending on how much impediment work and organisational coaching there is. That is an experience-based range, not a rule.

What it costs

Capacity. A person doing both jobs has fewer hours for each. If the team's forecast does not reflect this, it will be too high. The Guide says the Developers' forecasts depend on their upcoming capacity, so the part-time Scrum Master's real availability has to go into Sprint Planning.

Bias in facilitation. A facilitator who is also a stakeholder in the outcome finds it harder to stay neutral. If the Scrum Master-Developer has a strong view about a design, running a discussion about it requires effort.

Role confusion. Colleagues may not know which hat the person has on. An instruction can sound like a request from a peer or a direction from a leader.

Thinner coaching. The accountabilities for coaching, impediment removal and organisational work are the first to be squeezed when a deadline is close, because the code is more visible.

Single point of failure. If the person is also the strongest Developer, their time is in high demand, and the Scrum Master work becomes the thing that slips.

A worked example: the capacity maths

This is an illustrative case. A team has five people, including one who acts as Scrum Master. The Sprint is two weeks, which is ten working days. After holidays and meetings, a Developer has about six productive days for Sprint Backlog work in a Sprint.

The team's usual forecast is based on five Developers. But the Scrum Master spends about a day and a half per Sprint on events and facilitation, half a day on impediments, and one day on organisational matters and coaching. That is three days. Their Developer capacity is about three days, not six. The team's capacity is therefore four and a half Developers, not five.

If Sprint Planning ignores that, the team commits to roughly ten percent more than it can do, and the Scrum Master's duties take the shortfall. Over several Sprints the team concludes that it is slow or that Scrum costs too much. The calculation fixes this: show the capacity, forecast against it, and review whether three days is the right amount.

The point is not the exact number. It is that the cost is made visible, so the team and the Product Owner can decide whether it is worth it.

Four safeguards

1. Say which hat. Make it explicit when you are facilitating and when you are contributing. If you are in a technical discussion as a Developer, say you are speaking as one, and ask someone else to facilitate if the discussion is heated.
2. Plan the Scrum Master time. Put it on the Sprint Backlog or treat it as a reduction in capacity. Do not rely on goodwill.
3. Hand off the facilitation of contested topics. If you have a stake in a Retrospective topic, let a colleague lead that portion.
4. Rotate where you can. Passing the role between team members every few Sprints builds shared understanding of Scrum, spreads the load and guards against a permanent pecking order. It does need a handover and some patience for the first Sprint of each person.

When it does not work

Some signs that the arrangement has run its course: Retrospective actions stop being followed up, impediments sit for more than a few days, the person is the only one who knows how the events work, or they are regularly working evenings to catch up. The Agile Manifesto's principle on a sustainable pace is relevant here, since sponsors, developers and users should be able to maintain a constant pace indefinitely. If the dual role requires overtime, the choice has been made at the expense of someone's health.

At that point the options are a smaller Developer load, a partial dedicated Scrum Master shared across two teams, or, if the organisation can afford it, a full-time role. Which one is right depends on how many impediments the team faces and how much coaching its members need.

What about the Product Owner?

The Guide's wording about Developers also covers the Product Owner, who may work on Sprint Backlog items and participate as a Developer. The combination of Product Owner and Scrum Master is much more problematic in practice, because one role pushes for scope and the other protects the team. Teams that try it often find that the Scrum Master duties disappear. This post concentrates on the Scrum Master and Developer, which is the common case.

How to practise it

Estimate honestly how many hours your Scrum Master work takes in a typical Sprint, then show the number in Sprint Planning. In the simulator the capacity of the team is an input you plan against, so you can see what happens when you overestimate it.