When several teams contribute to the same solution, some work will need to happen in sequence. Teams will occasionally require specialist expertise. Shared platforms, environments, governance functions, and integration points will create legitimate connections between people and work.

The problem is that Agile Release Trains often respond to every dependency in the same way, i.e. by adding another coordination mechanism.

For example:

Let’s say a dependency is placed on a board. RTE schedules a cross-team meeting… aka “sync”. An escalation path is created. The RTE follows up with the teams. Everyone agrees to monitor the situation closely.

These “actions” may help a temporary dependency. But they DO NOT address recurring dependencies.

Before deciding how to manage a dependency, an RTE should ask:

What kind of dependency is this, and what response does that type require?

The answer should lead to one of the following responses:

Read more

Thank you for the question.

“Who gets the final say?”

It sounds like a simple question. Yet it sits behind many of the problems Scrum Masters are asked to help with.

A healthy Scrum Team wants input from everyone. But it also knows where the final decision (or “say”) belongs.

Collaboration does not mean everyone decides everything.

Sometimes the Product Owner decides after listening to others. Sometimes Developers decide after clarifying the product need. Sometimes the whole Scrum Team needs to reach an agreement. And sometimes the decision is constrained by an organizational policy that the team cannot simply vote away.

Scrum Masters can help their teams make these unclear boundaries clear.

In this post, I will give you my take on this and a way to help your team define these boundaries.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Thank you for the question.

This is clearly an intake problem.

Let’s start by making one thing clear: We can’t (and shouldn’t) eliminate all unplanned work.

In many environments, production incidents, regulatory changes, security vulnerabilities, and critical customer issues are legitimate realities.

And therefore…

Our aim should be to make the “intake” of such work visible and governed by clear trade-off decisions.

As a Scrum Master, you can help your team.

How?

By investigating the system through which “such” work enters your Sprints.

Let’s walk through how to do this properly.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Q: “Hi Vibhor, could you write about the metrics an RTE can use in an Agile Release Train? What should an RTE actually focus on to enable better planning, improve execution, and steer the ART toward value?”

Thank you for the question.

This is one of the most common questions I get from Scrum Masters stepping into or supporting an RTE.

The honest answer is this:

Most RTEs either measure too little (and fly blind into PI Planning) or measure too much (and drown their teams in dashboards). The goal is the right data, used the right way.

Here’s how I’d break it down.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Thank you for the question.

Most hybrid teams decide when people should come to the office. But what they don’t do is decide what they need to accomplish in those meetings.

Here’s what happens:

• The team selects two or three office days

• Everyone rearranges their schedule and commutes

• Then they spend half the day joining video calls

Meanwhile, the retrospective where the team needs to discuss a difficult conflict takes place with six people in a room and two people struggling to participate remotely.

Many believe the issue with Agile teams is too many remote meetings, but the actual problem is that teams often don't align the meeting format with the purpose of the work.

• Some meetings benefit from physical proximity.

• Others work just as well remotely.

Some should not be meetings at all.

And mixed-location meetings, where some people share a room while others join remotely, often create (as research shows) the worst experience of the three.

In this post, I will provide a Meeting Format Decision Model you can use to choose among in-person, fully remote, and hybrid meetings for each Agile event and other meetings.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Thank you for the question.

That observation you shared tells me that you are already doing the harder part of the job.

Most Scrum Masters I speak with are focused on getting their teams to follow the practices. You are asking whether the practices deserve to be followed at all. That is a more honest question, and it is the right one to be asking in 2026.

The problem you are standing in right now looks like this:

• Daily Scrum at 9:15 a.m.,

• Sprint Planning every other Monday,

• a groomed backlog,

• a velocity chart on the wall,

• a retrospective every two weeks,

• a Sprint Review on the last Friday.

• Attendance is good.

• The events run on time.

And yet the team’s decisions take longer than they should.

Nobody questions the events, because the EVENTS are Agile, and Agile is how the team does things.

Scrum Masters are no longer introducing Agile to teams for the first time.

They are inheriting Agile.

A team that inherited its practices is a different problem than a team that failed to apply them. The inherited team looks fine from the outside. The events are followed and accounted for. What is missing is the reason the events were designed in the first place.

And because these practices have been around for years, people stopped asking the necessary question:

Is this still helping us learn, or are we just preserving the shape of Agile?

SO let’s ask this question and see what happens.

Subscribe now

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Agile is old enough to need inspection

Agile is no longer new.

In the early days, many teams were trying to move away from heavy upfront planning and rigid delivery models like “waterfall”. Agile practices felt fresh at that time because they challenged the old system.

Now, in many organizations, Agile itself has become the system.

That means some teams are no longer rebelling against bureaucracy. They are navigating Agile bureaucracy.

Has Agile failed?

No!

Agile practices have been institutionalized.

And anything that becomes institutionalized needs inspection… periodically!

Separate the principle from the habit

The Agile Manifesto comprises four values and twelve principles.

Velocity appears nowhere in it, nor do story points.

The Manifesto does not define the structure of a Sprint Review or specify how long a Daily Scrum should last.

Those practices came later, mostly through Scrum and XP, and then through the organizations that implemented them, modified them, scaled them, and handed them down as received wisdom.

The distinction between Principles and Practices matters enormously, and getting it clear is the first step for an audit.

#1: Principle

A Principle is a durable belief about how good software work gets done.

These beliefs have held up across a wide range of contexts over 25 years.

#2: Practice

A Practice is a specific “action” designed to express a principle in a real working environment.

An institutionalized habit occurs when a Practice disconnects from its “original” purpose and continues to run on social inertia.

The team does it because the team has always done it, because the tooling was built around it, because the certification said so, because the manager can see it on a report, because removing it would require a conversation nobody wanted to have.

phew…

I know.

Why teams protect Practices that no longer work

The error that keeps Agile organizations stuck is treating Practices and Principles as equivalent, then using the authority of the Principles to shield the Practices from scrutiny.

Read that again…

Here’s an example:

When someone questions whether “velocity” tracking is actually helping the team make better decisions, they are examining a specific “action” used to express a Principle. That examination is completely legitimate. The Principle survives the question. The Practice has to answer it.

A 2025 systematic mapping study that analyzed 97 studies published throughout the Agile era found that

• communication,

• adaptability,

• leadership, and

• collaborative sense-making

are the qualities that recur most consistently across healthy Agile teams, regardless of which framework they use.

These are human capabilities with a 25-year evidence base behind them.

The practices that still support these capabilities deserve to stay. The practices that have gradually displaced them deserve inspection.

4 tests every Practice needs to pass

Before deciding what to keep, retire, or rebuild, you need a consistent basis for evaluation.

The audit I recommend applies 4 tests to every Practice.

Test 1: Feedback:

Does this practice shorten the time between action and learning?

Apply this test by asking whether the gap between doing and understanding actually shrinks because of the practice, or whether it would shrink just as fast without it.

Test 2: Customer Contact:

Does this practice move the team closer to real user evidence?

Product specifications written on behalf of end-users are a different category of evidence than observations of actual end-users interacting with working software.

Apply this test by asking whether the practice narrows that distance, or whether it substitutes one layer of interpretation for another.

Test 3: Team Learning

Does this practice produce adaptation, or only attendance?

Showing up to a Scrum event is compliance.

Changing behaviour as a result of that Scrum event is learning.

Apply this test by asking what the team does differently after the practice runs. If the honest answer is nothing in particular, the practice is generating compliance.

Test 4: Decision Quality

Does this practice help the right people make better decisions sooner?

Visibility that informs senior leadership without changing what the delivery team does next is a different outcome than a practice that puts decision-making authority with the people who have the best information.

Apply this test by asking who makes a better decision because of this practice, and whether that person is actually the one closest to the work.

These four tests are not a published academic framework. Apply them as you see fit.

What matters is applying the same questions to every practice, including the ones you personally favour.

Practices that still hold up

Some “inherited” Agile practices hold up well.

They earned their place because they still do real work, and that work is clear when you apply the four tests.

#1: Small Increments of Deliverable Work

Short cycles create feedback. Long cycles create assumptions.

This passes all four tests with little difficulty.

Breaking large uncertain problems into small deliverables, then getting real feedback on each slice, is as sound in 2026 as it was in 2001.

#2: Honest retrospection

This passes the feedback, learning, and decision-quality tests, but only when done well.

The word “honest” is carrying weight in that sentence.

A retrospective that produces a list of observations and no behavioural change is no good.

When a team uses a regular cadence to examine what is slowing them down, what is creating confusion, and which experiments they are willing to run, they are applying the twelfth principle of the Manifesto directly. That principle has not lost anything over 25 years.

#3: Direct Customer Contact

This practice holds up for the same reasons it always did.

Teams with regular, structured access to real users improve their understanding of what to build.

The teams that build things people actually use tend to be the teams that spend time watching people use things.

#4: Visible Work

This practice passes the decision-quality test when visibility genuinely serves the team.

What these practices share is that they quickly connect the team’s work to real consequences.

They create conditions under which learning happens continuously, without waiting for a scheduled reporting cycle.

Be careful with metrics that become targets

Metrics deserve special attention.

Historical delivery data can be useful. It can help teams forecast, understand flow, and have more honest conversations about capacity and trade-offs.

But when a metric becomes a target, behavior changes.

Velocity is the obvious example.

When velocity is treated as a forecasting signal, it may help. When it becomes a performance target, it can damage the system. Teams may inflate estimates, avoid risky work, split items artificially, or focus on points instead of outcomes.

That is why Scrum Masters need to inspect not only the metric, but the behaviour the metric creates.

A metric is not neutral once people are judged by it.

Rebuild before you retire the practice

Some practices should not be kept as they are. But they should not be thrown away either.

They need to be rebuilt.

This is an important category because it avoids the false choice between defending the old process and rejecting everything.

Sprint Planning is a good example.

The need behind Sprint Planning is still real. Teams need to decide what matters next, understand the goal, see the risks, and align around a short-term plan.

But in many teams, Sprint Planning becomes a capacity-filling exercise. The discussion focuses less on the outcomes and more on the capacity planning to fit.

Rebuild refinement around evidence

Backlog refinement needs the same treatment.

The original purpose is valuable: create enough shared understanding before work begins.

But refinement can easily become backlog farming.

Items are added, described, estimated, tagged, split, and stored. The backlog grows. The team feels productive. But the organization is simply creating a larger inventory of untested ideas.

Sometimes the best refinement outcome is not a better ticket. It is deleting the ticket.

Rebuild Sprint Reviews around decisions

Sprint Reviews are another common place where Agile becomes a routine.

Here’s what happens:

The team demonstrates work. Stakeholders nod. Someone says, “Looks good.” A few comments are made. Then everyone leaves, and the backlog continues mostly unchanged.

That is a demo. It may be useful, but it is not enough.

When the Sprint Review becomes a decision-making and learning event, it regains its power.

The goal is to inspect the product and adapt the future.

Look for customer contact

One of the strongest tests of an Agile practice is whether it brings the team closer to users.

Many teams are internally Agile but externally disconnected.

They collaborate well with each other. But real user evidence remains distant.

That is dangerous because the team can become very efficient at delivering assumptions.

Agile without customer contact easily becomes internal bureaucracy.

Compliance is not the same as adaptation

• A compliant team holds the retrospective. An adaptive team changes how it works as a result of the retrospective

• A compliant team updates the board. An adaptive team uses the board to notice bottlenecks and rebalance work

• A compliant team attends the Sprint Review. An adaptive team changes product direction based on what the review reveals

From a distance, compliance and adaptation can look similar.

Inside the team, they feel very different.

Compliance feels like going through the motions. Adaptation feels like a process that helps the team think, decide, and improve.

Scrum Masters should care less about whether the activity happened and more about whether it changed anything important.

Use decision quality as the main lens

If there is one lens that ties the whole audit together, it is decision quality.

A practice is valuable when it helps the right people make better decisions sooner.

For Example:

• Daily Scrum should help the team decide how to coordinate today.

• Sprint Planning should help the team decide what matters most in the next short cycle.

• Sprint Review should help the team and stakeholders decide what to continue, change, stop, or investigate.

• Retrospective should help the team decide what to improve next.

• Refinement should help the team and Product Owner decide what is clear enough, valuable enough, small enough, and evidence-backed enough to move forward.

This lens is powerful because it connects Agile practices to the actual outcomes.

The last thing teams need is more events. What they need is better moments of alignment, learning, and adjustment.

How to run the Audit

The 4-test audit works best when teams run it on themselves.

Start here:

Have the team list every recurring Agile practice it currently follows: events, artifacts, reporting habits, and meetings that exist because the framework says so. Get the list visible before evaluating anything.

Then:

take each practice and run it through the 4 tests.

Aim for an honest conversation.

Then:

Mark each practice as Keep, Retire, or Rebuild.

• A practice that passes all 4 tests earns Keep.

• One that the team cannot honestly defend against even a single test earns Retire.

• One that still addresses a real problem but whose current form is no longer serving that purpose earns Rebuild.

Then:

• Pick one practice from the Retire list and stop doing it for the next four weeks.

• Pick one from the Rebuild list and commit to redesigning it around the original problem it was meant to solve.

Run both experiments simultaneously.

Then:

After a month, review:

• whether learning improved,

• whether decisions got faster, and

• whether the team has better evidence about what their users actually need.

Use that review to decide whether to continue, extend, or revise.

The most Agile thing you can do

The most Agile thing a team can do in 2026 may be to stop protecting its practices from inspection.

Agile is twenty-five years old.

That is long enough for an idea to move from radical proposal to industry standard to inherited assumption.

The Manifesto’s authors were trying to articulate principles that would help teams navigate uncertainty and learn from their work. The practices that grew up around those principles deserve the same scrutiny that Agile teams are supposed to apply to everything else.

The question to bring back to your team is this:

If we were designing how we work today, with everything we now know, would we choose this practice?

If the answer is yes, keep it. If the answer is no, or if nobody can remember why the answer should be yes, that is the conversation the team has been waiting 25 years to have.

Show your support

Every post on Winning Strategy takes 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Further Reading

• Hybrid Agile. What is it?

• Parameters for Agile Assessment (With Data Collection Template)

• First Principles of Scaling Agile Practices

Connect With Me

• Product Output Vs Product Outcome

• Coaching Model and Mindset For Scrum Masters. What to Coach and How to Coach your Team?

• I spotted 9 problems in a healthy-looking team backlog

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.

Leave a comment

Thank you for the question.

Many Scrum Masters are asking the same question right now:

Where should AI help the team, and where should people stay in charge?

Teams already use AI for many things. That can save a lot of time and reduce admin work.

But AGILITY depends on judgment. It depends on context, trust, and shared understanding.

So the question is: how do we decide how much to depend on AI?

How to decide:

1. What work AI does independently

2. What work remains fully human-owned

3. What work needs human review

Agile teams could benefit from a delegation model for AI (download below), and this post offers exactly that.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Q: “Hi Vibhor, I’m a Scrum Master and I’m seeing more AI tools being introduced for things like meeting summaries, backlog analysis, reporting, metrics, and even drafting retrospective insights. I’m wondering what this means for my role in 2026 and further. If AI can take over some of the administrative and analytical work, what skills should I focus on developing?”

This is a question I expect more Scrum Masters to ask over the next few years.

And I think it is an important one.

Because AI is not arriving at the edges of agile work. It is moving directly into activities that many Scrum Masters have traditionally spent a significant amount of time doing.

An AI tool can summarize a Daily Scrum.

• It can turn a two-hour workshop transcript into action items

• It can analyze a backlog and identify duplicate stories, unclear acceptance criteria, dependencies, and possible risks

• It can generate sprint reports

• It can identify patterns in cycle time, throughput, blocked work, and carryover

• It can review six months of retrospective notes and suggest recurring themes

• It can draft stakeholder updates

• It can even suggest retrospective questions based on what happened during the Sprint

So I do not think Scrum Masters should dismiss the concern by saying:

“AI can never replace the human element.”

That answer is too easy, and I hear this all the time. I used to believe it too.

In my opinion, the question we now need to ask is this:

Which parts of Scrum Master work become less valuable when AI can perform them cheaply, quickly, and at scale? And which parts become more valuable?

And this is what we will discuss in this post.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Thank you for the question.

The first thing I tell every experienced Scrum Master is that you are not starting from zero.

SAFe is built on top of Scrum, not instead of it.

Your team-level practices like Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and the Product Backlog don’t disappear in SAFe. They remain the engine room of delivery.

What SAFe does is add layers of coordination around that engine room so multiple Scrum teams can work together toward a shared, larger goal. So instead of learning SAFe as something new, try learning it as Scrum+.

The simplest mental model to adopt here is this:

• Scrum = how one team plans, builds, and inspects its own work

• SAFe = how multiple Scrum teams synchronize their planning, building, and inspecting so they can deliver value together

Every time you meet a new SAFe concept, the question you ask is this:

“What Scrum concept is this scaling up?”

Having said that, let’s look at how you can approach SAFe step by step, connect it with your Scrum Master experience, and build confidence without getting lost in the terminology.

Let’s get started.

Subscribe now

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Understanding new SAFe roles, events, and artifacts

Rather than memorizing the glossary, map each new SAFe element to something you already do.

Also…

This mapping helps reduce anxiety.

SAFe has more layers because it is dealing with more complexity. But many ideas are not completely new. They are scaled versions of things you already understand.

Where to start learning?

One reason SAFe feels overwhelming is that it introduces all the above concepts at once. The mistake many people make is trying to learn everything with equal importance.

I would learn SAFe in layers instead.

1. Start with the team level

Begin with the parts closest to your current Scrum Master role.

At the team level, you will still see things that are familiar to you:

• Agile Teams

• Scrum Masters or Team Coaches

• Product Owners

• Iterations

• Team Backlogs

• Iteration Planning

• Daily Stand-ups

• Iteration Reviews

• Iteration Retrospectives

This is your comfort zone. Start by asking.

“How is my Scrum Team expected to operate inside SAFe?”

2. Then understand the Agile Release Train

The next important concept is the Agile Release Train (ART).

An ART is a long-lived team of Agile Teams. Instead of one Scrum Team working independently, several teams are aligned to a shared mission, product, value stream, or solution.

The ART introduces roles such as:

• Release Train Engineer

• Product Management

• System Architect

• Business Owners

• Multiple Product Owners

• Multiple Scrum Masters or Team Coaches

RTE is someone who facilitates and supports the train in a way similar to how a Scrum Master supports a team, BUT at the ART level.

This does not mean the RTE is simply a “Scrum Master of Scrum Masters.”

No!

But the service, facilitation, coaching, and impediment-removal mindset is the same.

3. Then learn the planning and feedback events

Once you understand the ART, focus on (the major) cadence-based events.

For example:

• PI Planning

• ART Sync

• System Demo

• Inspect & Adapt

These events help multiple teams align, coordinate, review integrated work, and improve together.

As a Scrum Master, you already know the value of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. SAFe adds larger-scale versions of planning, synchronization, review, and improvement.

4. Finally, learn portfolio and enterprise concepts

Do you absolutely need to learn about these?

Yes and No.

Do not start with portfolio terms unless your role requires them immediately. But do start your learning on these.

Concepts like:

• Lean Portfolio Management

• Portfolio Kanban

• Epics

• Strategic Themes

• Value Streams

• Enterprise Architecture

These concepts are important, but they may not be the first things a team-level Scrum Master needs to master.

Learn what is closest to your daily work first. Then expand outward.

Avoiding overwhelm from SAFe terminology

SAFe has a lot of terminology. Some of it is useful.

Don’t make it a vocabulary exam for yourself

I want you to treat every term as an answer to a practical scaling problem.

When you connect terminology to the problem it solves, the terms become less intimidating.

Term → Purpose → Problem it solves → How it connects to Scrum

For example:

PI Planning → Align multiple teams → Reduces dependency and priority confusion → Similar in spirit to Sprint Planning, but across teams and a longer horizon.

This makes learning sense.

Moving from team-level Scrum to scaled agility

This is more a mindset change than a knowledge change.

As a Scrum Master, your accountability has largely been to one team. In SAFe, your team’s success is now tied to the TRAIN’s success.

Now:

1. you’ll coordinate more with other Scrum Masters and the RTE around dependencies

2. your Sprint Goals will need to visibly connect to the train’s PI Objectives, and

3. you’ll start asking not just “is my team improving?” but “is my team improving in a way that helps the train deliver?”

That means paying attention to:

• Cross-team dependencies

• Shared goals

• Integration challenges

• Release constraints

• Architectural decisions

• Business priorities

• Capacity across teams

• Risks that affect multiple teams

• Flow of work across the ART

• Communication between Product Owners

• Alignment between teams and stakeholders

A Scrum Master in a scaled environment should still protect team health and agility, but not in a way that isolates the team from the larger system.

Knowing what changes and what stays the same

When moving from Scrum to SAFe, it is important to understand that not everything changes.

SAFe needs strong Scrum Masters because scaling weak agility only creates larger weak agility.

If teams do not understand collaboration, ownership, feedback, quality, and continuous improvement, scaling will not solve that problem.

Best practices for new SAFe Scrum Masters

Once you’ve got the structural pieces of SAFe sorted, the roles, the events, and the cadence, the real work begins.

Understanding the framework gets you in the room; how you operate within it is what actually makes you effective as a Scrum Master at scale.

The following practices will help you stay true to what made you a good Scrum Master in the first place, even as your scope of influence grows. Here’s where to focus your energy.

1. Focus on outcomes, not ceremonies

A common pitfall in SAFe adoption is becoming event-driven.

These are NOT enough.

This is where your Scrum Master coaching becomes powerful.

2. Build relationships beyond your team

In Scrum, you already work with the team and Product Owner.

In SAFe, you need to build relationships with other Scrum Masters, the RTE, Product Management, System Architects, Business Owners, and other teams.

Your influence expands through relationships.

A scaled environment depends heavily on collaboration. The better your relationships, the easier it becomes to remove impediments, resolve dependencies, and create alignment.

3. Use communities of practice

SAFe environments often have Scrum Master CoPs. I talked about these in my last post:

If you have these CoPs available in your organization, you must use them actively.

You do not need to learn SAFe alone.

4. Keep the Agile values alive

The danger in any scaled framework is that people may prioritize process compliance over Agility.

Your role is to keep bringing the conversation back to values and outcomes with the help of these questions:

That is the heart of your contribution.

So… how to learn SAFe as a NEW SAFe Scrum Master?

DO NOT abandon Scrum. Expand your perspective.

Scrum gives you a strong foundation in empiricism, facilitation, team coaching, continuous improvement, and value delivery. SAFe adds structures for alignment, planning, coordination, and improvement across multiple teams.

So do not try to learn SAFe as a huge collection of terms.

Learn it as a set of answers to scaling questions:

• How do multiple teams align?

• How do they plan together?

• How do they manage dependencies?

• How do they demonstrate integrated progress?

• How do they improve the larger system?

• How do they connect team execution to business outcomes?

If you approach SAFe this way, it becomes much less overwhelming.

Show your support

Every post on Winning Strategy takes 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Further Reading

1. How To Be A Proactive Scrum Master?

2. Role of Scrum Master in SAFe

3. Duties of a Release Train Engineer

Connect With Me

• Product Output Vs Product Outcome

• Coaching Model and Mindset For Scrum Masters. What to Coach and How to Coach your Team?

• I spotted 9 problems in a healthy-looking team backlog

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.

Leave a comment

Thank you for the question.

Most Communities of Practice start with good intent. Someone creates a calendar invite, names the group, adds the Scrum Masters and POs, and then waits for learning to emerge.

But this is NOT enough to make a Community of Practice valuable.

A Community of Practice becomes valuable when people feel (not think, FEEL):

• “This helps me solve MY problems.”

• “I learn things here that I can use immediately.”

• “People like me are dealing with similar challenges.”

• “This is not another status meeting.”

• “I have a reason to come back.”

If your Scrum Master and PO CoP have irregular attendance and low-impact conversations, the issue is usually how you have designed that CoP.

The community has probably become a meeting rather than a community.

I have a few suggestions on how to fix this.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Thank you for the question.

I have seen this happening, especially in technically strong teams.

Many teams are good at building things, but not always connected to why those things matter. The team is not engaging with the product problem or the business outcome.

In such teams, Sprint Planning is a conversation about workload. There is no discussion about the purpose.

This is not uncommon. And it does not mean the team does not care.

Often, it means the team has been operating in an organization where delivery is more visible than value. They have been trained (unintentionally, of course) to focus on output rather than outcome.

How do you help such a team?

Let’s find out.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Thank you for the question.

Joining an existing Agile Release Train as a new RTE (or a hybrid SM/RTE) is really quite different from launching one.

An existing Train has a heartbeat, a history, habits, good and bad, and there are people who are watching to see what you are going to change. The worst thing you can do in your first 30 days is walk in with a checklist of SAFe best practices and start "fixing" things.

Everyone feels pressure to “add value” quickly when they join a new team.

Resist that urge.

In your first 30 days, you are NOT going to fix the Train… or anything

The first thing you are going to do is understand the system you have joined, build trust, and discover where your help is actually needed.

And this is exactly what we are going to cover in this post.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

A Scrum Master recently asked me a question that many people working in SAFe or multi-team environments will recognize:

“Hi Vibhor, even though we are part of one ART, teams mostly work in isolation. They have their own priorities, their own ways of working, and limited collaboration with other teams. When cross-team issues come up, people say, ‘That’s not our scope.’ How do I create more ART-level collaboration?”

This is a very genuine problem.

Many Agile Release Trains are designed as a single train in theory, but they do not always behave as such in practice. Teams attend the same PI Planning. They share the same calendar of ART events. They even report progress through the same tools. But day-to-day, they operate in silos.

Each team has its own backlog, Product Owner, priorities, pressure, stakeholders, and way of working. Over time, the team boundary becomes stronger than the ART identity.

So when a problem appears between teams, the first response is not always, “How do we solve this together?”

It is often:

“That is not our scope.”

And that one sentence tells us a lot about the system.

The problem is that we've given our teams autonomy without giving them a shared purpose large enough to make collaboration feel worth it. And that's a structural problem disguised as a cultural one.

For my own clarity, if nothing else, I want to work through this question carefully, pulling in the frameworks, thinkers, and concrete practices I've found most useful. I've organized this from the most foundational problem to the most actionable fix. If you've navigated this yourself and have something to add, I'd genuinely love to hear it.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Thanks for the question.

This is one of those situations where a Scrum Master can either become a process police or a coach.

Because on the surface, the problem looks simple:

The team said they would finish something, and they did not.

But if you stay only at that surface level, the conversation quickly becomes unhelpful.

The Product Owner starts thinking, “The team is not serious about its commitments.”

The team starts thinking, “The PO does not understand how complex this work is.”

Leadership starts thinking, “Maybe this team is not performing.”

And the Scrum Master gets pulled into the middle, trying to defend the team while also acknowledging that, yes, the problem is real.

This is exactly the moment where your coaching stance matters.

Repeated carryover is a delivery problem. It is ALSO a signal, “Something about the way we plan, refine, slice, collaborate, or communicate is not working.”

The Scrum Master’s job is not to protect the team from accountability. It is also not to allow accountability to become blame.

The job is to help the team and stakeholders inspect the practices being followed honestly, learn from them, and make the next Sprint a little better than the last one.

Let’s look at where the real issues may be hiding.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

It sounds like a simple question, but it exposes a more serious dilemma about the Scrum Master role.

• Some people see the Scrum Master as a facilitator

• Some see them as a process curator

• Some expect them to be an Agile expert

• And some believe they should only ask powerful questions and never give answers

So where does coaching really fit?

Let’s find out.

Subscribe now

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

The short answer

Scrum Masters do coach, but they are not only coaches.

They coach:

• the Developers on self-management, collaboration, and continuous improvement;

• the Product Owner on product thinking, backlog management, stakeholder collaboration, and value delivery;

• the organization on process adoption, empirical thinking, removing impediments, and creating an environment where teams can succeed.

However, Scrum Masters also need to use other “stances” when coaching is not enough.

A Scrum Master may need to:

• teach Scrum when people do not understand it;

• mentor a new Product Owner or Scrum Master;

• facilitate events and conversations;

• advise leaders on organizational impediments;

• challenge behaviours that reduce transparency or accountability;

• support the team in resolving conflicts;

• help protect the team from harmful interference;

• help the organization inspect and adapt.

So the question is not simply, “Do Scrum Masters coach?”

The question is:

“When should a Scrum Master coach, and when should they use another stance to help the team?”

Why does the dilemma exist?

The dilemma exists because coaching can be misunderstood in two opposite ways.

1. “A Scrum Master is not a coach; they are just there to ensure Scrum happens.”

This view reduces the Scrum Master to a process administrator.

In this mindset, the Scrum Master:

• schedules events;

• manages Jira boards;

• reminds people about events;

• tracks action items;

• asks for updates;

• reports progress;

• removes small blockers.

This is a narrow and weak interpretation of the role.

A Scrum Master is not just a Scrum event coordinator. They help people and organizations become more Agile through the Scrum framework.

That requires coaching, facilitation, teaching, mentoring, and organizational change work, etc.

2. “A Scrum Master should only coach and never tell, teach, or advise.”

This is the opposite misunderstanding.

Some Scrum Masters interpret coaching as:

• never giving direction;

• never offering suggestions;

• never correcting misunderstandings;

• never teaching Scrum;

• never challenging bad practices;

• only asking open-ended questions.

This can also be ineffective.

For example, if a team does not understand the purpose of the Sprint Goal, it may not be helpful to only ask:

“What do you think the Sprint Goal is for?”

At some point, the Scrum Master may need to teach the purpose of a Sprint Goal, give examples, and then coach the team on how to create better ones.

1. Pure coaching is powerful when the person or team has enough awareness, knowledge, and ownership to discover their own solution

2. But when there is a knowledge gap, a misunderstanding of Scrum, or an organizational constraint, other stances may be more useful

What does “coaching” mean for a Scrum Master?

For a Scrum Master, coaching is the act of helping individuals, teams, and organizations improve their own capability to think, decide, collaborate, and adapt.

In short, they coach them to be Agile (a word no one likes to use anymore).

It is less about giving answers and more about helping people:

• see reality more clearly;

• inspect their assumptions;

• understand the impact of their behaviour;

• discover options;

• make decisions;

• take ownership;

• learn from outcomes;

• improve continuously

A Scrum Master coaches by creating awareness and enabling better choices.

For example, instead of saying:

“Your Daily Scrum is too much like a status meeting.”

They coach by saying:

“What is the team trying to achieve in the Daily Scrum?”

“Who is the conversation for?”

“How does the current conversation help the team inspect progress toward the Sprint Goal?”

The Scrum Master is not taking ownership away from the team. They are helping the team inspect and adapt.

Coaching is different from teaching, mentoring, and facilitating

One reason this becomes confusing is that Scrum Masters often use multiple stances on the same day.

#1 Coaching

Coaching helps people discover their own insights and solutions.

Important: Coaching is useful when the team has the “ability” to solve the problem but needs reflection, awareness, or courage. It is NOT useful when the team can’t solve the problem on their own.

#2: Teaching

Teaching is useful when there is a knowledge gap.

Important: Teaching is appropriate when people do not yet understand the framework, concepts, or principles.

#3: Mentoring

Mentoring is sharing experience to help someone grow.

Important: Mentoring is useful when the Scrum Master has relevant experience, AND the other person is open to learning from it.

#4: Facilitating

Facilitation helps a group have an effective conversation or decision-making process.

Important: Facilitation is essential to help teams navigate VUCA

#5: Advising or consulting

Sometimes the Scrum Master provides direct advice, especially to leaders or the organization.

Important: You gotta do what you gotta do. What you need here is COURAGE.

The Scrum Master as a coach to the team

Scrum Masters coach the Scrum team toward self-management and continuous improvement.

You are not the team’s manager. It means the Scrum Master helps the team own more of its work system.

A strong Scrum Master helps the team move from dependence to ownership.

The goal is for the team to become increasingly capable.

The Scrum Master as a coach to the Product Owner

Scrum Masters also coach Product Owners.

This is important because many Scrum challenges are, in fact, product ownership challenges.

For example, if the Product Owner comes to Sprint Planning with a list of unrelated user stories, the Scrum Master may coach with questions like:

“What is the product outcome we want this Sprint to move toward?”

“How do these items connect to the Product Goal?”

“What trade-off are we making if everything is priority one?”

“What feedback do we need from stakeholders before the next Sprint?”

Here, the Scrum Master is helping the Product Owner become more effective, not taking over product decisions.

The Scrum Master as a coach to the organization

This is often the most neglected part.

Scrum Masters do not only serve the Scrum Team. They also serve the larger organization.

They coach the organization to understand that Scrum is not just a team-level process. “It exposes” organizational problems.

A Scrum Master coaches leaders and stakeholders by making these issues visible and helping the organization inspect and adapt.

This may involve uncomfortable conversations.

For example:

“The team is being asked to commit to a Sprint Goal, but new urgent work is being inserted every few days. What do we want the team to optimize for: focus or responsiveness?

This is coaching at the system level.

Coaching does not mean being passive

One common anti-pattern is the passive Scrum Master.

They say:

“The team is self-managing, so I should not interfere.”

But self-management does not mean abandonment.

A Scrum Master should not control the team, but they should actively help the team see and improve its system.

Coaching is not silence, avoidance, or politeness.

Scrum Master must lovingly but firmly challenge the team.

The maturity of the team matters

The Scrum Master’s coaching stance should evolve with the team.

New team

A new team may need more teaching, structure, and facilitation.

The Scrum Master may explain Scrum events, clarify accountabilities, introduce working agreements, and help people understand the basics.

Growing team

A growing team may need more coaching and mentoring.

The Scrum Master can begin asking more reflective questions, helping the team own decisions and improve collaboration.

Mature team

A mature team may need more systemic coaching.

The Scrum Master may focus less on event mechanics and more on

• organizational impediments,

• product flow,

• stakeholder alignment, and

• continuous improvement

The same Scrum Master behaviour that helps a new team may limit a mature team.

For example, heavily facilitating every event may be useful early on, but over time, it may prevent the team from taking ownership.

To balance it all, you need Stance Agility

Effective Scrum Masters need stance agility.

They should be able to move between stances intentionally:

Choose the right stance for the moment.

My observation:

• Some Scrum Masters over-teach because coaching feels slow

• Some over-coach because direct teaching feels uncomfortable

• Some over-facilitate because conflict feels risky

• Some over-help because they want to be needed

What you need is to develop a “range.”

Example #1: Daily Scrum becomes a status meeting

A weak response:

A coaching response:

A teaching response may also be useful:

The Scrum Master may need both teaching and coaching.

Example #2: Product Owner brings too many priorities

A coaching response:

A mentoring response:

An advising response:

Example #3: Team does not improve after Retrospectives

A coaching response:

A facilitation response:

Example #4: Manager assigns work directly to team members

A coaching response to the manager:

A teaching/advising response:

A facilitative response:

Bottomline

So, do Scrum Masters coach?

Yes. Absolutely.

But the more honest answer is this:

Scrum Masters coach in service of self-management, empiricism, and continuous improvement, not as a performance of the role, but as one of several stances they use to help teams and organizations become more effective.

• A Scrum Master is not a meeting facilitator

• A Scrum Master is not a process police

• A Scrum Master is not only a professional coach

A Scrum Master is a change agent who uses coaching, teaching, mentoring, facilitation, and direct challenge in whatever combination the team and organization need to help people get consistently better at delivering value together.

Show your support

Every post on Winning Strategy takes 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Further Reading

1. Agile Coaching Lifecycle

2. How to Measure the Effectiveness of Agile Coaching?

3. Team Trust Coaching Cards

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.

Leave a comment

Here’s how I used to run retrospectives when I was a Scrum Master.

I used to go around the room, one person at a time, thinking that equal airtime meant equal participation.

Round-robin format. Everyone gets a turn.

There were two people on the team who never had anything to share.

My question: “Priya, you’ve been quiet. What do you think?”

Their reply: “No, all good. I agree with what was said.”

Let me be clear.

Round-robins are good.

But!

They create compliance. And compliance is not the same as candour.

Like most facilitators, I believed that if everyone got a turn to speak, the retro was fair. After years of coaching teams and sitting in on hundreds of retrospectives, I learned that:

Quiet people don’t need more turns to speak. They need fewer reasons to stay silent.

In this post, I’ll show you how to run a retro where quiet people contribute without being put on the spot… without round-robins.

Let’s get started.

Subscribe now

Read more

I genuinely believed that showing executives I knew Agile would earn their respect.

Then, in a meeting after a quarterly review, one of the SVPs pulled me aside and asked:

“I still don’t know what you actually do.”

As a new Scrum Master, I was quite impulsive, so I replied:

“I need to explain the framework better. I need to help the team understand Agile.”

Now… I don’t think I need to tell you what happened next.

I didn’t get the next question. The executive dropped the conversation and walked away.

That’s why I cringe now when I see new Scrum Masters walking into executive meetings armed with Agile vocabulary and walking out wondering why no one takes them seriously.

Let me be clear.

Knowing your Scrum matters.

But!

Agile fluency is not the same as executive credibility. And confusing the two is one of the most expensive mistakes a new Scrum Master can make.

After years of working alongside executives across banking and tech, I learned that credibility in this (or “any”) role is not granted. It is built through a specific set of behaviours that have almost nothing to do with how well you know the Scrum Guide.

In this post, I’ll share 7 such behaviours.

Because if someone who once bored executives into silence can learn to become the person they actually rely on, so can you.

Let’s get started.

Subscribe now

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

I used to think the Daily Standup was the one thing that didn’t need to change when a team adopted AI.

I was so very WRONG!

When a Scrum team adopts AI in its workflow, the Daily Standup SHOULD ALSO evolve.

The purpose of the Daily Scrum remains the same:

To help the team inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours.

But since AI changed, how work is done, where risks appear, and what the team needs to discuss, it has introduced some new risks, such as:

• low-quality generated output,

• hidden assumptions,

• security concerns,

• prompt dependency,

• duplicated work, and

• reduced shared understanding.

So…

When this is the situation… how do you guide your teams so the Daily Standup remains focused, transparent, and outcome-oriented?

Let’s find out.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

I’ve been on both sides of this conversation.

I’ve been the person trying to diplomatically explain that the whole system is broken. And I’ve been the person hearing that feedback, mentally preparing my defence before the other person finishes their sentence.

Believe me… neither side is fun.

As a Scrum Master, you have the exact same problem.

You are expected to “diagnose” but criticized for your “diagnosis.”

Stories are not ready. Sprint work spills over. Priorities change mid-sprint. Developers wait for answers that don’t come. Stakeholders bypass the Product Owner entirely.

From where you are sitting, the diagnosis of the above problems is obvious:

The system around product decision-making is broken.

But the moment you say “this is a systems problem” out loud, you risk damaging your relationship with the Product Owner if you’re not careful in your delivery.

So, how do we fix the delivery?

Let’s find out.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

“Not everything that counts can be counted, and not everything that can be counted counts.”
— Albert Einstein

Agile teams often have no shortage of metrics.

The problem is not the lack of data. Agie teams have a lot of it.

The problem is that they have too much disconnected data, which means they don’t have a shared understanding of what that data is supposed to help them decide.

This is the situation where metrics are discussed without changing anything. Everyone can point to numbers, but nobody is sure what they mean or whether they matter.

That is metrics overwhelm.

And it is dangerous because it makes a team “appear” data-informed without helping the team make better decisions.

Subscribe now

If you’re new, then you missed the posts below in the past few weeks

1. The Retrospective that never lead to action

2. How to deal with part time team members with split allocations

3. 11 things Atlassian Rovo AI can't do yet

4. How to define TRULY URGENT mid sprint interruptions?

5. 9 built in ROVO AI Agents for Scrum Masters

6. How would I help my team resolve impediments without depending on me?

Here’s what “metrics overwhelm” looks like

You may recognize metrics overwhelm when conversations sound like this:

“Our velocity is down, but our throughput is up. Is that good or bad?”

“The dashboard says we’re behind, but the team says things are fine.”

“Leadership wants more predictability, so we added more metrics.”

“We measure customer adoption, but nobody knows what adoption level would count as success.”

“We report sprint completion every two weeks, but the product decisions are still based on stakeholder pressure.”

“We have all the data in Jira, Productboard, GA, Amplitude, Power BI, and spreadsheets, but we still don’t know what to prioritize.”

The team collects metrics at three different levels, but mixes them together:

1. Delivery metrics: Are we delivering work smoothly?

2. Product metrics: Are users benefiting from what we deliver?

3. Business metrics: Is the organization getting the result it needs?

Each category is useful. But confusion begins when people expect one type of metric to answer another type of question.

Velocity cannot tell you whether customers value the feature. NPS cannot tell you whether the team has too much work in progress. Revenue cannot tell you whether your refinement process is healthy. Cycle time cannot tell you whether you are solving the right problem.

When the metric is used to answer the wrong question, the conversation becomes confusing.

Why does metric overwhelm happen?

The simple answer is UNCERTAINTY.

Metrics overwhelm usually happens because people are trying to reduce uncertainty.

Product work is uncertain. Agile delivery is uncertain. Stakeholder expectations are uncertain. Customer behaviour is uncertain. Technical complexity is uncertain.

So teams and leaders reach for measurement to build confidence.

The problem is that metrics are often added one by one, without removing old ones and without clarifying their purpose.

None of these is bad on its own. In fact, most are reasonable.

But together, without a decision framework, they become cognitive clutter.

The team ends up with a pile of signals but no way to separate what is important from what is merely available.

What’s a useful metric?

A useful metric should help someone make a better decision.

If a metric does not influence a decision or trigger a conversation, or guide an experiment, it is probably not a useful metric.

One of the questions you can ask your team is:

“What decision will this metric help us make?”

If nobody can answer, pause before adding it to the dashboard.

For example:

The metric itself is not the insight.

Insight comes from interpreting the metric in context and deciding what to do next.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

How Product Owners get overwhelmed by metrics

For Product Owners, metrics overwhelm often shows up as pressure to prove progress.

Stakeholders want to know:

In response, the Product Owner collects more and more data to defend decisions.

But a Product Owner’s job is not to produce enough metrics to satisfy everyone’s curiosity.

Their job is to create enough CLARITY to support better product decisions. That means the Product Owner needs to distinguish between:

The above metrics are not the same.

A roadmap confidence metric may help stakeholders understand uncertainty.

A feature usage metric may help the Product Owner decide whether to iterate.

A cost-of-delay discussion may help prioritize backlog items.

A cycle time metric may help the team improve flow.

A business outcome metric may help evaluate whether the product strategy is working.

When all of these are thrown into a single dashboard without a clear intent, the Product Owner becomes a curator of confusion.

How Scrum Masters get overwhelmed by metrics

For Scrum Masters, the danger is slightly different.

Scrum Masters often care deeply about team health, flow, continuous improvement, and transparency.

Metrics can be very helpful here. But they can also become a subtle form of micro management if not handled properly.

The above metrics can support excellent conversations.

But if the team feels the numbers are being used to judge them, they will adapt their behaviour to protect themselves.

Metrics should help the team see the system more clearly, not make individuals feel watched.

So how do we handle this?

The best way to escape Metrics Overwhelm is by clarifying the decisions first.

Start by asking:

“What decisions do we need to make on a regular basis?”

Then, for each decision, identify the smallest set of metrics that can inform it.

For example:

This approach prevents the collection of metrics that serve no purpose.

Use a “metrics menu,” not a metrics buffet

If you have ever had a buffet at a restaurant, you know that buffets encourage people to pile everything onto the plate.

A menu forces choice.

Agile teams benefit from a small, intentional set of active metrics, which may change depending on the team’s focus.

Below are a few examples of such a metric menu:

#1: If the team is struggling with the delivery flow

Those may still matter, but they are not the immediate requirement for improvement.

#2: If the team is validating a new product idea

The goal is learning, not maximizing output.

#3: If the team is improving quality

The goal is to restore confidence and reduce the demand for failure.

#4: If the team is scaling stakeholder trust

The goal is better alignment and expectation management.

Separate health metrics from target metrics

One distinction is between target metrics and health metrics.

Target metrics

These represent what you are actively trying to improve.

Examples:

• Increase activation

• Reduce onboarding drop-off

• Improve cycle time

• Reduce escaped defects

• Increase trial-to-paid conversion

• Reduce customer churn

• Improve forecast reliability

These metrics are central to business decisions.

Health metrics

These are things you monitor to make sure improvement in one area is not damaging another.

Examples:

• Team morale

• Defect rate

• Customer complaints

• System performance

• Support volume

• Work in progress

• Technical debt indicators

For instance, if the target is to increase feature delivery speed, quality and team health should become health metrics. Otherwise, the team may “succeed” by burning people out.

If the goal is to reduce defects, delivery throughput may become a health metric; otherwise, quality improvement could lead to paralysis.

This distinction helps reduce overwhelm because not every metric gets equal attention.

Some metrics are steering the current change.

Others are guardrails.

How to turn metric data into insight

Data becomes insight when it changes understanding.

Here’s how the progression happens:

1. Data: “Cycle time increased from 4 days to 9 days.”

2. Information: “The increase is mostly in review and testing.”

3. Insight: “Stories are reaching review before acceptance criteria are clear, causing rework.”

4. Action: “We will improve refinement and add earlier QA/product review.”

5. Learning: “If review wait time drops, we know the change helped.”

Many teams stop at step 1 or 2.

They display the data and assume the insight is obvious.

It usually is not.

Here, Scrum Masters can add huge value by facilitating the movement from number to meaning to action.

Qualitative insights

Metrics tell you what is happening.

They often cannot tell you why it is happening.

For instance, if activation is low, analytics may show where users drop off. But they may not explain whether users are confused, unconvinced, distracted, lack permissions, are using a workaround, or are solving a different problem entirely.

If the velocity drops, Jira may show fewer story points completed. But it may not explain whether the issue is unclear priorities, technical debt, dependencies, interruptions, illness, low morale, or overcommitment.

This is why metrics should be paired with qualitative learning:

You don’t have to choose between data and conversation. Use data to focus the conversation.

Metric Purpose Statement

For each metric you keep, define a short purpose statement.

Use this format:

We measure [metric] to understand [question] so that we can decide [decision/action].

Examples:

We measure cycle time to understand where work slows down so that we can improve flow and reduce unnecessary waiting.

We measure feature adoption to understand whether users are trying the new capability so that we can decide whether to improve, promote, or stop investing in it.

We measure escaped defects to understand where quality issues reach customers so that we can strengthen our feedback and testing practices.

We measure team sentiment to understand whether our way of working is sustainable so that we can address overload before it becomes burnout.

We measure activation rate to understand whether new users reach first value so that we can improve onboarding and early product experience.

If you cannot complete the statement, the metric probably does not belong in the active dashboard.

How to clean the current metrics you have

Conduct a workshop with the Product Owner, Scrum Master, Developers, and relevant stakeholders.

Step 1: List your current metrics

Collect every recurring metric the team reports, reviews, or tracks.

Do not debate yet. Just list them.

Step 2: Mark the audience

For each metric, identify who it is for:

• Team

• Product Owner

• Scrum Master

• Stakeholders

• Leadership

• Customers

• Operations

• Other teams

Step 3: Identify the decision

Ask:

“What decision does this metric support?”

If the answer is unclear, mark it.

Step 4: Identify the action threshold

Ask:

“When would this metric cause us to act?”

For example:

• If the cycle time increases for three consecutive weeks, we investigate blockers

• If adoption is below target after launch, we run customer interviews

• If the number of escaped defects increases, we review testing and release practices

• If WIP exceeds the agreed limit, we stop starting and start finishing

Step 5: Remove, archive, or downgrade

Not every metric needs to be deleted.

Some can be:

• If a metric helps us make a current decision, keep it active (Eg: Cycle Time)

• If it protects us from side effects, make it a guardrail (Eg. Escaped defects)

• If it helps us investigate a problem, keep it diagnostic (Eg. Time spent in each workflow status)

• If it has historical value, archive it (Eg. Adoption of last quarter’s reporting feature)

• If nobody uses it, remove it (Eg. Number of backlog items created)

This gives the team permission to stop carrying old measurement habits forever.

The honest truth about Metrics

Data doesn’t create clarity on its own. Clarity comes from a team that has agreed on what they’re trying to achieve, identified the signals that show whether they’re getting there, and built the habit of talking honestly about what those signals mean.

Metrics are a language.

And like any language, they only communicate something when both parties understand the words.

Further Reading

1. How to Discuss Metrics With Your Team?

2. Metrics for Project Based Scrum Teams

3. How Agile Metrics are Getting Misused - And How Can You Fix It?

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.

Leave a comment