How would I fix a team's unstable velocity problem?

🎁 AI Prompt Included: To guide you through solving such problems step by step.

Jun 15, 2025

Welcome to the 🔥 free edition 🔥 of Winning Strategy: A newsletter focused on enhancing product, process, team, and career performance. If you’d like to become a paid member, please see the benefits here, and feel free to use this expense template to request approval from your manager.

Nothing derails a sprint (and your mind) quite like a team’s unpredictable velocity.

I remember the first time I saw a team’s burndown chart zigzag all over the place. Everyone was frustrated, including developers, product owners, stakeholders and me. We kept wondering what could be wrong. Are we missing something obvious?

If you’ve been in this situation before, then welcome to the club.

Unstable velocity is not a numbers problem. It’s a signal. A symptom.

Sometimes it points to hidden blockers. Sometimes it’s the way work is planned or how the team collaborates. And sometimes, it’s simply a symptom no one knows how to decode.

Fortunately, there is a way out.

There’s a systematic way to solve such problems.

In this post, I will give you the tools that will help you break down the problem with your team.

PLUS, there is a detailed AI Prompt included below to guide you through troubleshooting from start to finish.

Let’s get started.

If you’re new, here’s what you missed in the last few weeks

Get the Substack App (Recommended)

I highly recommend downloading and using the Substack app. This will enable you to read the full newsletter without the length restrictions typically imposed by email clients like Gmail.

Furthermore, you will be promptly notified of the community chat discussions and educational notes I post regularly.

Available for iOS and Android

Step #1: Define the velocity problem

The first step is always CLARITY.

And you get that by clearly defining the Problem at hand.

I have already covered my favourite problem-defining tool, TOSCA, in a previous post.

TOSCA helps you break the prblem into the following 5 parts:

Trouble: What is the problem?
Owner: Who is responsible?
Success: What does success look like?
Constraints: What limits must be considered?
Actors: Who is involved or affected?

I highly recommend you check out that Free post at the link below

How to Define Problems so that Solving them Becomes Much Easier

The post also includes a handy Notion Template to help you define the problems using TOSCA.

Returning to the subject of this post, a TOSCA-defined velocity problem would look something like this:

Trouble

The development team’s velocity has decreased by 30% over the last three sprints. Sprint goals are regularly missed, and team morale seems to be dropping.

Owner

Development Team itself is responsible for improving team performance and delivery.

Note: Scrum Master facilitates the process and removes impediments, but accountability for delivery rests with the Development Team.

Success

Velocity returns to 40 story points per sprint (the historical average) within the next two sprints

Sprint goals are met at least 90% of the time for the next quarter

Constraints

1. Team size is fixed (6 members)

2. No extra hiring or budget for the current quarter

3. All work must remain remote (distributed across two time zones)

4. Product backlog order is fixed for the next sprint

Actors

1. Development Team Lead (accountable for delivery)

2. Scrum Master (facilitates Scrum and removes impediments)

3. Development Team Members (implement work)

4. Product Owner (manages backlog and priorities)

5. Stakeholders (expect timely delivery)

6. QA/Testers (shared resource)

Now, let’s analyze this TOSCA definition and determine the best approach to solving this problem.

Step #2: Analyze the problem definition

This is where we move from identifying the problem to understanding why it is happening and what kinds of solutions are realistic.

Let’s break down the TOSCA definition from above.

First:

Notice that this is an operational problem.

The team has not built the wrong feature. The problem is about how. How the team is working together.

This is a team dynamic (or process) issue, not a product issue.

Second:

The outcome we want is crystal clear and measurable. We’re talking numbers, velocity, and % sprint goal completion. No ambiguity here.

Third:

The constraints are confirmed. No new hires. No extra budget.

The backlog order is fixed (at least for now). The team is remote, split across time zones. This means we can’t just throw money or people at the problem. We need to work smarter with what we’ve got.

Fourth:

All the actors are internal.

Everyone involved: developers, Scrum Master, Product Owner, stakeholders, has a clear role and a stake in the outcome. No mysterious “external blockers” or unknown dependencies.

What does all of this tell us?

Because we need a solution that fits this reality:

It must work within the existing team and process constraints
It should allow for small, safe experiments. Nothing risky or disruptive
It needs to empower the team. The folks doing the work need to own the improvements

In other words, we’re after practical, team-level changes that we can implement RIGHT NOW.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Join Vibhor Chandel’s subscriber chat

Available in the Substack app and on web

Step #3: Find the best approach to solve this problem.

Now that the problem is clearly defined and analyzed, it’s tempting to jump straight to solutions like:

Change the estimation method!
Add more meetings!
Cut out meetings!

But!

Rushing into making changes without knowing why the velocity dropped in the first place may lead to serious risks. For example, it may lead to:

Wasting time on changes that don’t matter
Making things worse than they are
Missing the root cause

We need a systematic approach. Something that we can use to test small improvements, learn from the results, and adapt based on what works.

The simplest approach in this category is PDCA.

I have found the Plan-Do-Check-Act approach to be perfect for solving team-level problems.

Why? For these 3 reasons:

It focuses on small incremental changes
It’s all action. No endless analysis paralysis
It’s a natural fit for Agile: try something small, see what happens, adapt, repeat

A Word of Caution:

PDCA is only as good as the problem you're trying to solve.

It is powerful, no doubt. But it only works if you’re solving the root cause.

If your “Plan” (P of PDCA) targets a symptom instead of the root cause, you’ll end up moving in circles.

For example:

If you think the issue is estimation, but the real problem is unclear requirements, tweaking estimation processes won’t help.

Step #4: Finding the root cause

Before we can apply the PDCA, we need to find the root cause of our problem.

How?

Using the 5 Whys technique.

Why the 5 Whys technique?

Because just like PDCA, it is also the simplest. No fancy diagrams or advanced facilitation skills are required.

Let’s apply the 5 Whys to our velocity problem:

Problem Statement:

“Team velocity is unstable and has dropped by 30% over the last three sprints.”

#1: Why has the velocity dropped?

Because the team is completing fewer story points each sprint.

#2: Why is the team completing fewer story points?

Because more stories are being carried over or left incomplete.

#3: Why are more stories being left incomplete?

Because tasks are taking longer than estimated, and some blockers are unresolved.

#4: Why are tasks taking longer, and are blockers unresolved?

Because communication has slowed down, especially with everyone working remotely, and the team is unclear on some requirements.

#5: Why has communication slowed and requirements clarity dropped?

Because daily standups have become rushed, and the Product Owner is less available for clarifications due to other commitments.

Root causes (there are more than 1) identified:

Rushed daily standups
Reduced availability of the Product Owner
Communication challenges due to remote work

Notice: These are process and system issues. Fixable, team-level problems. No finger-pointing. Just facts.

Step #5: Solving the problem

Now that we understand what lies beneath the surface, we can finally apply the PDCA cycle.

A. Plan (target each root cause)

Improve daily standups: Make them more focused, ensure everyone speaks, and highlight blockers
Increase Product Owner access: Schedule a dedicated “office hour” for clarifications during each sprint
Enhance remote communication: Adopt a shared team chat channel for quick questions and async updates

B. Do

Implement the new standup format for the next sprint
Product Owner commits to a fixed 30-minute Q&A slot twice a week
Set up and encourage the use of a team Slack/Teams channel for daily async updates

C. Check

After the sprint, measure:
- Has team velocity improved?
- Are fewer stories being carried over?
- Did team members report better communication and clarity?
Conduct a quick team survey on standup effectiveness and PO access.

D. Act

If metrics and feedback show improvement, standardize these changes.
If not, adjust:
- Try different standup facilitation.
- Adjust PO office hours.
- Explore other tools or ways to surface and resolve blockers.

And that’s how I would solve the team’s unstable velocity problem.

But there’s more.

You can use the AI prompt below as a guide to solving such problems.

Using AI to find solutions to common process-related problems.

This is where the prompt comes in.

Below, you’ll find an AI prompt designed for Scrum Masters and Agile teams.
Just copy and paste it into ChatGPT (or any AI tool you like), and let it guide you through the process.

Here’s how it works:

The AI will interview you about your team’s process, blockers, and recent sprint experiences
Your job? Be honest and as specific as possible with your answers
Don’t rush. The more thoughtful and detailed you are, the more valuable the insights you’ll get back

Here’s the prompt:

You are an Agile Coach Assistant. Guide me step by step through solving a Scrum team process issue using TOSCA (Trouble, Owner, Success, Constraints, Actors), 5 Whys, and PDCA. Ask one question at a time. For each step, provide an example answer that is tailored to my previous responses—starting with this Trouble example:

Step 1: TOSCA – Problem Definition
1. Trouble
Ask:
What is the main problem or challenge your Scrum team is facing?
Example: "Team velocity is unstable and has dropped by 30% over the last three sprints."

2. Owner
After I answer Trouble, ask:
Who is responsible for resolving or driving action on this issue?
Tailor the example to the Trouble provided:
Example: "The Development Team Lead is responsible for addressing issues with team velocity."

3. Success
After I answer Owner, ask:
What does a successful resolution look like? Please include measurable outcomes if possible.
Tailor the example to Trouble and Owner:
Example: "Restore velocity to 40 story points per sprint and achieve stable velocity for at least three consecutive sprints."

4. Constraints
After I answer Success, ask:
What limitations, restrictions, or boundaries must be considered? (e.g., people, budget, time, tools)
Tailor the example to prior answers:
Example: "The team size is fixed at six developers, there is no extra budget available, and everyone is required to work remotely."

5. Actors
After I answer Constraints, ask:
Who are the key people or roles involved or affected by this problem and its solution?
Tailor the example to previous answers:
Example: "Development Team Lead, Scrum Master, all developers, Product Owner, and stakeholders who rely on sprint deliverables."

Once all TOSCA fields are answered, summarize the problem definition using my inputs and confirm with me before proceeding.

Step 2: 5 Whys – Root Cause Analysis
Ask the first why, using my Trouble statement:
Why is this problem occurring?
Example: "Because the team is completing fewer story points each sprint than before."

For each of the next four whys, use my previous answer to generate a tailored example for the next why, and continue until a root cause is clear.

Step 3: PDCA – Solution Iteration (One Question at a Time with Tailored Examples)
Guide me through each PDCA phase, one question at a time, each with an example tailored to the identified root cause and previous answers.

Plan
What specific action or experiment will you try to address the root cause?
Example: "Implement structured daily standups focused on surfacing blockers early."

What is your hypothesis for how this action will improve the situation?
Example: "If we improve our daily standups, the team will identify and resolve blockers faster, helping stabilize and increase velocity."

What resources or support will you need?
Example: "The Scrum Master will facilitate, and the Product Owner will join standups three times per week."

What metric or feedback will you use to measure success?
Example: "Track number of completed story points per sprint and gather team feedback via a retrospective survey."

Do
Who will implement this action?
Example: "The Scrum Master and all team members."

What steps will be taken to implement it?
Example: "Update the standup agenda, communicate the change to the team, and start the new format next sprint."

Over what time period will you implement this action?
Example: "Trial the new standup format for two sprints."

Check
How will you collect results and feedback after implementation?
Example: "Review sprint reports in Jira and conduct a short team survey at the end of the trial period."

How will you compare actual results to your success criteria?
Example: "Compare average velocity before and after the trial, and review team satisfaction scores."

Act
Based on what you found, will you adopt, adapt, or abandon the change?
Example: "If velocity improves and feedback is positive, adopt the new standup format; if not, adapt and try additional changes."

What will you do next based on these findings?
Example: "If the change is successful, make it part of our standard process; otherwise, revisit the root cause and try a new experiment."

Once all PDCA steps are complete, provide a Solution Report summarizing the TOSCA (Trouble, Owner, Success, Constraints, Actors), Root Causes, Actions, Results, and Next Steps.

Step 4: Solution Appropriateness Check
Ask:
Does this solution seem appropriate to you? (Yes/No)

If Yes: Congratulate and suggest documenting and sharing with the team.
If No:
Ask what didn’t work, if new information has emerged, and what could be tried differently.
Repeat the PDCA cycle with the new input to create another solution report.

REMEMBER: Always use my latest responses to tailor the next examples. Only proceed to the next step after I answer the current question.

When you’re done, you’ll have a focused list of next steps, experiments to try, and new angles to explore with your team.

Show your support

Every post on Winning Strategy takes ~ 3 days of research and 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 recommend 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.