Home → Part 19

Do You Need a Scrum Master? A Function, Not a Role

Friday 19 December, 16:00, retro. Six engineers and Gizem, our PO, an open board, an empty column. After fourteen minutes Mehmet said, “If nobody has anything, let’s finish.” We finished. Our Scrum Master, Selin, had left seven weeks earlier, and that retro produced zero actions.

Sertaç Yıldırım · 5 April 2026, 20:45 · 10 min read

From the field: four sprints after Selin left

Selin moved to another company at the end of October. We discussed whether to hire someone new, and I said, “We don’t need to.” My reason looked sensible. The team had done Scrum for more than two years. The daily and the retro were stable. From the outside, Selin’s job looked like “running meetings”. Six mature engineers can run their own meetings, I thought.

I was wrong. The visible part of Selin’s job was the meetings. The invisible part was what she did between them. In the first sprint, nothing happened. In the second sprint, the daily started to get longer, because nobody said “let’s take this offline” any more. In the third sprint, the “last actions” part of the retro quietly disappeared: that was the fourteen-minute retro on 19 December. The fourth sprint fell in the New Year week, and there was no retro at all.

Later I went back and pulled the numbers. I will use this table for the rest of the post, because we measured our next two attempts with the same rows:

The most expensive row is impediment age. In November, database access for the test environment got stuck with the infrastructure team. It waited six days. In the past, Selin solved this kind of problem the next morning, over coffee with the infrastructure team lead. Now nobody went for coffee, because it was nobody’s job. The difference was not skill. It was ownership.

What was the Scrum Master actually doing?

In early January I called Selin and asked one question: “Can you walk me through your two weeks with our team?” We talked for half an hour and wrote the list with hours. Selin worked with two teams. The part for our team looked like this:

A two-week sprint is 80 hours. Our share was less than a quarter of that. This number told us two things at once. First, we did not need a full-time person. Second, if we spread these 19 hours as “everyone does a little”, nobody would do them. The last four sprints had already proved it.

The Scrum Guide also describes the Scrum Master as an accountability, not a job description. It is the person accountable for the team’s effectiveness. The Scrum Master serves the team, the Product Owner and the organisation. The six rows above map to those three directions. The Guide does not say how many hours this takes. The team has to measure that itself.

Attempt 1: full rotation (January)

The first idea was the simplest one. Each sprint, one developer becomes “the Scrum Master of the sprint” and takes Selin’s whole list. On paper it looked fair and educational. Everyone would try the role in turn.

Mehmet went first. His own story slipped by three days, because half of each day went to meetings and follow-ups. In the same sprint, another infrastructure blocker came up and waited five days. Mehmet did not know whom to call, and the infrastructure team did not know him. Ayşe took the second sprint, and the same thing happened. For the third sprint, nobody volunteered. The team had already named the role “chore week”. We stopped after two sprints.

To understand why it failed, I looked at the list again. The six functions were very different in nature:

• Facilitation can be learned. In two weeks, someone can learn to run a good daily.
• Removing impediments needs relationships and authority. If you do not know the infrastructure team lead, you cannot build that relationship in two weeks.
• Measurement needs continuity. If a different person keeps the numbers every two weeks, you lose the trend.

Full rotation put all three in the same box and gave them all the shortest period. That was right for the first one and wrong for the other two.

Attempt 2: split the functions, choose the owner by time (February–March)

In the second attempt, we split the list. For each function we asked two questions. Who does this best? And how long should the same person keep it?

The last column of the table shows the result after four sprints. The daily went down to 9 minutes. Impediment age went down to 2 days. We met the sprint goal in 3 of 4 sprints. Retro actions started to close again, because Ayşe opened every retro with the list of last time’s actions. I wrote that rule on this blog myself on 6 December. Two weeks later, I was not following it in our own retro.

This time, the facilitation rotation held. The difference was that it was now one job of about 7 hours, not 19. Nobody’s own work slipped by three days. Two people liked the role so much that they wrote the walk-the-board daily format back into the team rules.

How it breaks: three things that did not work

1. The blocker was me

I took impediment removal because I had the relationships with other teams. That made sense. But in mid-February, a new row appeared in Ayşe’s table: the number of items whose priority changed in the middle of a sprint. There were six in four sprints. I had brought three of them: “Can Mehmet look at this for half a day?” None of them was written on the board as a blocker. Nobody writes their manager down as a blocker.

This showed one feature of the Scrum Master: they are not the team’s manager. The team tells them things it cannot tell the manager. No matter how well I did this job, that channel did not open for me. For the same reason, I did not facilitate the retro. I tried once, and everyone in the room talked while looking at me. I had already written about how to budget work that arrives mid-sprint. I was the one who broke that budget most.

2. The coaching gap

In February, Barış moved to another team and Emre joined in his place. Nobody explained to him why the daily goes item by item, not person by person. For three weeks, he gave a status report every morning: yesterday I did this, today I will do that. Nobody corrected him, because it was nobody’s job. The rotating facilitator ran the meeting. Explaining to Emre why we work this way was a different job.

The same gap appeared on the PO side. With Selin, about 8 in 10 stories came to refinement ready. In March it dropped to 5 in 10. The rotating facilitator joined the preparation meeting with the PO. But they did not have the seniority to teach the PO’s job to the PO. Coaching is not something a person can do after taking the role for two weeks. It needs trust, and trust needs time.

3. The organisation side

The last row in Selin’s list, “talking to other teams and management”, was only 2 hours per sprint. It was the row I cared about least. In March, a neighbouring team moved its sprint calendar one week away from ours and did not ask us. Two shared items waited for each other for two sprints. With Selin, that decision would have gone through her, because she was the Scrum Master of both teams. None of us had built that relationship.

The decision: team size and dependencies

At the end of March we had to decide. “Do we need a Scrum Master?” was the wrong question. The right question was this: which of these six functions can be shared, which ones need one person, and how much time does that person need? This is the table I took from our experience and from how Selin worked with two teams:

We were in the second row. Since early April, Deniz, the Scrum Master of the neighbouring team, gives us one day per sprint, which is 8 hours. These 8 hours go to exactly the three rows we could not do well inside the team: coaching, preparation with the PO, and organisation. The facilitation rotation (now meetings only, 4 hours per sprint) and Ayşe’s measurement continue. Impediment removal stays with me, with one change. Every sprint, Deniz reads the “mid-sprint priority change” row with me. If I am the source, she does not hear it from me. She sees it in the numbers.

We did not decide by budget. There was budget for a full-time Scrum Master. We did not hire one, because 11 of the 19 hours were done well inside the team. In the same way, it would have been wrong to hire nobody “because there is no budget”. November and December paid for that for four sprints.

Checklist

Conclusion

In that fourteen-minute retro on 19 December, there were seven skilled people in the room. The missing thing was not a person. It was 19 hours that were in nobody’s calendar.

Today I answer “Do we need a Scrum Master?” with another question: “Which function are you giving to whom?” If you have an answer, maybe you do not need one. If you say “everyone does a little”, you need one. You will just learn it four sprints later.