Become a Super Scrum Master 2 - the assignments

Now, I would like to delve into more specific tasks for a ScM and how the different ceremonies can be organized to maximize their effectiveness.

One small but crucial ceremony within Scrum are the short daily stand-up meetings. The purpose of these meetings is to facilitate collaboration among team members and create a work environment where everyone has full visibility into what other team members are working on.

When I say "short stand-ups," I mean they should be kept very brief and not become the subject of long discussions and conversations. Instead, focus on ensuring that each team member answers three questions:

• What did I do yesterday?
• What will I do today?
• Are there any obstacles in my way?

Another recommendation is to conduct daily stand-ups while standing. It's evident from the name itself... The reason behind this is that it helps keep the meetings timeboxed. If everyone is comfortably seated in armchairs or office chairs in a meeting room, it becomes much more challenging to stick to the allocated time.

An effective daily stand-up in a team of up to ten people should ideally last no longer than 15 minutes, or even shorter. If, as the ScM, you consistently exceed this time limit, team members may begin to feel that it takes up too much time and question its value.

If someone raises an obstacle, it can be tempting to jump in and try to solve it right away - avoid doing that! This is something that can be discussed outside of the daily stand-up; otherwise, there is a significant risk of it extending the meeting time. As the ScM, it is your responsibility to interrupt such discussions in a graceful way so that nobody feels stepped on or offended.

One last thing I want to mention is the importance of holding daily stand-ups at the same time and in the same location every day. This creates a natural routine for everyone and makes it easier for all team members to participate.

Sprint planning is a critical activity where both the ScM and PO play central roles. As the ScM, it is essential to prepare thoroughly before sprint planning by familiarizing yourself with the goals and purpose of the upcoming sprint.

This will make it easier for you to communicate the upcoming goals to the team and create a better understanding of what needs to be done in the next sprint.

Before the meeting, it's good for you, as the ScM, to sit down with the team and explain the activity, articulating what needs to be done and why. It is much easier for the team to participate and engage when they also understand what is expected of them. Another crucial aspect is to ensure that the product backlog is clear and prioritized.

This significantly simplifies matters if everyone knows what is most important by studying the backlog. It becomes much more complicated if you have to begin sprint planning by prioritizing everything in the backlog.

As always, it is also up to the ScM to ensure that the team does not get lost in endless discussions about various topics. Keep in mind that technicians are technicians, and it is easy for them to get caught up in detailed discussions about preferred encryption algorithms now and in the future or how quantum computers will impact all algorithms, and so on.

Here, it is essential for you, as the ScM, to be responsible for fulfilling the overall goal of sprint planning and keeping to the schedule.

A common problem during sprint planning is that team members tend to be too accommodating and promise more than they can deliver. I understand why individuals do this, but it can backfire if the team cannot fulfill all the commitments. In my experience with the teams I've worked with, it is generally better to promise slightly less and then add items if there is room.

An important part of planning involves calculating the team's capacity. In its simplest form, you, as the ScM, can define that one story point equals eight hours of work, or one workday. If you are calculating the capacity for a team of ten people over a three-week sprint, it would be 10 people x 3 weeks x 7 days = 210 story points (SP). However, the ScM and PO are not included in that calculation, so we subtract 2 x 3 x 7 = 42 SP, leaving us with 168 SP. Additionally, as the ScM, you need to account for some overhead and room for activities not included in the regular planning.

Assuming that 15% of the capacity is allocated to this, an additional 0.15 x 168 = approximately 25 SP will be deducted, resulting in 143 SP. Then, let's say two people will be on leave, one for two weeks and the other for one week. This means another 3 x 1 x 7 = 21 SP is subtracted, leaving us with a final capacity of 122 SP for the team during the sprint.

As you plan everything you need to do during the sprint, 122 is the magic number. Of course, it's difficult to plan all activities to exactly match that number, but if you can come close, there is a much greater chance that the team will be able to deliver everything they have promised and committed to.

Although the PO is responsible for the product backlog, as the ScM, you can also contribute to prioritizing the items in it. The more you facilitate this work, the clearer the backlog will be, making it more useful for both sprint planning and ongoing work. Different perspectives are always beneficial, and the closer the PO and ScM can collaborate, the better.

The more involved you, as the ScM, are in the PO's work, the more you will get out of the collaboration. In previous assignments or roles, I have often heard statements like:

• Well, that is actually the ScM's responsibility and task.
• That is not part of my job. It's the PO's responsibility to handle it.

In most of these cases, they couldn't have been more wrong. Remember to focus more on what the team needs to deliver and less on what falls under specific roles. It feels a bit like going back to the '80s or '90s when everyone wanted job descriptions with exact specifications, and as soon as a task didn't fit neatly into a description, there was nobody available to handle it.

Therefore, it is warmly welcomed for the ScM to help and support the PO in all situations. This becomes especially important when things become challenging or when there is friction somewhere in the process. In the long run, this will contribute to a well-maintained backlog and ensure that everyone in the team knows what is expected at all times.

If you, as the ScM, successfully implement what I have written about, you will be well on your way to becoming an SScM. However, there is another important task that we have only touched upon so far: how to handle obstacles, risks, and other factors that muddy the waters. I will discuss this further in the next article.