A Scrum Master’s day

In our article “Who is the Scrum Master?” we examined what the general responsibilities of a Scrum Master are, who makes a good Scrum Master and the role of certificates in the training process. In this article we take a closer look at how a Scrum Master’s day is spent.

In the simplest breakdown, a Scrum Master has two types of days: sprint turnovers, which are mostly spent facilitating Scrum events, and “regular days” within the Sprint. We will see later that these regular days are not so similar, but this simple distinction may be sufficient to start with.

Sprint turnovers

It is recommended to organise all Sprint Turnover events on the same day, so that the morning is conveniently devoted to the conclusion of the current Sprint (Sprint Review and Sprint Retrospective) and the afternoon to the planning of the new Sprint (Sprint Planning).

On these days, the Scrum Master’s most important duty is to facilitate the Scrum events. What does the word facilitation mean? It simply means to help the participants to achieve the goal. So the Scrum Master does not “lead” or “conduct” the events, nor does he/she necessarily “moderate” them, but he/she helps the team to use the right tools to make the events run as effectively as possible and to really achieve their goal. The right tool can be different from situation to situation. 

It is important to distinguish between responsibilities and activities. None of the Scrum events are one-man shows, they all involve the active participation of the whole Scrum Team. The Scrum Master makes sure before the event that all participants arrive properly prepared and that the purpose and process of the event is clear to everyone. And at the events themselves, he ensures efficient and valuable management, clear communication, adherence to roles and the resolution of possible conflicts.

Objectives of Scrum events

So what are the objectives of each Scrum event?

Sprint Review 

“The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.” (Scrum Guide)

A Sprint Review is therefore considered successful if the Product Owner and the other participating stakeholders have an accurate picture of the content and status of the product increment created during the Sprint, the Scrum Team has made the necessary decisions based on these, and has collected the necessary data to plan the next Sprint.

Sprint Retrospective

“The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.” (Scrum Guide)

In other words, a retrospective is successful if the Scrum Team has identified changes and experiments that will be implemented and tested during the next Sprint to improve the team’s effectiveness and the quality of the product. A retrospective is therefore unsuccessful if the result is simply: all is well, no changes are needed. The only thing more unsuccessful than a result-less retrospective is not keeping it.

Sprint Planning

“Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint.”  (Scrum Guide)

The Sprint planning is considered successful if, by the end of the event, the high-level goal of the Sprint; the backlog items that the team plans to produce during the Sprint to achieve the goal; and the implementation plan that the team has defined are clear to all members of the Scrum team.

Daily Scrum / Daily standup

Although the Daily Scrum, or the more common, though informal name of the Daily Standup, is usually unnecessary on Sprint Turnover days, we should not leave it out of the list of Scrum events, as it has an important purpose.

“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.” (Scrum Guide)

The daily standup is perhaps the most commonly misunderstood element of the methodology. It’s not status reporting, it’s planning. A successful standup is when team members are clear about the goal of the Sprint, where the team stands, and have planned what tasks they will do on that workday in order to make the Sprint a success. If you feel these goals are getting lost in your standups, try another standup format.

“Regular Sprint days”

Although not a meeting, Scrum considers the Sprint itself an event, just like any of the above events. The Scrum Master’s responsibility in this case is to ensure effectiveness and success. The Scrum Master therefore facilitates not only meetings but also the entire Sprint (most often two weeks long). The main difference is that the Sprint is much longer and not as focused. While in the other events all participants are focused on the event itself, during the Sprint the Developers are doing their daily work, preparing the product increment, and the Product Owner is busy with the Product Backlog, preparing and ordering future backlog items and meeting stakeholders, while of course being available to the Developers to clarify issues that arise during product development. All of this requires enough peace of mind to allow them to immerse themselves in their tasks. But then what does a Scrum Master do? How does he help you achieve your goal without being distracting?

The answer depends on a number of conditions:

  • the maturity of the team
  • on whether the Scrum Master has other teams (or, although we do not advise this, other roles and responsibilities)
  • the product
    • the number of teams working on the product
    • the amount and level of dependencies between teams
  • the maturity of the organisation
  • the stage of Scrum implementation in the organisation, and
  • what the organisation’s goals are for agility

For the sake of this article, let’s ignore the above considerations and look at the simplest situation. As promised at the beginning of this article, everyday life within the Sprint is not always the same.

Start of the Sprint

The most common tasks of a Scrum Master at the beginning of a Sprint are to “clean up” after the Sprint round, draw lessons learned from the Sprint turnover and start the new Sprint.

Documenting the Sprint turnover

After the Sprint turnover, it is a good idea to record the results of the Sprint. We recommend a simple, easy-to-read memo template for this purpose. It is also important to ensure that key stakeholders who were unable to attend the Sprint turnover are informed of the results of the Sprint. This activity is divided between the Product Owner and the Scrum Master, the PO’s task is to give any additional presentations or reports to interested stakeholders, while the Scrum Master’s task is to communicate information about the methodology (e.g. obstacles, team speed, etc.). These two actions are often not so sharply separated, as the methodology information includes, for example, a list of backlog items completed (and not completed). It is important to emphasise that the purpose of documenting the sprint turnover is always to inform and never to micro-manage.

Lessons learned from the Sprint Turnover

Scrum is an empirical framework: its central idea is the importance of making decisions and improvements based on lessons learned from experience. This basic philosophy is also important for the Scrum Master, so it is worth spending time after the Sprint turnover to evaluate it not only in terms of the product and methodology, but also in terms of the Scrum Master’s personal tools and tasks. What worked well, what should be changed, whether the retrospective technique worked, whether the colleagues who presented the product at the Sprint Review need help to become more skilful and courageous, whether all team members participated in the planning of the new Sprint with enough confidence, etc.

The followings can pop up from this thinking:

  • administrative tasks
  • research, learning, preparation tasks
  • necessary feedback to individual team members, even working with them over a longer period of time

It may happen that at the Sprint turnover, especially at the Review, in order to keep the focus, the Scrum Master promised to organize a separate discussion between Product Owner and stakeholders on certain topics. The time to organize these is also the beginning of the Sprint.

Although it is regularly stated that the tasks and action items agreed upon in the retrospective are not only the responsibility of the Scrum Master, it is important that the whole team is involved in the development of the processes, the Scrum Master often has something to do after the retrospective. These should also be started as soon as possible after the Sprint turnover.

Launching the new Sprint

When designing a new Sprint, it is important that all backlog elements undertaken by the team are independent, i.e. that there are no external obstacles to the task, to the start and completion of the development. Practically speaking, however, this goal is not always achievable, in which case we tend to allow for a small number of external dependencies that can be quickly resolved. The Scrum Master often has the responsibility of dealing with these.

The middle of the Sprint

From the second or third day of the Sprint, the focus of the Scrum Master is twofold. On the one hand he works on the current tasks of the Sprint:

  • Has there been a problem, an obstacle, even an obstacle that the team hasn’t noticed yet?
  • Has an external or internal conflict arisen that needs the support of the Scrum Master to be resolved?
  • How is the team progressing against the plan, what is the chance of success, is there any extraordinary action needed to achieve success?

The other half of the focus is on the future:

  • How good is the backlog? Are there enough good quality and clean backlog items on top of the backlog to plan the next Sprint? If not,
    • the Product Owner may need help in preparing the backlog, or
    • a backlog refinement meeting is needed.
  • How can we prepare for the Sprint review?
    • Is there a completed backlog element that Developers can hand over to the Product Owner during the Sprint to reduce the chance of misunderstandings, small stuck errors?
    • Does testing, quality control need help?
  • In a lucky case, the Scrum Master also has time to think about the distant future: what can make us even better? Answering this question of course requires continuous research, learning and reading.

Of course, there may be a continuation of the tasks that came up at the beginning of the Sprint, such as the implementation of retrospective actions.

The end of the Sprint

As the end of the Sprint approaches, the Scrum Master’s attention is increasingly focused on the closing of the Sprint. Inviting key stakeholders, if necessary consulting them beforehand about what to expect and what their tasks are – with a special emphasis on the fact that the Sprint Review is not the place to convince the PO to push in our own needs. If necessary, preliminary meetings between PO and stakeholders can be organised.

Extra equipment, demonstration product pieces, etc. may be needed for the Sprint turnover. In addition, it is important to organise the presentation of the finished product creations at the Sprint Review: to ensure that there is coordination within the team about who will present which finished development, to help them to assemble and rehearse the presentation if needed.

It is perhaps noticeable that a good part of the above tasks, e.g. individual support for each team member, explaining the roles of key stakeholders, etc., are usually more typical for a young team working in an organisation that’s new to Agile. Therefore the Scrum Master’s tasks are largely determined by the maturity of his environment. If the team is mature enough, the Scrum Master can take on another team, working with two teams in parallel.

If you’d like to learn more about the tools of a Scrum Master, or want to become a Scrum Master yourself, we recommend our Advanced Scrum Master training courses.