Scenario questions in interviews are often inevitable, especially, for roles like the Scrum Master role.

And there are many different ways to answer them because often there is no right answer.

So how do you answer them like a pro? And what do you ACTUALLY do if you are faced with those scenarios in real life?

Watch the video or keep reading to learn more.

A few weeks ago I made a video on some interview questions for Scrum Masters and you all loved it. If you haven’t watched it, go watch it now.

One of the things I mentioned there was that the big part of the interview will be based on some scenario questions, but I didn’t go into details on that.

In this video, I want to give you some example scenarios that you might very well face in real-life working as a Scrum Master.

Here is the kicker – there are so many variations of situations, team dynamics, organizational structures, and more, that exist – that you will most likely find scenarios that you have never faced before.

I don’t think there is ANY professional who has lived through all of the possible situations that may happen in a Scrum team.

There’s always something new and unexpected.

But no matter – as an Agile leader, you need to know how to address these situations even if you’ve never faced them yourself.

I’ll talk about some general advice first, so if you are just interested in the questions, skip thru. I’ll put the chapters with questions in the description.

The right answer

You might be thinking – if there are so many variations, how would you ever learn the right answer.

Well, this is where it gets tough – there is no right answer.

Yes, I mentioned this before. But I want to talk a bit more about it.

When you are faced with a challenge, there are multiple options that will immediately become available to you.

Often multiple approaches will work and this will depend on your facilitation and teaching style, on your relationships with the team, on team dynamics, on organizational agility and more.

There sometimes will be an approach that is immediately wrong as it will only make things worse. That’s the one you should avoid. But it is usually extremely obvious.

Like, if you see a bull charging right at you, don’t just stand there hoping it would stop. Run, hide, or go for an attack yourself.

… I have no idea why that was the first metaphor that came to me, but here you go. You got the point.

Your choice system

Since there are various ways to approach situations, what are some of the choices that are available to you?

There are a few that you can always rely on.

The very first choice to make is whether you are going to:

• do something, or
• do nothing.

Do something would mean that you decide to intervene in the situation. It may involve you giving advice, supporting or guiding, or doing an essential action yourself.

Do nothing means that you let the situation unfold.

But, why would you do nothing?

Well, it might be a situation that doesn’t actually require your involvement and will be better addressed by the team itself.

You may decide to go with this choice if you want to help your team self-manage, and maybe even learn from their mistakes.

When you opt to do nothing, what it really means is that you decide to observe & analyse instead.

You take your time to see what is happening and make decisions on what could be the next steps.

So it’s kind of doing nothing and not really.

If you want to learn more about this topic, check out my video on the Scrum Master role in self-organization.

Once you have decided to intervene and do something, there are a few things you can do once again, and the choice is yours.

You can:

• Teach by providing some straightforward information on the topic and how exactly they can address it.
• Coach by asking questions and guiding people towards solutions that can work for them.
• Mentor by sharing your past experiences in similar situations.
• Facilitate a discussion or a meeting necessary as a result of the situation.
• Direct people towards the solution that most likely will work for them.
• Act on your own to resolve the situation by addressing it directly. This may involve many things.

I also have a video on the differences between teaching, coaching, and mentoring in case you want to learn more about it.

It might so happen that you would decide to use several choice available to you based on the situation at hand.

Ok, enough of that! Let’s talk about some scenarios!

I will present you the scenario and then I’ll answer how I would answer in real-life situation.

Scenario 1: Decreasing velocity

Your team’s velocity has been gradually decreasing in the past few Sprints, but they have not mentioned any issues to you. Should you be concerned?

That’s not a lot of information to go on, so the first thing for me to do would be to figure out what’s going on.

The big question here: are they actually delivering value every Sprint?

Decreasing velocity may be an indication of a problem, but it might not be.

For example, if the team is getting more accustomed to the product, and more confident when working with it, their estimates would tend to go down, which could show decreasing velocity.

But there also might be some external dependencies that prevent the team from completing the same amount of work as before.

Of even, something natural reasons. Like during a flu season where many team members may be getting sick all at the same time.

SO my approach would be first figure out what’s wrong.

In addition, I wouldn’t be as concerned with velocity itself – this is really just a metric to help the team plan. It doesn’t really represent value or team performance.

It may be more useful to look at some other metrics like cycle time, number of defects, team health index, and more.

Scenario 2: Nothing in the Product Backlog

The team constantly struggles at the beginning of every Sprint because their Product Backlog is empty and the Product Owner doesn’t have time to update it. They waste time getting the information from him. What do you do?

That is quite concerning if the Product Owner is absent. There are a few things to figure out here.

I would need to speak with the Product Owner to understand why they don’t have time with the team on a regular basis.

It might be that they don’t really understand their role and how much time they need to dedicate to the Product Backlog management and to the team.

They also might be spread too thin. And then the question would be whether we have the right person to play the role of the Product Owner.

We need to have someone who can work closely with the team, and if they are too busy doing something else, another person may be a better fit.

One more thing that comes to mind is if our Product Owner is actually a proxy, as in, they always need to ask someone else for the approval or additional information and that is what’s taking so much time.

There definitely will be some opportunities for knowledge transfer and delegation.

Then I’m also thinking about the Backlog Refinement – is it even happening? And if yes, how productive is it? Does the Product Owner attend? There might be some improvements we can implement around regular refinement.

Scenario 3: Dependency on another team

The team is unable to deliver because they have a huge dependency on another team that has to do some pre-work before your team can start. How do you manage the situation?

Firstly, I’d like to understand the process better. Why does this dependency exist? What causes it?

Is it the lack of knowledge or skills on the team? Is it a strict approval process not permitting the team to do that pre-work themselves? Is it just the way it was always done before?

To understand that I will most likely need to facilitate a discussion between my team and the other team to create alignment.

Based on the reason we can find an appropriate solution.

For example, if the team is lacking knowledge or skills, we need to organize some knowledge transfer activities. Maybe there are opportunities for pair programming. Maybe better documentation can help. Maybe a simple training session will suffice.

If the issue is the process itself, then we would need to go back to the drawing board with everyone involved in it to identify how we can optimize it to remove dependency.

This might include not only my team and the team they are dependent on, but also management, and potentially even other teams who are impacted by that process.

Scenario 4: Daily Scrum is awful

The team has been complaining about the Daily Scrum being a waste of time. It’s practically Product Owner and Team Lead talking to each other for 30 minutes. What’s your approach?

The whole point of the Daily Scrum is for the Developers to inspect their progress towards the Sprint Goal and plan their day together.

Neither the Product Owner, nor the Team Lead are even mandatory participants in the Daily Scrum, unless they are also playing the role of Developers.

My main questions would be – what are they doing in a Daily Scrum?

There might be the need for them to have their own regular discussion, but it should happen in a different meeting.

So my first instinct is to limit the Daily Scrum to the Developers only. If the Product Owner and the Team Lead want to come, they can only observe and are not allowed to speak, even to ask questions.

And then I would work with the Developers to help them make their Daily more productive by first explaining its purpose and giving some tips on how to organize it, but letting them figure out how they want to do it.

Scenario 5: Manager wants to attend the Sprint Retrospective

The manager of the team is anxious about how the team is doing and asks you to invite him into your retrospective from now on so that he knows what problems there are. How do you respond?

Firstly, why is the manager anxious? There must be a reason for him to be stressed about the team’s performance or something else.

So the first thing for me to do is to discuss with the manager in more detail what information exactly is he trying to get from the retrospective.

There might be other ways to get that information in a more appropriate manner.

I would also explain that the retrospective is the Scrum Team internal meeting where no external people are invited. It has to be a safe environment where people feel free to speak up and raise concerns.

Having a manager in the room may have a negative impact on it. So the team members may refrain from bringing the real issues to the table and hence make the retrospective much less productive.

I would also check with the team if they are willing to share their retrospective notes with the manager. However, if they don’t feel comfortable doing so, then I must respect their decision.

Ok, that’s it. That was the last scenario I wanted to share.

Of course, these are just examples of what can wait for you in the interviews and during your job as well.

If you are looking for guidance and help on this, check out my store for guides, templates, and online programs.

I share all of my secrets and ideas with you and give you practical tips on how to address challenging situations.