11 Ways Scrum Masters Can Help Speed Up Feature Delivery?
Different ways you can help your team move faster.
Welcome to the 🔥 free edition 🔥 of Winning Strategy: a newsletter focused on enhancing product, process, team, and career performance. This newsletter shares insights gained from real-world experiences that I gathered working at Twitter, Amazon, and now as an Executive Product Coach at one of North America's largest banks. If you’d like to become a paid member, see the benefits here, and feel free to use this expense template to ask your manager.
"A team is only as fast as the obstacles they face."
I’ll never forget the first time I worked as a Scrum Master with a team that was completely stuck.
On paper, they had everything going for them:
a skilled team,
clear goals, and
all the right Agile tis toks in place
But week after week, their progress crawled along. Frustration was mounting, and I just couldn’t figure out why.
I sat in on their standups, retrospectives, and planning sessions, thinking, “What am I missing?”
Then, one day, during a 1:1, a team member opened up to me:
"It’s not that we don’t want to move faster. It’s that we’re constantly running into roadblocks, big and small. It’s like we’re trying to sprint through mud."
That’s when it hit me: my role as a Scrum Master wasn’t to push the team harder or enforce processes better. My role was to clear the mud.
And here’s the thing: most Scrum Masters don’t realize this.
They think their job is about facilitating meetings and keeping the team on schedule. But that’s only part of it. The real job is to remove friction — those little (or major) roadblocks that slow your team down without you even noticing.
You’re not just a meeting manager.
No!
You’re the enabler of high performance.
But how exactly do you do that?
In today’s post, I’ll share 11 common reasons why teams stumble and actionable steps you can take to eliminate each one.
Because when you remove friction, your team doesn’t just move faster — they flourish.
Let’s get started.
If you’re new, here’s what you missed in the last few weeks
#1 Unclear Requirements
A few years ago, I observed a Release Train within a portfolio in which one of the Scrum teams was proving to be an obvious bottleneck.
So I decided to dig deeper.
No matter how hard they worked, they always seemed to miss their Sprint Goals.
The developers were frustrated, the Product Owner was stressed, and stakeholders lost patience. One day, during a Sprint Review, a team member finally said what everyone was thinking:
"We’re building things, but we’re never sure if we’re building the right things."
That was it!
The root cause of all the missed goals, rework, and frustration boiled down to one thing: unclear requirements.
In December last year, I got myself a 1000-piece puzzle. It’s like a family tradition. We all sit together and try to beat our previous year’s time solving it.
My wife is a genius at putting puzzle pieces together, so I decided to give her a challenge. I said,
“I bet you can’t solve the puzzle without looking at the picture on the box.”
She looked at me, and without thinking it through, she accepted the challenge to prove me wrong.
And she did! I never win challenges against her.
But it took her 10 days in multiple sittings, where it takes one or a maximum of 2 days to finish the puzzle.
The point?
Unclear Requirements are like assembling a puzzle without seeing the picture on the box.
The team “wastes time:”
making assumptions,
debating interpretations, and
going back to rework things that didn’t meet expectations
It’s a massive form of friction.
As a Scrum Master, it’s your job to help eliminate this friction.
And you do this with the help of the following:
conducting refinement sessions
helping the team create a Definition of Ready
helping the team create a Definition of Done
promoting the use of acceptance criteria
teaching the team how to split user stories
coaching the PO to champion the “why”
coaching the team to collaborate with the stakeholders
Your job isn't to write better requirements yourself.
Your job is to create conditions where clarity emerges naturally through collaboration.
When requirements are clear, your team stops building the wrong things.
And when you stop building the wrong things, you start delivering the right things faster.
Additional Reading:
#2 External Dependencies
A few years ago, during one of my first projects as a Scrum Master, I worked with a team that constantly struggled to meet its commitments.
Every Sprint Planning session was ambitious and optimistic, yet every Sprint Review was filled with:
“We couldn’t finish this because we were waiting on X” or
“We’re blocked because Y didn’t deliver what we needed.”
Dependencies can feel like invisible walls around your team. They waste time, cause delays, and create frustration. And the worst part? If you ignore them, they don’t go away—they multiply.
As a Scrum Master, your job is to help your team remove these walls.
Here’s how:
help your team map dependencies
make dependencies visible (to stakeholders during reviews)
escalate the issue to the appropriate channels (e.g. Scrum Masters of dependency team, Program Managers)
work with the PO to help negotiate timelines and prioritize dependencies with stakeholders
build relationships with peers in the dependency teams
help your team get the tools they need to do the job
help your team split independent user stories
help your team create a contingency plan
Your job is to make dependencies visible and help the team develop strategies to handle them.
When dependencies are well-managed, your team stops playing the waiting game.
And when you stop waiting, you start delivering faster.
#3 Frequent changes in priorities (scope creep)
Let’s say you’re planning a road trip.
You've got your route mapped out. You're excited to hit the road. But then, every hour, someone changes the destination. "Let's go to the mountains!" "The beach is just a little far. Can we stop for selfies?" “Let's make a quick stop at the premium mall."
Scope creep, or the constant shifting of priorities, is like these never-ending detours. It can throw off the team's momentum and make it impossible to reach the finish line.
This form of friction can leave your team demoralized and burnt out.
A few weeks back, I wrote a post sharing one of my friends' complete processes for handling frequent mid-sprint interruptions.
You can check it out here: When Management Interferes
Also, if you’re a paid member of Winning Strategy, you can access the Sprint Interruption Tracker (shown below) for free.
I have designed this tool to help you collect the necessary data to present your case to the stakeholders.
Other than preparing a case in your favour, do your due diligence. Here’s what I mean:
help the PO create a well-defined, prioritized Product Backlog
conduct multiple small refinement sessions to catch what’s missed
help stakeholders understand that frequent changes hurt delivery
when faced with a request for a last-minute change, don't let it go without asking questions. Is it truly urgent? What is the impact on the team? Is there a better way to address the need?
help your team create a buffer (not ideal, but it works)
make your team’s work visible
Your job isn't to prevent changes (after all, Agile is built to embrace change).
Your job is to help the team, and stakeholders understand the impact of those changes and make informed decisions.
#4 High Work In Progress (WIP)
If your team uses Kanban (and even if they don't), you're probably familiar with the term "Work In Progress" or WIP.
Once, I worked with a team that had an interesting problem. Their board was full of stories - nearly all were "in progress." When I asked how things were going, the Scrum Master said proudly:
"Everyone's busy. We're working on everything!"
That was exactly the problem.
I've seen this pattern repeat itself across many teams. They believe being busy equals being productive. They start many items but finish few.
They juggle too many balls at once
You might keep them in the air for a while, but eventually, they all come crashing down.
High WIP creates a cognitive load.
Your team members try to keep track of multiple tasks and lose focus on what's important.
As a Scrum Master, here's how you address this friction:
educate the team on the negative impact of high WIP
help your team understand the cost of context-switching
experiment with different WIP limits
coach team members to swarm unfinished user stories
use Cumulative Flow Diagram during stand-ups to identify bottlenecks
use huddles (fantastic techniques to increase team cohesiveness)
Don’t force WIP limits.
Help the team understand why limiting WIP matters and guide them in finding their flow.
When WIP is controlled, your team stops starting and starts finishing.
If you’re enjoying this, hit that like button ❤️ and subscribe.
#5 Technical Debt
This is an interesting one.
Teams like to talk about it but never do anything about it.
In one of the retrospectives I attended, a developer shared a story that stuck with me:
"We keep taking shortcuts to meet deadlines. Now, making even small changes takes forever because we have to navigate through a maze of quick fixes. We're paying interest on a loan we'll never be able to pay back."
Technical debt is a hidden tax on your team's velocity.
It accumulates slowly, often invisibly, until one day, your team spends more time working around problems than solving them.
When there is technical debt, you hear things like:
"We need to rewrite this entire module."
"This should be a simple change, but the code is so fragile."
"We can't add new features until we fix the architecture."
As a Scrum Master, you can measure technical debt (that’s right), make it visible, and help create space to address it.
Not sure how to do that?
I wrote a post on how to do that (no coding knowledge required) a few months ago.
Check it out here: How do you measure technical debt in Scrum?
What else can you do?
make technical debt visible to stakeholders and help them understand the cost of ignoring it and the benefits of addressing it
work with the PO to include technical debt items in the backlog and prioritize them
coach the team to use quality metrics from the start
include quality in the definition of done
ask questions so the team can share technical concerns during refinement and planning
rotate the role of one person in the team who refactors the code
When technical debt is visible and managed, your team stops drowning in workarounds.
And when you stop drowning, you start swimming towards better solutions…faster.
#6 Bottlenecks in specific roles
I bet you’ve heard the term — “The Oracle.”
The one who knows “everything.”
We also call them the SMEs.
Every complex decision, every major code review, every architecture question - all go through them.
Well, guess what?
Unlike movies, Oracles are humans. They, too, get sick. And when they do, the team’s work comes to a halt.
This is what we call a single point of failure - when one person becomes so critical that their absence creates a complete bottleneck.
I've seen this pattern with QA specialists, DevOps engineers, and senior developers. The team becomes dependent on their expertise, and work stops flowing when they're not available.
As a Scrum Master, here's how you address this friction:
Identify roles that rely on a single individual. Use team discussions, retrospectives, or even informal chats to uncover these bottlenecks
Promote brown bag sessions to share knowledge
Use pair programming, technical discussions, and learning sessions
Work with leadership to reward knowledge-sharing
Use documentation. Not as a substitute for knowledge sharing. But to help reduce reliance on a single person when they’re unavailable
If the bottleneck stems from a lack of resources (e.g. the team only has one DevOps engineer or QA specialist), escalate the issue to leadership
Have a plan in place for when a key individual is unavailable
Your job is to help the team spread knowledge.
When knowledge is shared, your team stops waiting for heroes.
And when you stop depending on heroes, you start building a stronger team.
#7 Insufficient backlog refinement or planning
Last quarter, I watched a team start their sprint planning. The Product Owner pulled up a story:
"Build user authentication system."
That was it!
No acceptance criteria. No technical discussions. Nothing.
About halfway through the sprint, the team discovered that they had greatly underestimated the complexity. They hadn't considered important security requirements like password recovery, multi-factor authentication, or other features.
The sprint failed.
It was obvious. They were cooking a complex dish without a recipe.
When this happens, we start to hear things like:
"We don't know enough to start this."
"This story is bigger than we thought."
"We keep finding hidden requirements during the sprint."
Here's how you can help:
Make refinements “regular”
Assign 5 min. for technical discussions for each user story
Break down large user stories
Work with the Product Owner to ensure stories are “ready” well before sprint planning
Occasionally invite stakeholders (when needed)
Teach your team to ask PO the right questions
Help them explore edge cases, technical implications, and dependencies during refinement
Make the Definition of Ready “clear-er”
Make a “Ready” column on the Scrum board to help PO see which items need more attention
Teach them how to write a good “Acceptance Criteria”
When refinement is thorough, your team stops discovering and starts delivering.
And when you stop starting with assumptions, you start finishing with confidence.
#8 Blockers or impediments that are not addressed promptly
"Blocked - waiting for response from external team."
I once saw this note on a Jira card that hadn't moved for two weeks. When I asked about it, the response was telling:
"Oh yeah, that's been stuck for a while. We've sent some emails..."
Sometimes, developers mention blockers during standups, but nothing happens afterward.
Sometimes, they’d sit on an issue for days, hoping it would resolve itself.
Other times, they’d try to push through on their own, wasting hours or days on something that could’ve been solved quickly with the proper support.
This happens when blockers or impediments aren’t addressed promptly. They may seem small initially, but they quickly become productivity killers.
By the way, Blockers and Impediments are not the same. Checkout the post below to learn the actual difference:
I've watched teams normalize blockers, treating them as unavoidable facts of life rather than urgent problems to solve. They update their status daily: "Still blocked," but take no meaningful action to resolve the situation.
Here's how you address this friction:
Make blockers unignorable. Use your daily standup to discuss not just what's blocked but what actions are being taken to unblock
Add a “Blocked” column to your Kanban or Scrum board to make impediments visible
Work with management to create clear escalation paths for resolving blockers, especially with external teams
Track patterns. If the same type of blocker keeps appearing, a systemic issue likely needs addressing
Coach team members to raise blockers as soon as they encounter them
Help the team escalate blockers to leadership, negotiate with stakeholders, or bring in external support
Blockers don’t always require outside help. Facilitate team discussions to brainstorm solutions. For example, if a developer is waiting on a code review, encourage others to prioritize it so the work can move forward
Sometimes, blockers arise from a lack of foresight. Coach the team to expect possible impediments during Sprint Planning or backlog refinement. For example, if a task depends on input from another team, ensure that communication happens early
Build strong relationships with these stakeholders to quickly escalate and resolve issues when they arise
Use Retrospectives to reflect on how blockers were handled
Your job isn't to solve every blocker yourself.
Your job is to ensure blockers don't become accepted as “normal.”
When impediments are actively managed, your team stops waiting and starts moving. And when you stop accepting “blocked” as normal, you start finding ways through.
#9 Lack of stakeholder alignment
"We need all these features by the end of the quarter."
"But why isn't this done yet? It seemed simple."
"Can't you add more people to speed things up?"
If these statements sound familiar, you're dealing with one of the most challenging frictions in agile teams: misaligned expectations.
I once worked with a team where the stakeholders expected a complete platform redesign in three months. The team knew it would take at least six. Instead of addressing this gap early, both sides avoided the uncomfortable conversation.
The result?
Mounting pressure, deteriorating trust, and ultimately, a project that satisfied no one.
As a Scrum Master, here's how you bridge this gap:
Calculate your team’s capacity and make it visible
Build transparency into progress (burndown charts, etc.)
Don't wait for problems to surface. Create regular touchpoints with stakeholders where expectations can be discussed openly
Help stakeholders understand trade-offs. When they ask for faster delivery, show them how it impacts quality, scope, or team sustainability
Teach the PO how to manage stakeholders
During Refinement, work with the PO and team to define a goal that reflects the highest priority for the upcoming Sprint. Share this goal with stakeholders during the Review
Use tools like product roadmap and release plan to give stakeholders a clear view of what’s being worked on and how much progress is being made
Teach the PO how to push back constructively when stakeholders impose tight deadlines. For example:
break the work into smaller parts and deliver the most valuable features first
discuss the risks of sacrificing quality for speed, such as accumulating technical debt or creating rework
offer data-driven alternatives, like extending the timeline or de-scoping non-essential work
Your job is to help create a realistic alignment between expectations and capabilities.
When expectations are aligned, your team stops feeling pressured to promise the impossible.
If you have any questions, don’t forget to leave a comment.
#10 Ineffective Scrum Events
I once heard of a team that used to conduct 45-minute-long Dailys.
For a team of six people. That's not a standup - that's a sitdown.
Ineffective events are more than just time-wasters; they're motivation killers. They drain energy, reduce engagement, and make people question the value of agile itself.
As a Scrum Master, here's the bare minimum on how you make events count:
1. Set clear objectives for each event.
Remind the team of the purpose of each ceremony:
Sprint Planning: Define what the team will deliver and how they’ll do it
Daily Standup: Synchronize and identify blockers to keep work flowing
Sprint Review: Showcase completed work and gather stakeholder feedback
Retrospective: Inspect and adapt processes to improve
2. Timebox all events
Long meetings drain energy and focus. Timebox each ceremony to ensure discussions don’t drag on unnecessarily. For example:
Sprint Planning: 2 hours for a 2-week Sprint.
Daily Standup: 15 minutes.
Sprint Review: 1-2 hours.
Retrospective: 1 hour.
These are just suggestions. Once the timebox is decided make sure the team adheres to it.
3. Use Agendas to Stay Focused
Before each event, prepare an agenda and share it with the team. Agendas help keep meetings structured and prevent aimless discussions.
4. Make Daily Standups Collaborative
If standups feel like status updates, shift the focus to collaboration. Instead of asking, “What did you do yesterday?” try asking, “What can we do to move work forward today?”
5. Sprint Planning:
Ensure stories are properly refined beforehand
Come prepared with prioritized, ready stories
Split the session if needed (capacity planning / task breakdown)
6. Retrospective:
Create action items
Track and follow up on previous action items
Create a safe space for honest discussion
Create a ballet box where issues are posted anonymously
7. Sprint Review:
Rehearse demos in advance
Focus on value, not technical details
Work with stakeholder to ensure participation
Keep it demo-driven, not slide-driven
Little things make big difference.
These events aren’t just meetings—they’re opportunities to inspect, adapt, and deliver value.
When events are focused, engaging, and productive, the team spends less time in meetings and more time delivering meaningful results.
#11 No visibility into progress
"Is that feature done?"
"I thought someone else was working on that."
"We have no idea if we'll hit our sprint goal."
These statements reveal a common friction: work happening in a black box.
I once consulted with a team where work status lived in developers' heads and private to-do lists. When the PO asked for updates, a chain of interrupting questions was triggered across the team.
Without clear visibility, teams operate on assumptions, and stakeholders operate on hope.
Here’s what you can do:
1. Make sure the board is visible to everyone
Whether your team uses physical boards or digital tools (like Jira, Trello, or Azure DevOps), ensure that all work is tracked and visible. A clear board with columns such as “To Do,” “In Progress,” “Blocked,” and “Done” helps everyone see the status of stories at a glance
2. Make sure the board is updated regularly
Sometimes, you have to ask the team multiple times. Make sure when a task moves from “In Progress” to “Done,” it’s reflected on the board
3. Use Burndowns and BurnUps
Burndown and burnup charts provide a visual representation of progress during a Sprint. Share these charts with the team and stakeholders during standups or reviews
4. Track the Definition of Done
Visibility isn’t just about seeing where tasks are—it’s also about knowing whether they’re actually “done.” Ensure the team adheres to the Definition of Done for every story. This prevents surprises, like finding out that “completed” work still needs reviews, testing, or bug fixes
5. Use Dashboards
Many Agile tools offer dashboards that visualize progress, team velocity, and work distribution. Set up dashboards and share them with the team and stakeholders
Your job is to make work and progress so visible that questions answer themselves.
When work is visible, your team stops wondering and starts collaborating.
The Journey Forward
While these challenges can feel overwhelming, remember that every great Scrum team once struggled with these same issues.
The journey from friction to flow isn't about perfection – it's about continuous improvement. Each small step forward, each tiny improvement, compounds over time to create remarkable results.
Your role as a Scrum Master isn't to solve every problem or to create a frictionless environment overnight.
No!
Your mission is to help your team recognize these patterns, understand their impact, and develop the capability to address them.
As you move forward, keep these final thoughts in mind:
what works for one team might not work for another
the solutions will evolve as your team matures
sometimes, the best action is simply to make the friction visible
The mark of a great Scrum Master isn't the absence of problems – it's the presence of continuous learning and adaptation.
What frictions are you seeing in your team today?
Start there.
Take one small step. Then another. That's how great teams are built.
Connect With Me
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.
Thank you for simplifying this Vibhor.
Pure gold - thank you Vibhor 🙌😊