Skip to main content

Dear Scrum Masters: Ask These 7 Questions in Your First 90 Days to Ensure Long-Term Team Success

March 9, 2026

What do you actually do as a Scrum Master when you join a new team?

I ask this question to many Scrum Masters — and to myself. I’m always curious to learn how others work, think, and operate. The three most common answers are: conducting 1:1 meetings with every team member, ensuring all Scrum events take place, and observing the team’s collaboration.

For the first 90 days, these activities might enough.

However, if you want to be successful beyond that initial phase, simply improving the Scrum process isn't enough. You must also dedicate yourself to value creation, organizational structures, and team dynamics to uncover hidden obstacles.

For me, these seven questions have proven extremely helpful.

Question #1: What is the team’s mission from both the team's and management's perspective?

Let me let you in on a secret: Simply throwing a group of people into a room and saying, "You are a team, go do great things," won't work. But you probably knew that already.

Successful teams are like living organisms; they develop their own identity over time. You can lay the foundation for this identity by asking your team three questions:

  • Why do we exist?
  • What is important to us?
  • What do we want to achieve together?

However, identity alone isn't enough for long-term success within a company. Success isn't usually measured by the team, but by management. Therefore, never forget to ask:

What does management expect from our team?

Question #2: What defines "Value" for the product?

What characterizes successful product development in the end?

It is a win-win situation for users, customers, and the company. Nothing more, but certainly nothing less.

Think of a product where users are unhappy. Or a product that doesn't generate revenue for the company in the long run. Truth be told: how successful is that development really? In Scrum, we call this win-win situation "Value." If you want to help your team, help them understand what this win-win looks like concretely. Ask yourself:

What defines value for our product?

Question #3: How transparent is the information needed for informed decisions?

Every Scrum Master knows the three artifacts:

the Product Backlog, the Sprint Backlog, and the Increment. Some even know they cover all time horizons: the future, the present, and the past. But few realize that Scrum’s success depends entirely on the transparency of these artifacts. They are the basis for every decision.

The less transparent these artifacts are, the poorer the decisions will be.

You can recognize a lack of transparency when decision-making takes forever. Slow decisions are poison for agility. Agility means reacting quickly to change, which requires fast decisions. That’s why the Product Owner role exists — one person can decide faster than a committee.

So ask yourself:

"How transparent is the information needed to make vital decisions?"

Question #4: How agile is the team, really?

What is the one metric to measure agility?

That was a trick question — there isn't just one. However, some metrics describe agility better than others. One metric I would never do without is Cycle Time.

Cycle Time is the time a team needs to move a Product Backlog item through the entire development process. We measure how long a feature or bug fix takes from the moment work starts until it is "Done."

The Scrum Guide even provides a benchmark: the length of a Sprint. If your team takes longer than 30 days to finish items, action is needed. I’d go further: the general expectation for a Sprint is 2 weeks. Therefore, ask:

"Is our team agile enough to deliver new software in less than 2 weeks?"

Question #5: What prevents the team from delivering and learning faster?

If the answer to the previous question is "no," what's the reason?

Image
Goals

Common obstacles I’ve seen over the last 10 years include:

  • Multitasking: Members working on too many things at once.
  • Dependencies: Too many links between backlog items or other teams.
  • Skill Gaps: Constant lack of necessary skills to get work to "Done."
  • Technical Debt: Legacy issues must be cleared before new things can be built.
  • Lack of Feedback: No reviews with customers/stakeholders.
  • No Goal: No common Sprint Goal or the team isn't a "real" team.

Use these insights to formulate your own investigative questions, such as:

"Our team builds tools for other teams. Who are our stakeholders, and how do we get early feedback?"

Question #6: How professional is the software development process?

There are two ways to develop software today.

The first involves manual steps for everything — compiling, hosting on physical servers, manual testing, and manual deployment.

The second involves modern professionalism:

  • Software designed as independent services.
  • Automation from integration to deployment.
  • Infrastructure as Code for instant scalability.

I’ll go out on a limb and say the first way has no future. To see where your team stands, don't just look for specific tools; look at the impact of your practices:

  • How often do we deploy new versions?
  • How much time passes from code commit to successful deployment?
  • How quickly do we recover from service interruptions?
  • How often do deployments fail or require rollbacks?

Question #7: What is the state of psychological safety within the team?

When it comes to retrospectives, many Scrum Masters focus on the wrong things.

They ask themselves:

  • Which format should I use to ensure everyone participates with enthusiasm?
  • What do I do if I couldn't book a meeting room for our onsite retrospective again?
  • How can I bring more variety into the retrospective?

Don’t get me wrong: these questions are important. However, we shouldn’t forget one thing: in the end, retrospectives are not about the format, but about the result. And that result depends on one thing: psychological safety.

Research is now in clear agreement on this. For example, a survey of 236 members across 43 software teams showed that teams with high psychological safety reflect significantly more often, implement more improvements, and perform better overall. In other words: psychological safety had both an indirect effect (through the ability to reflect) and a direct positive impact on team performance.

If you, as a Scrum Master, want to ensure that the ability to reflect continues to evolve in the long term — well beyond the first 90 days — and thus increase team performance over time, you must ask yourself this question:

"What is the state of psychological safety within the team?"

These seven questions have helped me in the past to uncover obstacles not only within the Scrum process, but also in value creation, organizational structures, and team dynamics.

Do look for ways to accelerate your career as a Scrum Master?

Then the PSM III Bootcamp might be the next step for you.

In this cohort-based online training, you will take on the Scrum Challenge by answering 30 PSM III practice questions in 30 days to develop the skills needed to think like a Professional Scrum Master and pass the certification exam.

Join us to elevate your expertise to the highest level and drive real impact in your organization.


What did you think about this post?

Comments (0)

Be the first to comment!