No one could tell. With 500 fairly small items, it was extremely hard—perhaps impossible—to spot an important need the backlog had overlooked.

And five hundred items is not even an especially large backlog. Plenty of organizations have backlogs 10 times that size, or even larger.

But imagine how different that conversation would have been if the team had started with 25 or 50 high-level epics. At that level, people could have looked across the product and asked:

• Are we missing an important type of user?
• Is an essential workflow absent?
• Does this reflect how we intend to position the product?
• Where are the capabilities that will distinguish us from competitors?
• Have we included features merely because similar products have them?

Once those high-level decisions had been made, the team could have decomposed the most important epics into smaller backlog items.

AI makes it very easy to skip the step of identifying and reviewing the product's high-level epics before decomposing them into stories.

Teams can jump immediately to hundreds of detailed backlog items without first considering whether those items collectively describe the right product.

Give AI a description of a product and, within minutes, it can produce hundreds of user stories. Ask again, and it will add acceptance criteria, edge cases, dependencies, and suggested priorities.

The results are often well-written and impressively thorough.

That is exactly what worries me.

A Detailed Backlog Can Create False Confidence

The danger is not that AI will produce obviously terrible backlog items. Those would be easy to spot and reject.

The greater danger is that AI will produce a large number of plausible, polished items that look complete.

The sheer volume of detail can discourage people from questioning the backlog. It is difficult to recognize what is missing when you are looking at hundreds of individual stories. It is also difficult to distinguish an essential capability from something AI included because it seemed reasonable.

A substantial backlog is not necessarily a complete backlog. And a complete-looking backlog is not necessarily a good one.

Teams need to begin at a level where they can still understand the product as a whole.

I prefer to start with a relatively small number of high-level epics identified by humans. AI can then review those epics and suggest important areas the team may have overlooked.

After the team has considered the product at that level, AI can help decompose one or two of the most important epics at a time.

That sequence is much safer than asking AI to create a comprehensive backlog in one pass.

Start with What Will Make the Product Successful

Before asking AI to generate backlog items, describe how the product is intended to succeed.

Is it an all-encompassing product that will compete by offering nearly every capability users might need? Or is it intended for a narrow audience with a few unusually valuable features?

What gap exists in the market? Why might customers choose this product instead of a competitor? Are there financial or timing goals that should affect product decisions? Which user personas or roles are most important?

This context helps AI generate suggestions that fit the intended product rather than a generic version of that product category.

Without that context, AI will often suggest the expected features. Those table-stakes features matter, but they rarely make a product exceptional. AI may miss what the Kano model calls delighters: capabilities users may not explicitly request, but that can distinguish a product from its competitors. That's as true for internal products as commercial ones — an internal tool may not have a commercial competitor, but it still competes with the current process, existing tools, spreadsheets, workarounds, and doing nothing.

Before generating any product backlog, explain:

• The outcome the product should create
• Who will use it
• How those people perform the work today
• What is slow, costly, risky, or frustrating about the current approach
• What would motivate people to adopt something new
• How the team will know the product succeeded
• Which constraints and non-goals should limit the proposed solution

For a commercial product, also explain the market opportunity, important competitors, reasons customers might choose this product, and any relevant financial or timing goals.

This strategic context is almost like acceptance criteria for the product itself. It describes what must be true for the product to be considered successful.

Start there. Then use AI to help explore how the product might achieve that success.

A Well-Written Story Can Still Be the Wrong Story

AI does not normally have firsthand evidence from interviews and observations with this product's users. Unless the team provides that evidence, AI is generating plausible features rather than demonstrated needs.

That means teams should ask more than whether an AI-generated story is clear and testable.

They should also ask:

• Does this support the way we intend to position the product?
• What evidence do we have that users need it?
• Is it necessary, competitively differentiating, or merely plausible?
• Could we omit it and still succeed?
• Do the acceptance criteria describe what matters, or merely what was easy for AI to specify?

That last question is particularly important.

Imagine a team building a receipt-scanning expense application. The product is intended to succeed by making expense submission nearly effortless: a user should be able to photograph a receipt and finish the expense with almost no typing.

Without that context, AI might generate acceptance criteria such as:

• Users can upload JPG, PNG, and PDF receipts.
• Files larger than 10 megabytes display an error.
• Users can enter the merchant, date, amount, and category.
• Required fields are validated before submission.
• A confirmation appears after the expense is saved.

Those criteria are specific and testable. They also describe a fairly ordinary upload form.

Acceptance criteria that protect the product's intended advantage might instead address:

• Extracting the merchant, date, amount, and category from a photograph
• Asking users to correct only information the application cannot determine confidently
• Detecting duplicate receipts
• Suggesting a sensible expense category
• Identifying potential policy violations before submission

The first set describes a feature that works. The second helps describe why someone would prefer this product.

But without strategic context and human review, it can easily produce the first: sensible functionality for a generic product.

Humans need to determine what will make this particular product valuable.

AI Should Support Co-Creation, Not Specification Handoffs

Suppose a product owner works alone with AI, creates polished stories and acceptance criteria, and then hands them to the team.

That process may be fast, but it loses many of the benefits of co-creating a solution.

Users understand their goals, frustrations, environment, and current behavior. Customers — who are not always the users — bring purchasing concerns, organizational needs, and their own definitions of value.

Developers, testers, designers, and other team members contribute technical possibilities, risks, constraints, alternative solutions, and ways to test an idea incrementally.

The product owner brings product direction and responsibility for making tradeoffs. The product owner ultimately decides what enters the product backlog, but the best product owners make those decisions in consultation with users, customers, and the team.

These are not isolated responsibilities that should be performed through a sequence of handoffs. They are different types of knowledge brought into the same product conversation.

Co-creation helps teams avoid solving the wrong problem. It surfaces information no one person would have. It creates ownership and trust. It also makes the eventual solution more adaptable because more people understand the reasoning behind it.

AI can contribute to that process. It can propose possibilities, uncover assumptions, identify missing cases, and ask useful questions.

But it has neither accountability for the product nor firsthand knowledge of its particular users and context.

Shared understanding exists among people. AI can help create the conditions for it, but it cannot replace the conversations through which it develops.

Treat AI-Generated Stories as First Drafts

After a product owner and perhaps the team have reviewed an AI-generated story, it can enter the product backlog.

From there, it should be treated like any other first-draft backlog item. It must be prioritized. It may need more discussion and additional detail. It may need to be split, revised, or removed.

I also think it is useful for AI to include initial acceptance criteria when it generates a story. Producing those criteria is inexpensive, and they often help a reader understand the intended behavior.

But they remain first drafts.

As an item rises in priority and gets closer to being brought into a sprint, the team should critique its acceptance criteria during backlog refinement.

AI can help with that. It can look for omissions, overlaps, inconsistencies, and missing examples. It can be especially useful when a story needs concrete examples of calculations or business rules.

Our Story Critic AI skill reviews backlog items and identifies whether they appear adequately detailed for refinement or a sprint.

Even if an AI tool says a story appears ready, the team must still apply its own judgment.

AI can supplement backlog refinement. It cannot eliminate the need for it.

If anything, easy AI-generated detail makes collaborative refinement more important.

Use AI to Expand Your Thinking

"Trust but verify" is good advice for using AI, but it doesn't go far enough.

A team should not merely check whether AI wrote a backlog item correctly. It should determine whether the item deserves to be built at all.

Start with users, product positioning, desired outcomes, and a small number of high-level epics. Ask AI to question, supplement, and expand the team's thinking. Let it propose missing items, decompose selected epics, draft acceptance criteria, and critique stories during refinement.

Then apply human judgment.

Talk with users and customers. Co-create solutions with the whole team. Refine the most important items as they get closer to implementation.

AI can write backlog items.

Only people working and learning together can decide whether those items describe a product worth building.

The answer is sometimes uncomfortable: the organization is making real teamwork hard.

A Scrum team may be told to own the sprint goal, collaborate across specialties, and deliver a valuable increment together. But the same team may also be staffed part-time, measured individually, interrupted constantly, and pulled back into functional silos whenever priorities shift.

When that happens, people adapt. They protect their own tasks. They focus on what their manager will notice. They avoid helping too much outside their specialty because they are already overcommitted. They attend the Scrum events, but inside the sprint they still behave like individuals.

That is frustrating for leaders, Scrum Masters, product owners, and team members. But it is rarely solved by telling people to collaborate more.

Teams work like individuals when the system around them rewards individual behavior.

Each of these problems has a leadership move that can make teamwork more likely.

Part-Time People Create Part-Time Teams

A team cannot build much shared ownership when half its members are assigned somewhere else.

Many organizations staff Scrum teams by spreading specialists across several teams. A database expert is 25% on one team, 25% on another, and available “as needed” to everyone else. A UX designer supports three teams. A tester is shared across a product area. A product owner is responsible for multiple teams and spends much of the sprint in meetings away from the people doing the work.

The organization may see this as efficient. It keeps scarce skills busy. It avoids hiring before demand is clear. It gives each team access to the people it needs.

But the cost shows up inside the sprint.

Work ends up waiting on whoever has the specific skill. Questions don’t get answered right away. Decisions happen without the right people in the room. The team plans like everyone is fully available, then runs into the reality that no one really is. People also start to avoid taking on anything outside their lane because their time is already stretched across too many commitments.

Part-time assignment creates part-time ownership.

A Scrum team does not need every specialist full time in every situation. But when key skills are routinely split across too many teams, the team learns to manage around scarcity instead of working together. The result looks less like teamwork and more like reservation scheduling.

What Leaders Can Change

Leaders do not have to make every specialist full time on every team. But they should make shared assignment visible and intentional.

If a database expert or UX designer is supporting three teams, the team should plan with that constraint in mind instead of pretending the person is fully available. Better still, reduce the number of teams each person supports so real teamwork has a chance to form.

Part-time assignment should be a conscious tradeoff, not the default staffing model.

Individual Utilization Undermines Team Delivery

Many leaders want teams to finish valuable work, but still manage as if the goal is to keep every individual fully utilized.

That changes how people behave.

If everyone is expected to stay busy all the time, people will start more work. If people are judged by the tasks they complete, they will protect their tasks. If specialists are rewarded for throughput inside their specialty, they will optimize their specialty even when the team needs something else.

This is how a team ends up with five people busy and six product backlog items nearly done.

A developer finishes coding and starts something new because the tester is not ready. The tester eventually catches up and finds issues, but the developer is now deep into another item. The product owner gets questions late, when the team has fewer options. By the end of the sprint, everyone has worked hard, but too little is actually done.

The problem is not effort. The problem is what the organization has optimized.

Scrum teams need room to help each other finish. That may mean a developer reviews tests, a tester joins a story discussion earlier, or a programmer helps clarify an acceptance criterion instead of starting another item. On a utilization chart, that may look less efficient. In delivery, it is often exactly what the team needs.

I first noticed this dynamic at 16 while working at a fast food restaurant. On a typical night shift, Nikki ran the register, Mark handled the grill, and I moved between roles wherever I was needed.

If the line got long, I helped Nikki. If burgers backed up, I helped Mark. No one cared whether I stayed in my assigned role. We cared whether customers got their food.

Scrum teams need more of that same thinking. The goal is not to keep every person busy in their specialty. The goal is to finish valuable work.

What Leaders Can Change

Leaders who want real Scrum teams need to care less about whether every person appears busy and more about whether the team is finishing valuable work.

Notice when someone helps another specialty, joins a discussion early, reviews work before being asked, or helps finish one important item instead of starting another. Those behaviors may not look as efficient on an individual utilization report, but they are often what makes team delivery possible.

Functional Reporting Can Pull People Away from Team Ownership

Functional departments are not automatically a problem. Specialists need mentoring, standards, career paths, and peers who understand their discipline.

But functional reporting can undermine Scrum teams when people receive stronger signals from their department than from their team.

A tester may be told the team owns quality, but evaluated by a QA manager on testing-specific output like the number of defects logged. A UX designer may be assigned to a Scrum team, but judged by design deliverables created before the sprint starts. A developer may be encouraged to help the team finish, but rewarded for completing assigned programming tasks.

Those signals shape behavior.

People naturally pay attention to the people who influence their reviews, raises, promotions, and reputation. If the team says, “Help us finish this,” but the functional manager says, “Why are your design deliverables late?” the functional manager wins.

Functional leadership should strengthen the Scrum team, not pull people away from it.

What Leaders Can Change

Leaders do not need to eliminate functional expertise. They do need to align it with team outcomes.

Functional managers can still protect professional standards, mentor specialists, and build capability. They just need to reward those skills when they help the Scrum team deliver, not only when they produce functional deliverables.

A manager of testers can still care deeply about testing skill while encouraging testers to collaborate earlier. A UX leader can still protect good design practice while helping designers work more closely with product owners and developers. An engineering manager can still mentor programmers while rewarding behavior that helps the whole team deliver.

Interruptions Make Sprint Goals Optional

A sprint goal is supposed to help a Scrum team focus.

It gives the team a reason to make tradeoffs. It helps the team decide what matters most when surprises happen. It gives the daily scrum something more useful to inspect than a list of individual tasks.

But leaders can accidentally teach teams that sprint goals are optional.

They do it by inserting urgent work mid-sprint. They do it by asking for “just a quick favor.” They do it by escalating around the product owner. They do it by treating sprint plans as flexible whenever the request comes from someone senior enough.

The team learns quickly.

If outside work can appear at any moment, the sprint goal becomes less meaningful. If priorities change whenever a leader asks, the team stops treating sprint planning as a real plan. If people are pulled away from the sprint often enough, they protect themselves by thinking in terms of personal tasks rather than team outcomes.

Interruptions are sometimes necessary. Production issues happen. Customers need help. Leaders learn new information. Scrum does not require pretending the world is stable for a full sprint.

A sprint goal cannot guide behavior if leadership treats it as a suggestion.

What Leaders Can Change

Make interruptions visible and intentional.

When urgent work appears, involve the product owner. Talk about the effect on the sprint goal. Make the tradeoff clear. Do not pretend the team can absorb every interruption without cost.

Leaders should also recognize that interrupting one person often interrupts the team’s ability to finish. Pulling a tester, developer, designer, or product owner away may look like a small request from the outside. Inside the sprint, it can leave important work waiting.

Focusing Only on Individual Assignments Limits Teamwork

Some leaders unintentionally keep Scrum teams working like individuals by asking individual-assignment questions:

• Who owns this?
• Who is assigned to that?
• What is everyone working on?

Those questions are sometimes useful. Work needs clarity. People need to know who is taking the next step. A team without any ownership can drift.

But assignment thinking becomes a problem when it dominates the way leaders talk about work.

The team begins to think in terms of personal ownership instead of shared delivery. A product backlog item becomes a collection of assigned tasks. Each person tries to finish their part. If the item gets stuck after that, it becomes someone else’s problem.

The better leadership question is often:

“What is the team trying to finish next?”

That question changes the conversation. It points people toward flow, risk, and shared responsibility. It makes it easier for the team to notice that three people are busy starting new work while one important item is waiting for help.

Leaders shape team behavior through the questions they ask. Asking only about individual assignments reinforces individual work.

What Leaders Can Change

Leaders can still ask who is taking the next step. But they should also ask what the team is trying to finish, where work is waiting, and what is putting the sprint goal at risk.

Those questions keep the focus on team delivery instead of individual activity. They also help the team see when starting more work would be less useful than finishing something already underway.

Frequent Reshuffling Prevents Real Teams from Forming

Scrum teams need time together to become good at working together.

They need to learn each other’s habits, strengths, preferences, and blind spots. They need to discover how to split work, coordinate in the daily scrum, involve the product owner, and help one another finish. They need a few sprints together to improve.

Frequent reshuffling resets that learning.

Some organizations treat teams as temporary staffing pools. People are moved from one initiative to another whenever a new priority appears. A team starts to gel, then loses a developer. A product owner finally gets aligned with the team, then is assigned to a higher-priority effort. A tester is moved because another team is behind.

Each move may make sense locally. Together, those moves prevent teamwork from forming.

A stable team will still change over time. People leave. Products shift. Skills need to move. But leaders should recognize the cost of churn. Every change forces the team to relearn how to work together.

When leaders want teamwork but keep changing the team, they are asking for maturity without giving the team time to mature.

What Leaders Can Change

Treat team changes as real costs.

Sometimes moving people is necessary. But it should be a conscious tradeoff, not an administrative convenience. Before moving someone, leaders should ask what learning, trust, domain knowledge, and coordination ability the team will lose.

Stable teams are not guaranteed to become great teams. But unstable teams rarely get the chance.

Reward Systems Tell the Truth

Culture is often clearest in the reward system.

A leader may say teamwork matters. But if recognition goes to individual heroics, people notice. If promotions favor the person who saves the sprint at the last minute, people notice. If managers praise starting more work but ignore helping behavior, people notice.

Teams pay attention to what gets rewarded.

This is especially dangerous when the rewarded behavior looks useful in the moment. The person who works late to fix a problem may deserve thanks. The specialist who jumps across three teams to unblock everyone may be genuinely helpful. The manager who reassigns people quickly may appear decisive.

But if those patterns become normal, the organization rewards heroics over sustainable teamwork.

Real Scrum teams should not depend on a few people saving the day. They should make work visible early, reduce handoffs, limit work in progress, and collaborate before problems become emergencies.

What Leaders Can Change

Leaders can reinforce teamwork by noticing different behavior:

• Who helped finish an item that was at risk?
• Who raised a problem early?
• Who simplified the work instead of expanding it?
• Who helped another specialty without taking over?
• Who protected the team’s focus?

Those are the behaviors that create stronger Scrum teams.

A useful test for leaders is this: Are we asking teams to behave as teams while staffing, measuring, interrupting, and rewarding them as individuals?

Scrum Teams Need Leadership Support

A Scrum team can improve many things on its own. It can run a better daily scrum. It can swarm on risky work. It can limit work in progress. It can involve the product owner earlier. It can inspect handoffs in the sprint retrospective.

But some obstacles sit outside the team’s control.

A team cannot make itself stable if leaders keep moving people. It cannot fully own the sprint goal if leaders interrupt the sprint without tradeoffs. It cannot optimize for team delivery if managers keep rewarding individual utilization. It cannot collaborate across specialties if functional silos remain stronger than team ownership.

That is why leaders matter.

The goal is not to blame leaders for every team problem. The goal is to make the system visible. When Scrum teams continue working like individuals, leaders should ask what the organization is doing to make that behavior reasonable.

Sometimes the team needs training.

Sometimes the leader needs to remove a constraint.

Often, both are true.

Working on a Scrum Team helps the whole Scrum team, and the leaders who support it, build a shared understanding of how Scrum is supposed to work in practice. That shared understanding matters because real teamwork is created by the team and protected by the organization around it.

The people attend sprint planning together. They meet every day for the daily scrum. They hold sprint reviews and sprint retrospectives. They may even work from the same product backlog and use the same sprint board.

From the outside, it looks like Scrum.

But inside the sprint, work still moves from person to person the way it always has. An analyst clarifies the requirement. A developer codes it. A tester waits until something is ready. A product owner gets pulled in late to answer a question that should have been discussed earlier. Everyone is busy, but the team is not really working as a team.

Work starts, waits, changes hands, gets nearly done, and then carries into the next sprint.

That is one reason Scrum can feel disappointing. The organization has adopted the events, roles, and artifacts, but the people doing the work still behave like a group of individuals connected by meetings.

Scrum depends on real teamwork. Without it, the mechanics of Scrum are still there, but many of the benefits are lost.

A Scrum Team Is More Than People Assigned to the Same Sprint

Putting people on the same Scrum team does not automatically make them a team.

A real Scrum team shares responsibility for delivering a valuable increment. The product owner, Scrum Master, and developers have different accountabilities, but they are working toward the same outcome. They are not merely contributing separate pieces and hoping those pieces come together at the end.

This is important because Scrum exposes problems quickly. If people are working independently, Scrum will make that visible. Work piles up. Dependencies appear. Items stay nearly done. Testing gets squeezed into the end of the sprint. Daily scrums become status updates. Sprint goals become words on a board instead of something that guides decisions.

When that happens, the problem is rarely that the team needs more meetings. The problem is usually that the team has not learned how to work together around shared goals, shared constraints, and shared delivery responsibility.

Handoffs Slow Teams Down

One sign that a Scrum team is still working like a group of individuals is the amount of handoff inside the sprint.

One team recently took this to an extreme. UX designers owned a story until the design was complete. It then moved to a database engineer to assess any database impact before being handed off to a programmer. The programmer finished all coding before passing it along to a tester.

Each person did their part, but no one owned getting the story finished.

A little handoff is unavoidable. Specialists still matter, and people bring different skills to the team. But when work routinely moves from analyst to developer to tester to reviewer in a predictable sequence, the team has recreated a small waterfall process inside the sprint.

That creates delay. Someone waits for clarification. Someone waits for code. Someone waits for testing. Someone waits for feedback. Each wait may seem small, but together they stretch the time it takes to finish anything.

Handoffs also create misunderstanding. Each person receives a partial view of the work and makes decisions based on that view. By the time the whole team sees the item together, it may be late in the sprint and expensive to change.

This is how teams end up with lots of started work and very little finished work. Everyone can honestly say they were busy. Everyone can point to tasks they completed. But the team still misses the sprint goal or carries work into the next sprint.

A Scrum team should be looking for ways to reduce those handoffs. That does not mean everyone does everything. It means the team collaborates earlier, overlaps work, keeps important work visible, and asks, “What should we finish next?” before asking, “What can I start next?”

The product owner is part of this too. When the product owner is only consulted at the beginning and end of a story, the team loses chances to simplify, split, or redirect the work while there is still time.

The Daily Scrum Should Help the Team Coordinate

The daily scrum often reveals whether a Scrum team is acting like a team.

When the event becomes a series of individual reports, the team is probably not coordinating enough. One person says what they did yesterday, what they will do today, and whether they have blockers. Then the next person does the same. The Scrum Master listens. Everyone else waits for their turn. No one comments on someone else's work.

That can look orderly, but it rarely changes how the team works that day.

A useful daily scrum helps the developers inspect progress toward the sprint goal and decide how to work together for the next day. The focus is not on proving that everyone was busy. The focus is on the work, the goal, and the risks.

Useful questions sound more like these:

• What is most important to finish next?
• Which item is most at risk?
• Where are we waiting?
• Who needs help?
• What should we stop starting so we can finish something valuable?

Those questions change the purpose of the daily scrum. The event becomes less about reporting and more about coordination. The team leaves with a better plan for the day, not just a collection of individual updates.

A team working like individuals tends to organize around personal tasks. Each person owns their piece. Each person tries to stay busy. Each person can say, “My part is done.”

Watch the “My Tasks” View

Tools can accidentally reinforce individual ownership. A “my tasks” view is useful, but teams also need to look together at what is closest to done, what is blocked, and what matters most to the sprint goal.

Scrum works best when the team cares more about finishing valuable work than keeping every individual fully utilized.

That requires shared ownership. A developer who finishes their task does not simply grab the next unrelated task so they can stay fully utilized. They look at what the team is trying to finish. They ask where help is needed. They may pair, review, test, clarify, split, simplify, or swarm.

Shared ownership changes the conversation. Instead of asking, “What am I assigned to?” the team asks, “What does the team need to finish?”

That is a small shift in language, but a major shift in behavior.

It also reduces the “almost done” problem. Many struggling Scrum teams have several product backlog items nearly done near the end of the sprint. The coding is done, but testing is not. Testing is done, but feedback is missing. Feedback came in, but too late to incorporate.

A team with shared ownership attacks that problem earlier. They do not wait until the last day to discover that too much work is unfinished. They coordinate throughout the sprint so fewer items are in progress and more items are truly done.

Cross-Functional Does Not Mean Everyone Does Everything

Cross-functional is one of the most misunderstood ideas in Scrum.

A cross-functional team has the skills needed to turn product backlog items into a valuable, usable increment. People still have specialties. A database expert, UX designer, tester, and programmer do not suddenly become interchangeable. Cross-functional describes the team’s capability, not each individual’s résumé.

Specialists are often essential. The problem comes when specialization becomes a wall.

A tester can help the team think about acceptance criteria before coding begins. A programmer can help test earlier instead of waiting for a formal handoff. A UX specialist can collaborate with the product owner and developers before the sprint is packed with assumptions. A database expert can help others understand constraints so the work does not bottleneck around one person.

That is what cross-functional collaboration looks like. People still bring depth in different areas, but they do not protect narrow task boundaries at the expense of the team’s goal.

The aim is finished value, not interchangeable people.

Leaders Shape Whether Real Teamwork Is Possible

Teams are often blamed for not collaborating, but many teamwork problems are reinforced by the organization around the team.

Leaders may say they want stable Scrum teams, but assign people part-time across multiple teams. They may say they want team ownership, but reward individual utilization. They may say the sprint goal matters, but pull people away for urgent work that is unrelated to the sprint.

Those choices make real teamwork harder.

A Scrum team needs:

• Enough stability to learn how to work together
• Enough focus to make and meet realistic commitments
• Permission to finish important work instead of keeping everyone individually busy
• Leaders who care about outcomes, not just activity

This is especially important when people come from functional departments. Developers, testers, analysts, UX specialists, architects, and product owners may all have different managers, incentives, and habits. Without leadership support, those functional loyalties can remain stronger than the shared ownership needed on a Scrum team.

Leaders do not need to manage the team’s daily work. But they do need to create conditions in which teamwork is possible.

How to Start Acting More Like a Team Next Sprint

A Scrum team does not become a real team because someone gives a speech about collaboration. The team becomes more team-oriented by changing how it handles real work.

Start small.

Pick one important product backlog item in the next sprint and treat it as a team effort from the beginning. Discuss the risks early. Clarify acceptance criteria together. Identify where handoffs would normally happen and look for ways to reduce them. If the item gets stuck, swarm on it instead of letting it wait for the next specialist.

Reframe the daily scrum around the sprint goal and the work most at risk. Talk less about what each person did and more about what the team needs to finish.

Limit work in progress. A team that starts too much creates more handoffs, more context switching, and more unfinished work. Finishing fewer items sooner is often better than starting everything and hoping it comes together later.

During the sprint retrospective, look specifically at where work waited. Where did an item sit without progress? Where did a handoff create delay? Where did the team discover a problem later than it should have? Those delays are clues about where teamwork needs to improve.

The goal is not to become perfect in one sprint. The goal is to make teamwork more visible and more deliberate.

Scrum Works Better When the Team Works Like a Team

Scrum gives teams a structure for planning, coordinating, reviewing, and improving their work. But the structure alone is not enough.

A Scrum team needs shared ownership. It needs collaboration across skill boundaries. It needs developers who coordinate around the sprint goal. It needs a product owner who helps the team focus on value. It needs a Scrum Master who helps the team improve how it works. And it needs leaders who create conditions that support real teamwork.

When those pieces are missing, Scrum can become a set of meetings around individual work.

When those pieces are present, Scrum feels different. The team finishes together. Problems surface earlier. The daily scrum becomes useful. The sprint goal guides decisions. Work flows with fewer delays. People still have specialties, but they use those specialties in service of the team’s outcome.

If your Scrum teams are holding the events but still working like groups of individuals, the next step is helping the whole team build a shared understanding of how Scrum is supposed to work and how they need to work together.

That is why Working on a Scrum Team is designed for the whole team, not just one role. It helps product owners, Scrum Masters, and developers move beyond attending Scrum events and start using Scrum as a practical way to collaborate, focus, and deliver.

Those changes may be part of the work. But they are not the point.

The point of an agile initiative is to improve an organization’s ability to deliver valuable work, learn from feedback, respond to change, and make better decisions under uncertainty.

Treating the effort as a rollout leads to a very different set of leadership behaviors than treating it as an ongoing improvement effort.

A rollout can be managed mostly as a project: train people, rename roles, update workflow boards, schedule new meetings, and declare the rollout complete.

Improving agility cannot be managed that way. You cannot know in advance exactly what “better agile” will look like for every team, product, department, or organization. You can know what outcomes you want. You can know what problems you are trying to solve. But the exact practices, team structures, decision rules, and improvement path need to emerge as people learn.

That is why the best way to lead an agile initiative is to use agile to improve agility.

Set a goal. Choose a small improvement. Try it. Review what happened. Adjust. Repeat.

That sounds simple, but it changes the leadership stance. The goal is no longer to install agile perfectly. The goal is to make the organization measurably better at delivering value.

Start with Outcomes and a Shared Understanding of Agile

Before beginning an agile improvement initiative, leaders should be clear about what they want agility to improve.

Useful goals might include:

• reducing time to value;
• improving customer satisfaction;
• reducing defects found after release;
• improving employee engagement;
• making planning more reliable;
• shortening feedback loops;
• helping teams respond to changing priorities without chaos.

These goals are better than “adopt agile” or “roll out Scrum.” They help leaders and teams evaluate whether the initiative is producing meaningful change.

A clear outcome also helps avoid one of the most common problems in agile initiatives: different people using the same word to mean different things.

One team may think agile means following the Scrum Guide closely. Another may think it means using Kanban. Another may think they are agile because all work is tracked in Jira. Leaders may say they want empowerment but still expect every important decision to come back up the hierarchy.

None of this is unusual. Agile is flexible, and that flexibility is part of its strength. But without a shared understanding, flexibility becomes confusion.

A leadership team should be able to answer questions such as:

• Why are we trying to become more agile?
• What business outcomes are we trying to improve?
• What decisions should move closer to teams?
• What practices do we expect teams to use consistently?
• Where do teams have freedom to adapt their way of working?
• What behaviors will leaders need to change?
• How will we know whether this initiative is helping?

A shared understanding does not mean every team works identically. It means people share enough language, principles, and expectations that teams can make local decisions without pulling the organization in conflicting directions.

Why Agile Initiatives Fail

When agile initiatives struggle, the same problems tend to show up again and again.

Seeing those patterns early gives leaders a chance to respond before skepticism hardens and the organization starts explaining the failure in unhelpful ways.

Problem: Agile Becomes Process Without Mindset

The most visible parts of agile are easy to copy: sprints, daily scrums, reviews, retrospectives, product backlogs, task boards, story points, and new roles.

Those practices can help. But they do not automatically change how an organization thinks about control, uncertainty, learning, or accountability.

A company can adopt agile meetings and still expect every decision to be approved by management. It can create product owner roles while still letting stakeholders bypass the product owner. It can ask teams to deliver iteratively while still judging them by fixed-scope, fixed-date expectations set too early.

That creates agile in name only.

The organization looks busier. It may even look more agile. But decisions are still made the old way, work still flows the old way, and teams still operate inside the old management logic.

Problem: Agile Is Delegated, Not Lived

Leaders can delegate many things. They cannot delegate the change in leadership behavior required for agile to work.

Teams can learn Scrum. Scrum Masters can be trained. Product owners can be assigned. Coaches can be hired. But many of the biggest obstacles teams face are outside the team: budgeting rules, overloaded specialists, conflicting priorities, unclear authority, too many active initiatives, or stakeholders who expect change without trade-offs.

Teams cannot solve those problems alone.

When leaders stay outside the change, the organization sends a mixed message: teams should become agile, but the surrounding system will remain mostly the same.

Teams read that signal quickly.

If leaders say they want learning but reward certainty, teams will hide uncertainty. If leaders say they want outcomes but ask only about utilization, teams will optimize for looking busy. If leaders say they want empowerment but override every uncomfortable decision, teams will wait for permission.

Teams follow what leaders do, not what leaders say.

Problem: Organizations Scale Problems Before Solving Them

Scaling agile can be useful. Scaling too soon can make things worse.

Before adding large-scale coordination structures, leaders should ask whether the organization has enough team-level success to build on:

• Can a few teams deliver valuable work?
• Can they finish within short iterations?
• Can they work with a clear product owner?
• Can they get feedback from stakeholders and customers?
• Can they improve how they work?
• Can they plan with enough reliability that the business can make good decisions?

If the answer is no, scaling often spreads dysfunction.

It adds meetings, roles, dependencies, and coordination around problems the organization has not yet solved. Weak product ownership becomes weak product ownership across more teams. Too much work in progress becomes a larger traffic jam. Unclear decision-making becomes more expensive.

It is better to build coordination around teams that are already working well than to hope a larger structure will make struggling teams successful.

Problem: Too Much Work in Progress Slows Everything Down

Many organizations think they have a speed problem, so they start more work.

More initiatives. More urgent requests. More people assigned across multiple teams. More projects moving at once.

This usually creates the opposite of speed.

When too much work is in progress, people switch constantly. Work waits. Dependencies multiply. Quality slips. Teams look busy, but less finishes. Leaders see slow progress and often respond with more pressure, which adds even more work and interruption.

Doing fewer things at once often makes the organization faster overall.

That is hard because real prioritization hurts. If saying no does not disappoint anyone, the organization probably has not really prioritized. It has only rearranged a list while continuing to overload the system.

Problem: Product Ownership Is Too Weak

Many delivery problems are really product decision problems.

The organization may have someone called a product owner, but that person may not have enough authority to make meaningful priority decisions. Stakeholders, managers, executives, architects, salespeople, and urgent customer requests may all compete for the team’s attention.

When everyone has a say and no one owns the outcome, the backlog becomes a storage place for requests instead of a strategy for delivering value.

Teams can remain very busy in that environment. They can complete many product backlog items. But they may still struggle to answer the more important question: Are we delivering the right things?

An agile initiative needs clear product ownership. That does not mean one person ignores input from others. It means someone is accountable for the final priority call, can explain trade-offs, and can give the team a stable direction.

Problem: Agile Reveals What the Organization Still Has to Solve

Agile often makes problems visible before it makes them better.

Shorter feedback loops reveal weak product choices. Sprint reviews reveal stakeholder misalignment. Retrospectives reveal teamwork issues. Forecasts reveal uncertainty. Product backlogs reveal too many priorities. Team-level work reveals organizational bottlenecks.

That visibility can feel uncomfortable. It can even make the initiative look worse for a while.

But visibility is not the problem. Visibility gives the organization a chance to improve.

When agile exposes unstable priorities, weak product ownership, slow feedback, or leadership contradictions, leaders should resist the urge to blame agile. The better response is to ask: What is this showing us that we need to fix?

Use Agile to Improve Agility

The best way to lead an agile improvement initiative is to manage the improvement effort in an agile way.

That means setting a direction, choosing a small improvement, trying it, reviewing what happened, and adapting from there. The organization does not need to know the perfect future state before it starts. It needs a clear purpose, short feedback loops, and a way to keep improving.

Mountain Goat Software calls this the Better Agile Framework. It has four parts:

• Iterate toward greater agility. Treat each improvement as an experiment and learn from what happens.
• Use improvement backlogs. Make the work of improving agility visible, prioritized, and inspectable.
• Guide rather than control the effort. Leaders create energy, remove obstacles, and set useful boundaries without turning the initiative into a compliance program.
• Supplement teams with improvement communities. Use communities to address problems that span teams, such as testing, product ownership, metrics, or cross-team collaboration.

Use the Better Agile Framework when your organization needs a lightweight way to coordinate improvement without turning the effort into a top-down program. It gives leaders, teams, and improvement communities a shared structure for deciding what to improve next and learning from each change.

Use the Five Pillars to Decide What to Improve First

Agile improvement initiatives become fragile when they focus on only one part of the system.

A team may learn new practices but lack role clarity. Leaders may say the right things but continue rewarding individual heroics. Product owners may understand agile but lack authority. Teams may improve internally while stakeholders continue disrupting sprints or demanding fixed scope without trade-offs.

The five pillars help leaders decide where to focus next:

• Mindset: Do people understand why they are being asked to work differently?
• Practices: Are teams learning and using the practices needed to deliver, inspect, and adapt?
• Roles: Are responsibilities clear enough for decisions to be made well?
• Teamwork: Are people working as a real team rather than as individuals passing work from one specialist to another?
• Outside-the-team support: Are stakeholders, managers, and surrounding functions changing how they interact with teams?

Use the five pillars as sources for improvement backlog items. When progress stalls, look across the pillars and ask which part of the system is limiting agility now.

For example, a team may have enough training and motivation but still struggle because stakeholders keep inserting urgent work during the sprint. That is not primarily a practices problem. It is an outside-the-team support problem. Another team may have a strong Scrum Master and good sprint events but still lack a product owner with authority. That is a roles problem.

The value of the five pillars is diagnostic. They help leaders avoid solving the wrong problem.

Make the Leadership Shifts That Let Agile Work

The success of an agile initiative is visible in leadership behavior.

Leaders do not need to know every detail of every agile framework. But they do need to change how they create clarity, support teams, make trade-offs, and respond to uncertainty.

Participate Visibly

Agile becomes believable when leaders show up consistently.

That does not mean attending every team meeting. It means participating where leadership context and feedback help: sprint reviews, roadmap conversations, planning discussions, product goal reviews, and retrospectives where organizational obstacles need leadership attention.

When leaders attend reviews and ask what was learned, teams prepare differently. When leaders ask about outcomes rather than only output, teams focus differently. When leaders remove obstacles, teams learn that transparency is worth the risk.

Visible participation tells the organization that agile is not the initiative of the quarter.

Empower for Real

Empowerment requires authority, time, and trust.

A product owner needs authority to make priority decisions. A Scrum Master needs enough time to help the team improve. A team needs trust when it makes a reasonable decision that is not the one a leader would have made.

Symbolic empowerment creates frustration. People are told to own decisions, then overruled whenever those decisions become uncomfortable.

Real empowerment is a structural choice. Leaders decide who owns what, give those people the conditions to do the work well, and then support them when trade-offs become difficult.

Focus the System

Leaders improve agility by helping teams finish.

That often means reducing work in progress, protecting teams from constant interruption, and making hard priority choices.

When everything is important, nothing moves well. Teams cannot be predictable when priorities change constantly, people are split across too many efforts, and urgent work is inserted without trade-offs.

Focus is not a motivational slogan. It is a leadership discipline.

Learn Sooner

Agile is a learning system.

Leaders who understand this do not demand false certainty too early. They ask what is known, what is uncertain, what the team expects to learn next, and what range of outcomes is reasonable.

That does not mean leaders stop caring about dates, budgets, or commitments. It means they use feedback to make better decisions rather than pretending every plan can be known perfectly in advance.

Better questions include:

• What do we know?
• What is still uncertain?
• What would need to be true for this plan to work?
• What options have we considered?
• What trade-offs should we discuss?
• What could we learn sooner?
• What decision do you need from me?

Leaders who ask these questions make uncertainty discussable. That is one of the most important things they can do.

Improving Agility Without Another Big Program

Many organizations are not trying agile for the first time. They are trying to make agile work better than it has so far.

They may have trained teams, introduced Scrum, hired coaches, reorganized, or adopted a scaling framework. Some of it helped. Some of it faded. Some of it left people skeptical.

That history shapes how people respond to the next agile improvement initiative.

If people have experienced previous change programs that overpromised and underdelivered, they will not automatically trust the next effort. They may wait it out. They may comply on the surface while preserving old habits underneath.

Leaders can reduce change fatigue by making the next effort smaller, more honest, and more connected to real problems.

Instead of announcing a sweeping program, leaders can say:

• Here is the business problem we need to solve.
• Here is what we believe agility can help us improve.
• Here are the first few changes we will try.
• Here is how we will know whether those changes are helping.
• Here is what leaders will change, not just what teams will change.

That approach is less dramatic. It is also more credible.

People do not need another slogan. They need evidence that this time the organization is willing to change the conditions around teams, not merely ask teams to absorb another process change.

Common Questions About Leading Agile Initiatives

Why Do Agile Initiatives Fail?

Agile initiatives fail when organizations change visible practices without changing how decisions are made. Common causes include weak leadership participation, unclear product ownership, too much work in progress, scaling too soon, poor role clarity, and expecting agile to fix problems the organization still refuses to address.

What Should Leaders Do During an Agile Initiative?

Leaders should set clear outcomes, create useful boundaries, participate visibly, remove organizational obstacles, protect focus, clarify roles, support product ownership, and create safety for teams to surface problems early. They should guide the improvement effort without controlling every team-level decision.

What Is the Better Agile Framework?

The Better Agile Framework is Mountain Goat Software’s approach for improving agility using agile itself. It encourages organizations to iterate toward greater agility, use improvement backlogs, guide rather than control the improvement effort, and supplement teams with improvement communities. This Guide introduces the framework; the full framework should be explained on its own page.

What Is an Improvement Backlog?

An improvement backlog is a prioritized list of experiments and changes intended to improve agility. Teams, improvement communities, and guiding coalitions can all use improvement backlogs to make change visible, actionable, and inspectable.

What Is a Guiding Coalition?

A guiding coalition is a small group of influential leaders who support and guide an agile improvement initiative. The coalition creates energy, communicates why change matters, removes organizational obstacles, provides resources, and helps the organization improve without turning agile into a top-down compliance program.

Should We Start Small or Go All In?

Either can work, but both have risks. Starting small gives the organization a chance to learn before expanding. Going all in can create urgency and consistency, but it also spreads mistakes quickly. The best choice depends on the organization’s goals, urgency, leadership support, and capacity for change.

How Do We Know Whether an Agile Initiative Is Working?

Look for evidence that the organization is getting better at delivering value. Useful signs include shorter feedback loops, more reliable planning, clearer priorities, stronger product ownership, better collaboration, improved quality, higher stakeholder trust, and teams that can inspect and adapt how they work.

How Can Leaders Avoid Change Fatigue?

Avoid slogans, big-bang promises, and process theater. Focus on real problems, small improvements, visible leadership behavior, and honest feedback. Show people what will change in the system around them, not just what ceremonies they are expected to perform.

Need Help Leading an Agile Initiative?

Agile initiatives succeed when leaders create the conditions teams need to improve: clear outcomes, empowered roles, practical feedback loops, enough focus to finish, and a way to keep learning.

Mountain Goat Software helps leaders and teams improve agility without turning the effort into a heavy program. We can help you diagnose what is happening now, form a guiding coalition, create improvement backlogs, support improvement communities, and strengthen the five pillars of sustainable agile change.

Schedule a Discovery Call

Those classes mattered — and they helped spread agile knowledge at a time when many people were hearing these ideas for the first time.

But the place where I believe we can have the greatest impact now has shifted.

We're ending our public classes and focusing Mountain Goat Software's training and coaching work on private client engagements: private courses, practical workshops, and follow-through support for teams and organizations that want help applying agile and Scrum more effectively.

Why This Shift Makes Sense Now

A lot of individuals understand Scrum and agile quite well.

But while training can give individuals a solid understanding, that alone does not help a team work better together.

Teams have to make decisions about their own backlog, planning, collaboration, and stakeholder expectations. Those are difficult to solve one person at a time.

That's where private client work becomes so valuable. When we work with a company directly, we can focus on the team's actual challenges — the product backlog they really use, the planning problems they're actually trying to solve, the leadership dynamics that are quietly making things harder.

That deeper work is where I'm most excited to spend my time.

What Changes When the Work Is Private

Private training lets teams work on the backlog items, planning decisions, and delivery problems they already need to solve. In Mastering User Stories, for instance, teams work with their own backlog items and user stories — improving the actual work they need to refine, split, estimate, and deliver.

That changes the nature of the class. A team can see where its current stories are too large, too vague, or too focused on output instead of value. Product owners, Scrum Masters, developers, testers, and leaders build a shared understanding of what good stories need to do in their context — not in some hypothetical scenario.

The same principle applies across all our private offerings:

• Working on a Scrum Team helps a team build a stronger, shared way of applying Scrum together.
• Agile for Leaders helps leaders see how their behavior affects the teams they're trying to support.
• Accurate Agile Planning helps teams and leaders make better decisions about dates, scope, forecasts, and uncertainty.

And in all of these, we can add coaching and follow-through support so the learning doesn't end when the class does. A course can create insight. Real change takes repeated application, adjustment, and support over time.

A Recent Engagement That Made This Clear

Last year, we trained roughly 550 people at one organization through a series of classes and follow-through coaching sessions. Their biggest needs centered on backlog health, cross-team collaboration, and leadership alignment.

Those three things were connected. The backlog problems were making collaboration harder. The collaboration gaps were feeding leadership misalignment. Working across all of them — together, over time — produced changes that a two-day public course never could have.

That engagement reinforced something I've believed for a long time: agile improvement is most effective when teams and leaders work on it together, with support that follows them into the real work.

How We Shape Private Engagements

We start by understanding what the client is trying to improve and where teams are getting stuck.

That might mean looking at their backlog, planning approach, team structure, agile leadership expectations, or a particular delivery problem. We then shape the course, workshop, or follow-through support around that need.

Sometimes the right answer is a focused workshop: improving backlog quality, splitting stories, estimating, or preparing for a release-planning conversation. Sometimes it's a private course for one or more teams. Sometimes it includes coaching after the course so teams can apply what they learned with support alongside them.

The format depends on the need. The goal is always the same: help the client make meaningful, lasting progress with agile.

What Stays the Same

I'll continue writing blog posts, sending email tips, and creating YouTube videos. I've been doing that for decades, and I still think it's helpful. There will always be people who find Mountain Goat Software through an article, a tip, a book, or something a colleague forwards to them.

We're also rebuilding the Mountain Goat Software website around this new direction and reorganizing 500+ blog posts into ten topic-based agile guides — covering Scrum, user stories, product backlog, agile planning, leadership, and more. The goal is to make it easier to find the most useful material, whether you're a private client or an individual reader.

What's changing is where we focus our training and coaching work.

If Your Organization Wants Help

The goal hasn't changed: helping people and teams succeed with agile.

If your organization wants help with private training, a practical workshop, or follow-through coaching — whether that means improving user stories and backlog refinement, helping Scrum teams build a stronger shared approach, or helping leaders understand how to support agile teams more effectively — I'd welcome a conversation.

Get in touch here

The comment can sound cynical, dismissive, or resistant. But often it is something more useful: evidence from a previous improvement effort.

People may have seen the organization rename meetings, assign new roles, update Jira workflows, adopt Scrum or Kanban, hire coaches, or launch a major transformation. For a while, everything may have looked more agile.

But the promised results did not appear.

Planning was still unreliable. Priorities still changed without meaningful tradeoffs. Product Owners still lacked the authority to make real decisions. Teams were still overloaded. Stakeholders still bypassed the backlog whenever something felt urgent. Sprint Reviews rarely generated useful feedback, and retrospectives kept uncovering the same issues without anything really changing.

When that happens, people do not need another speech about the benefits of agile.

They need evidence that this time the organization will improve the conditions around the work.

Why This Matters

Organizations rarely approach agile as a completely new idea anymore.

More often, leaders are trying to improve agility in an environment where people have already experienced one or more agile initiatives. Some helped. Others created frustration, skepticism, or change fatigue.

Understanding that history matters. The way leaders respond to skepticism can determine whether the next improvement effort gains credibility or repeats the same patterns that disappointed people before.

Start by Asking What Actually Failed

Do not start by defending agile.

Start by asking what happened.

Useful questions include:

• What did agile promise here that did not happen?

• Which parts helped, even a little?

• Which parts felt like overhead?

• What changed for teams but not for leaders, managers, or stakeholders?

• Where did we add process without improving decisions?

• What problems became visible but were not addressed?

• What would need to be different for people to believe the next effort is serious?

• What evidence would make you say, “This is helping”?

Those questions turn skepticism into information. They help leaders discover whether the last effort failed because of weak practices, unclear roles, too much work in progress, insufficient product ownership, leadership behavior, technical problems, or the system surrounding teams.

The goal is not to convince everyone that agile worked.

The goal is to understand what limited agility and improve it.

Don’t Dismiss Skepticism as Resistance

It is tempting to label skeptical people as resistant.

Sometimes that is accurate. People may prefer the current system. They may dislike uncertainty. They may worry about losing authority, status, predictability, or a familiar way of working.

But in many organizations, skepticism about agile is not resistance to a new idea. It is a reaction to lived experience.

They may have seen this before: a big announcement, a few classes, new meetings, new role names, maybe a new tool. Then, after a few months, the energy fades and the old ways of making decisions return.

Teams are told they are empowered, but every important decision still gets escalated. Leaders say they want agility, but priorities keep changing without tradeoffs. People are told to be transparent, but the first bad news they share is used against them.

In that context, “we tried agile and it didn’t work” may mean:

• We changed the meetings but not the decisions.

• We changed the team structure but not the work in progress.

• We changed job titles but not authority.

• We adopted a framework but not the mindset behind it.

• We were told to be transparent, then punished for surfacing problems.

• We were asked to commit to fixed scope and fixed dates, just in shorter increments.

• We had more ceremonies but not more learning.

• We did agile to teams instead of improving agility with them.

Leaders should treat that skepticism as data. It points to what the next improvement effort needs to address.

What People Usually Mean by “Agile Didn’t Work”

When someone says agile did not work, ask what they mean.

The answer matters because agile can disappoint in different ways.

It Did Not Make Us Faster

Many organizations start agile hoping teams will deliver faster.

That may happen eventually, but agile does not create speed by asking overloaded teams to do the same work in shorter cycles. Agile improves delivery by making work visible, creating shorter feedback loops, reducing waste, clarifying priorities, improving teamwork, and helping the organization make better tradeoff decisions.

If the organization kept starting too much work, splitting people across too many initiatives, or inserting urgent requests without removing anything else, agile may have made the overload more visible without solving it.

That can feel like agile failed.

The deeper problem may have been focus.

It Did Not Make Planning Easier

Agile planning is not a way to make uncertainty disappear.

It is a way to make uncertainty discussable sooner.

If leaders expected agile teams to provide perfect predictability while priorities changed constantly, dependencies remained unmanaged, and scope was treated as fixed, planning probably became frustrating for everyone.

Teams may have felt pressured into false certainty. Leaders may have felt teams were avoiding commitment. Stakeholders may have heard ranges or tradeoffs as excuses.

The problem may not have been agile planning. The problem may have been that planning was never treated as a shared problem.

It Did Not Empower Teams

Some organizations tell teams they are empowered but leave the old decision system in place.

The Product Owner cannot really prioritize. Stakeholders bypass the backlog. Managers still assign work directly to individuals. Technical decisions require approval from people far from the work. Teams are asked to self-organize, but only within narrow boundaries that have already determined the answer.

That creates symbolic empowerment.

Symbolic empowerment is worse than no empowerment because it raises expectations and then disappoints people.

When people say agile did not work, they may mean they were promised ownership but given process.

It Added Meetings Without Improving Decisions

Agile events are meant to create feedback, alignment, adaptation, and accountability.

They are not valuable just because they happen.

A Daily Scrum that becomes a status meeting does not improve teamwork. A Sprint Review without stakeholders or meaningful feedback does not improve product decisions. A Retrospective that surfaces the same issue every sprint without action does not improve the team. Sprint Planning that ends with a list of tasks but no shared goal does not create focus.

When agile becomes a meeting structure rather than a learning system, people understandably conclude that agile is overhead.

It Revealed Problems No One Wanted to Fix

Agile often makes problems visible before it makes anything better.

A shorter cycle can reveal weak product ownership. A Sprint Review can reveal stakeholder disagreement. A Retrospective can reveal unresolved teamwork issues. A forecast can reveal that a date is unrealistic. A visible backlog can reveal too many priorities. A team trying to finish work each sprint can reveal technical debt, dependency problems, unclear roles, or insufficient testing practices.

That visibility can be uncomfortable.

When the organization responds by blaming agile, blaming teams, or ignoring the problems, the initiative stalls. But agile may not have created the problem. It may have revealed a problem the organization was already carrying.

The better response is to ask: What did agile show us that we still need to solve?

Separate Agile from the Failed Implementation

Agile is not the same as the last implementation of agile.

It is not a tool, a meeting calendar, a certification path, a job-title change, or a scaling framework. Those things may support agility, but none of them guarantees it.

At its core, agility is the ability to deliver valuable work, learn from feedback, respond to change, and make better decisions under uncertainty.

A failed implementation may have included agile language without agile behavior.

For example:

• The organization said “responding to change” but treated every plan as fixed.

• Leaders said “empowerment” but overruled uncomfortable product decisions.

• Teams said “Sprint Review” but showed work to each other instead of learning from stakeholders.

• Managers said “focus” but kept starting more initiatives.

• Product Owners said “backlog” but managed a storage place for requests rather than a strategy for value.

• Teams said “done” but left testing, integration, documentation, or release work for later.

• Coaches said “self-managing,” but leaders did not create the boundaries that made self-organization possible.

When people say agile did not work, leaders need to understand whether agile was actually tried or whether the organization tried a version of agile stripped of the leadership behavior, product discipline, technical practices, and teamwork needed to make it work.

Why Agile Improvement Efforts Disappoint

The most common causes of disappointment are rarely mysterious.

They tend to show up in familiar patterns.

Agile Became Process Without Mindset

The visible parts of agile are easy to copy.

Teams can schedule sprints, hold Daily Scrums, create backlogs, estimate stories, and run retrospectives. Those practices can help, but they do not automatically change how the organization thinks about uncertainty, control, feedback, collaboration, or accountability.

If the old mindset remains, agile becomes process theater.

Teams do the events, but the real decisions are still made elsewhere. Leaders talk about outcomes but measure activity. Stakeholders say they want flexibility but expect every original commitment to remain unchanged. Teams are told to inspect and adapt, but only within boundaries that keep the old system intact.

Leaders Delegated Agile Instead of Living It

Teams can improve many things themselves.

They can improve refinement, collaboration, estimation, testing, and how they plan their work. But some obstacles sit outside the team: funding rules, portfolio overload, unclear authority, competing priorities, overloaded specialists, unrealistic dates, inconsistent stakeholder behavior, and incentive systems that reward the wrong things.

Teams cannot solve those problems alone.

When leaders delegate agile to teams, Scrum Masters, coaches, or a transformation office, the initiative sends a mixed message: teams should change, but the system around them will remain mostly the same.

People notice.

They learn that transparency is risky, that leadership behavior is exempt, and that agile is something teams are expected to perform rather than something the organization is using to improve.

Work in Progress Stayed Too High

Agile does not work well when the organization keeps starting too much.

Too much work in progress causes context switching, delays, dependency problems, unfinished work, quality issues, and unreliable forecasts. Teams may look busy while less gets finished.

This often gets interpreted as a team problem.

Leaders see slow progress and ask teams to commit harder, estimate better, or improve velocity. But if the system is overloaded, better ceremonies will not fix the problem. The organization needs to make harder priority decisions.

Focus is not a motivational slogan. It is a leadership discipline.

Product Ownership Was Too Weak

Many agile disappointments are really product ownership disappointments.

A team may have someone called a Product Owner, but that person may not have enough authority to make priority decisions, say no, clarify tradeoffs, or protect the team from competing demands.

When everyone can influence the backlog but no one can make the final priority call, the backlog becomes a collection of requests. The team can deliver many items and still fail to deliver the right outcomes.

Weak product ownership makes agile look ineffective because teams are busy, but the work does not add up to enough value.

Teams Were Standardized Instead of Supported

Some organizations respond to inconsistent agile practices by standardizing everything.

A little consistency can help. Shared language, clear expectations, common definitions, and useful guardrails can prevent confusion.

But excessive standardization creates another problem. Teams stop adapting. They follow rules that may not fit their work. They focus on compliance instead of improvement. They lose ownership of how they work.

The goal is enough consistency to stay aligned and enough autonomy to keep learning.

The Organization Scaled Problems Instead of Solving Them

Scaling agile can help when multiple teams need to coordinate around shared goals.

But scaling too soon can spread dysfunction.

Weak product ownership becomes weak product ownership across more teams. Too much work in progress becomes a larger traffic jam. Poor technical practices create integration problems across the system. Unclear priorities become more expensive. Teams that cannot finish work inside one sprint now need additional meetings to coordinate unfinished work across many teams.

If agile disappointed at scale, the organization may need to step back and ask whether it scaled success or scaled unresolved problems.

Rebuild Credibility Through Small, Visible Improvements

After a disappointing agile initiative, credibility is rebuilt through evidence, not slogans.

Do not announce another sweeping transformation with a new name. Do not promise that this time everything will be different. Do not start by asking people to trust the process.

Start by improving something real.

1. Acknowledge the Previous Experience

Leaders should be honest about what happened.

That does not mean declaring the previous effort a failure. It may have helped in some ways. It may have improved transparency, created useful practices, introduced better language, or helped some teams.

But leaders should also acknowledge what disappointed people.

For example:

“Last time, we changed team practices faster than we changed leadership behavior.”

Or:

“We introduced agile meetings, but we did not give Product Owners enough authority.”

Or:

“We asked teams to be more predictable while continuing to change priorities without tradeoffs.”

That kind of honesty lowers defensiveness. It tells people leaders have learned something.

2. Name the Outcome You Want to Improve

Do not restart with “we need to be more agile.” That is too vague to guide decisions and too easy for people to dismiss.

Start with a real outcome. Maybe the organization needs to reduce unfinished work, improve planning reliability, increase stakeholder trust, shorten feedback loops, improve quality, or clarify product ownership.

The specific outcome matters less than making it concrete. People should be able to tell whether the next few changes are helping.

A clear outcome gives people something better than “trust us, this time agile will work.” It gives them something they can observe.

3. Choose a Small Improvement

Pick one improvement that is small enough to try and visible enough to matter.

That might mean having leaders attend the next few Sprint Reviews and ask what was learned. It might mean clarifying which product decisions the Product Owner can make without escalation. It might mean reducing the number of active initiatives for a quarter, trying a different refinement approach for two sprints, or replacing a status meeting with a real obstacle-removal conversation.

The exact improvement will depend on the outcome you named. If you want clearer priorities, work on priority decisions. If you want more honest planning, change the planning conversation. If you want stronger feedback, improve the Sprint Review.

The point is to pick something real. Not a slogan. Not a principle. A change people can see, try, and inspect.

4. Put Improvements in an Improvement Backlog

An improvement backlog makes the work of improving agility visible.

Without one, improvement stays vague. Everyone agrees the organization should get better, but no one can see what is being tried, what is waiting, or what has already been learned.

The backlog does not need to be complicated. It might include team-level improvements, cross-team improvements, and leadership-level improvements. One item might be about improving stakeholder participation in Sprint Reviews. Another might be about clarifying Product Owner authority. Another might be about reducing work in progress, strengthening technical practices, improving story splitting, or removing a recurring dependency bottleneck.

The backlog should be ordered because not everything can be improved at once. That ordering is useful. It forces leaders and teams to have the same kind of tradeoff conversations they want teams to have about product work.

5. Review What Happened

Every improvement should be inspected.

After trying a change, pause long enough to ask whether it helped. What changed? What did we learn? What surprised us? Should we continue, adjust, or stop? Is there something another team or leader should learn from this?

This is where credibility starts to return.

People do not need every experiment to work. They will trust the effort more if leaders are honest about what did not work. What they need to see is that the organization is paying attention, telling the truth, and changing based on evidence.

Use the Five Pillars to Diagnose What Went Wrong

When agile disappoints, leaders often reach for the most visible fix.

Train the teams again. Change the tool. Reconfigure the workflow. Add a coach. Adopt a framework. Create a new dashboard.

Any of those might help.

But they might also solve the wrong problem.

The five pillars help leaders diagnose what is limiting agility now.

Mindset

Do people understand why they are being asked to work differently?

Skepticism may be a mindset issue if people see agile as a management fad, a delivery-speed mandate, or a set of ceremonies imposed from above.

But mindset is not improved by cheerleading. It improves when people see a credible connection between agile practices and better outcomes.

Practices

Are teams using practices that help them deliver, inspect, and adapt?

Skepticism may be a practices issue if teams do not know how to split work small enough, refine effectively, test within the sprint, collaborate across specialties, or use retrospectives to create meaningful improvement.

In that case, people may not need more persuasion. They may need better skills and support.

Roles

Are responsibilities and decision rights clear?

Skepticism may be a roles issue if Product Owners lack authority, Scrum Masters are treated as meeting schedulers, managers are unsure how to support self-organization, or stakeholders do not know how to work through the backlog.

Role confusion creates frustration that people may blame on agile.

Teamwork

Are people working as a real team?

Skepticism may be a teamwork issue if work still moves through individual handoffs, specialists remain isolated, testing happens late, or people optimize for completing their own tasks rather than finishing valuable work together.

Agile exposes the difference between a team and a group of individuals.

Outside-the-Team Support

Are leaders, stakeholders, managers, and surrounding functions changing how they interact with teams?

Skepticism may be an outside-the-team support issue if stakeholders insert urgent work without tradeoffs, leaders pressure teams for fixed answers too early, HR policies reward individual heroics, finance rules reinforce project thinking, or governance processes require large batches of work.

Many agile disappointments live here.

Teams can improve their practices, but they cannot become fully agile while the surrounding system keeps pulling them back.

What Leaders Need to Do Differently This Time

A renewed agile effort does not become credible because leaders choose a better slogan.

It becomes credible when leaders behave differently.

Make the Problem Shared

When teams say something is too much, too soon, or too unclear, do not treat that as refusal.

Treat it as information.

A team saying “we cannot do all of that by then” may be opening the door to a better planning conversation. What is driving the size? Which features matter most? What can be simplified? What can be deferred? What tradeoff would produce the best outcome?

Leaders rebuild trust when they help solve the problem instead of handing the problem down.

Ask for Truth, Not Reassurance

Teams learn quickly what leaders really want.

If leaders reward reassuring answers, teams will provide reassurance. If leaders punish bad news, teams will hide bad news. If leaders treat uncertainty as incompetence, teams will pretend to be certain.

Better leadership questions include:

• What assumptions are we making?

• What could derail this plan?

• What do we need to learn soon?

• What tradeoffs should we discuss?

• What decision do you need from me?

• What would make this easier or more likely to succeed?

• What are we not saying yet?

A team that can tell the truth early gives leaders more options.

Protect Focus

Leaders improve agility by helping teams finish.

That often means reducing work in progress, limiting interruptions, clarifying priorities, and making tradeoffs visible.

If the organization keeps saying yes to everything, teams will keep disappointing someone.

Real prioritization requires disappointment. If no one is disappointed, the organization probably has not prioritized. It has only rearranged the list.

Strengthen Product Ownership

A Product Owner needs more than a title.

Product ownership requires authority, availability, product judgment, stakeholder trust, and the ability to make tradeoffs.

When leaders strengthen product ownership, teams get clearer direction. Stakeholders get a more coherent decision process. The backlog becomes a strategy for value rather than a storage place for requests.

Change the System Around Teams

Teams should improve how they work.

But leaders should also ask what the organization must change around those teams.

That might mean:

• reducing active initiatives;

• changing how priorities are decided;

• clarifying decision rights;

• improving stakeholder participation;

• changing measures that reward the wrong behavior;

• making time for improvement work.

People will believe the next agile effort when they see leaders changing the system, not just asking teams to change their practices.

Involve Skeptics in the Improvement

Skeptics can help.

A thoughtful skeptic may notice risks enthusiasts miss. They may remember what failed last time. They may have credibility with others who are waiting to see whether this effort is real.

Do not give skeptics veto power over improvement. But do give them a voice.

Invite them to help define the problem. Ask them what evidence would change their mind. Include them in improvement conversations. Give them a role in identifying risks. Ask them to review proposed experiments and point out what might go wrong.

A useful question is:

“What would make this improvement worth trying, even if you are not yet convinced it will work?”

That question does not demand belief. It asks for participation.

When to Stop Calling It Agile

Sometimes the word agile carries too much baggage.

If people have been through multiple disappointing initiatives, the label may get in the way. Leaders do not always need to start by asking people to recommit to agile.

They can start with the problems people already care about. Maybe the organization needs to finish more of what it starts, have better planning conversations, reduce rework, make stronger product decisions, get faster feedback from stakeholders, avoid late surprises, or help teams and leaders make tradeoffs together.

Those are agile goals even if the word agile is not emphasized.

The organization can improve agility without making people argue again about whether agile worked last time.

A Better Response to “We Tried Agile and It Didn’t Work”

When someone says, “We tried agile and it didn’t work,” try responding with curiosity.

You might say:

• “Tell me what happened.”

• “What did you hope agile would improve that it didn’t?”

• “What changed for teams, and what stayed the same around them?”

• “What would we need to do differently for this to be worth trying again?”

Those questions change the conversation.

Instead of defending agile, leaders start learning from the organization’s experience. Instead of asking people to forget the last effort, leaders use that history to avoid repeating it.

That is the beginning of a more credible improvement effort.

Is Your Organization Ready to Improve Agility Again?

Use these questions to decide where to start:

• Do we know what disappointed people last time?

• Have leaders acknowledged what did not change enough?

• Are we focused on a business outcome rather than “being more agile”?

• Are improvement items visible in an improvement backlog?

• Are leaders prepared to change the system around teams?

• Do Product Owners have enough authority to make meaningful priority decisions?

• Are teams carrying too much work in progress?

• Are stakeholders participating in feedback and tradeoff conversations?

• Are we using agile events to learn, or just to report status?

• Are skeptics being heard as sources of information?

• Are we trying small improvements and inspecting the results?

• Do people see evidence that this effort is different?

Use the answers to find the next conversation.

Common Questions About Trying Agile Again

Should We Try Agile Again If It Failed Before?

Yes, if the organization is willing to learn from what happened. Do not repeat the same rollout with new terminology. Start by identifying what disappointed people, what outcomes matter now, and what leaders will change in the system around teams.

Is Skepticism About Agile a Bad Sign?

No. Skepticism can be useful. It often contains information about previous attempts, unresolved obstacles, weak leadership support, or ways agile was implemented as process without meaningful improvement.

What If People Hate the Word Agile?

Do not start with the word. Start with the problem. Improve planning reliability, reduce unfinished work, increase stakeholder feedback, clarify product ownership, or help teams finish more of what they start. Those improvements build agility even when the label is not useful.

How Do We Know Whether Agile Really Failed?

Ask what agile was expected to improve and what actually changed. If the organization adopted meetings, roles, or tools but did not change decision-making, product ownership, work in progress, leadership behavior, technical practices, or stakeholder involvement, agile may not have been fully tried.

Should We Hire Agile Coaches?

Coaches can help, but only if leaders are willing to act on what the coaches help reveal. Coaching teams without changing the system around them often produces temporary improvement followed by frustration.

How Can Leaders Rebuild Trust After a Failed Agile Initiative?

Acknowledge the previous experience, name a concrete outcome, choose a small visible improvement, make leadership behavior part of the change, inspect results, and share what is learned. Trust returns through evidence.

What Is the First Improvement We Should Try?

Choose something painful, visible, and small enough to inspect quickly. Common starting points include clarifying Product Owner authority, reducing active initiatives, improving Sprint Reviews, making planning a shared problem, or creating a small improvement backlog.

Related Courses and Workshops

Agile Leadership

Learn how leaders can support we Tried Agile And It Didn’t Work by creating clarity, protecting team ownership, and improving the system around teams.

Private Training for Agile Teams

Use private training to create a shared improvement approach across leaders, teams, Product Owners, Scrum Masters, and stakeholders.

Scrum and Agile Training

Build shared understanding of Scrum and agile practices so teams and leaders can improve we Tried Agile And It Didn’t Work without turning agile into process theater.

Accurate Agile Planning

Learn how to improve planning and predictability conversations without pushing teams into false certainty or unrealistic commitments.

Recommended Articles

• The Five Pillars of a Successful Agile Transformation

• 3 Strategies for an Org-Wide Shared Understanding of Agile

• Why Smart Teams Overcommit and How Leaders Make It Worse

• When Planning Should Become a Shared Problem

• An Iterative Waterfall Isn’t Agile

• Self-Organizing Teams, Their Benefits, and a Leader’s Role

• How To Fail With Agile

Related Pages

• Agile Leadership: Use this when the main issue is how leaders create clarity, support self-organization, remove obstacles, and make tradeoffs.

• Product Ownership: Use this when agile disappointed people because priorities were unclear, Product Owners lacked authority, or the backlog became a collection of requests.

• Agile Planning and Forecasting: Use this when the organization needs better forecasts, more honest planning conversations, and clearer scope/date tradeoffs.

• Scrum: Use this when teams need to revisit Scrum roles, events, artifacts, and how inspection and adaptation are supposed to work.

Tools and Downloads

• Personalized Guide to Agile: A useful starting point for identifying agile goals and challenges.

• Agile Training ROI Calculator: Useful when leaders need to think through the benefits, costs, and value of agile training.

• Overcommitment Toolkit For Leaders: Useful when skepticism comes from repeated overcommitment, unrealistic dates, or poor scope/date tradeoff conversations.

• MGS AI Toolkit: Useful for practicing leadership conversations, stakeholder discussions, and coaching scenarios before having them live.

All Articles on This Topic

• The Five Pillars of a Successful Agile Transformation

• 3 Strategies for an Org-Wide Shared Understanding of Agile

• Why Smart Teams Overcommit and How Leaders Make It Worse

• When Planning Should Become a Shared Problem

• An Iterative Waterfall Isn’t Agile

• Self-Organizing Teams, Their Benefits, and a Leader’s Role

• How To Fail With Agile

Need Help Making Agile Work Better This Time?

If your organization tried agile and did not get the results you expected, the answer is not another slogan or another rollout.

Mountain Goat Software can help you understand what happened, identify the next improvement opportunities, strengthen leadership support, clarify roles, create improvement backlogs, and rebuild trust through small, visible improvements.

Improve Your Agile Initiative

You’ve trained people. You’ve created teams. You’ve named product owners and scrum masters. You have a product backlog. You hold sprint planning, daily scrums, sprint reviews, and retrospectives.

By any reasonable outside measure, you are “doing Scrum.”

And yet, you’re not getting the benefits you hoped for.

Work is not reaching customers faster. Iteration is not happening as rapidly as expected. Quality is not improving much, if at all. Employees are not happier. Teams are frustrated. Work carries over from one sprint to the next. And people are starting to ask why they spend so much time in Scrum meetings if the work still feels slow, chaotic, and unpredictable.

That is a discouraging place to be.

It’s also common.

When Scrum is not working, people are usually trying hard. They are attending the events, filling the roles, and managing the backlog. But effort alone is not enough if the surrounding system keeps pulling teams away from focus, feedback, quality, and delivery.

Blame rarely helps here.

A more useful question is:

What is getting in the way of Scrum helping us deliver value sooner, learn faster, improve quality, and make work better for the people doing it?

Scrum Should Help Teams Move Faster, Not Feel Heavier

I like to think of Scrum as being a bit like the lines painted on a highway.

Those lines are constraints. They tell us where to drive. They limit some choices. I cannot drive in any lane I want, in any direction I want, at any time I want.

Their purpose is to help us go fast safely.

Scrum works the same way.

Scrum gives teams a small set of roles, events, artifacts, and commitments. Those things create structure, focus, and opportunities to inspect and adapt. They help teams move quickly without turning work into chaos.

In many organizations, Scrum starts to feel less like helpful lines on a highway and more like a long list of rules, approvals, reports, templates, and mandates.

When Process Becomes the Goal

Teams are told how they must estimate. They are told when every daily scrum must occur. They are told exactly what must be in every backlog item before anyone is allowed to work on it. They are told that every team must follow the same “best practice,” even when the best practice is not best for that team.

This is when the process police show up.

The process police can appear in any role: scrum masters, agile coaches, managers, consultants, product owners, team members, or anyone else. They are often very well-meaning.

Process matters. But when adherence to a process becomes more important than the results the process is supposed to produce, Scrum starts becoming part of the problem.

That is how Scrum becomes heavy.

Scrum should help teams deliver value more effectively. When Scrum feels like a tax teams pay before they can make progress, something is wrong.

The First Sign Scrum Isn’t Working

One of the clearest signs Scrum is working is that people value using it.

They understand why the events exist. They see the value in sprint planning. They get useful feedback from sprint reviews. They leave retrospectives believing something might actually improve. They see the product backlog as a tool for focus and transparency rather than a bureaucratic dumping ground.

When Scrum is working, people feel that the framework is helping them.

When Scrum is not working, the same events start to feel like waste:

• The daily scrum becomes a status meeting.
• Sprint planning becomes a negotiation over how much work can be stuffed into the sprint.
• The sprint review becomes a demo no one uses to influence what happens next.
• The retrospective becomes a place where the same issues are discussed every two weeks and nothing changes.

At that point, it is no surprise people start saying Scrum has too many meetings.

Often the meeting count gets blamed. More often, the meetings are not producing enough value.

Scrum Events Should Earn Their Place

A useful Scrum event should create clarity, energy, or both.

• Sprint planning should leave people clearer about what the team is trying to accomplish and more confident about how they will begin.
• The daily scrum should leave people clearer about how to coordinate the day’s work.
• The sprint review should produce feedback that can influence what happens next.
• The retrospective should leave the team with something worth improving.

If people leave a Scrum event less clear, less energized, or with no meaningful decision, adjustment, or shared understanding, that event has not earned its place on the calendar.

Inspect the event before canceling it.

Start by asking, “What is this event supposed to help us achieve?”

For example, if the review is not producing useful feedback, ask whether the current design of the meeting achieves that purpose. If not, redesign the meeting.

Keep it short. Keep it energetic. Keep it appropriate. But make sure it does what it exists to do.

Agile Reduces the Cost of Change. It Does Not Make Change Free.

One of the most common reasons Scrum fails to produce benefits is that organizations interrupt sprints too freely.

This happens when:

• someone discovers a new opportunity
• a customer asks for something important
• a competitor makes a move
• a leader has a new idea
• a production problem appears
• something that seemed important two weeks ago now seems less important than something that appeared this morning.

Agile approaches are meant to help organizations respond to change. Pretending change has no cost creates trouble.

Agile can reduce the cost of change. It can make it easier to try new ideas, change direction, learn from feedback, and adjust priorities.

But redirecting a team still has a cost.

The Later the Change, the Higher the Cost

Think about ordering dinner in a restaurant.

You tell the waiter, “I’ll have the chicken.” Ten seconds later, you see the fish being delivered to another table and say, “Actually, I’ll have the fish instead.”

No big deal. There is probably no cost to that change.

But suppose your salad has already arrived and the kitchen has started cooking your chicken. Now changing to fish may have a cost.

And if the waiter sets the chicken in front of you and you say, “No, I want the fish,” the cost is obvious. The chicken has been prepared. Someone has done the work. The restaurant may not be happy. You may need to pay for it anyway.

The same thing happens in a sprint.

Changing direction early may be cheap. Changing direction later is usually more expensive. Changing direction after the team has already done significant work can be very expensive.

And when it happens repeatedly, discarded work is only part of the cost.

Teams begin to wait for the interruption.

They hesitate to fully immerse themselves in the work because they have learned that the work may change. They start to doubt that the product owner has enough figured out for the sprint to be worth committing to. They lose trust in the sprint goal. Eventually, they lose trust in Scrum itself.

That is when you hear people say, “Why are we doing all these Scrum meetings if everything is just going to change anyway?”

That is a reasonable question.

Scrum should make the tradeoffs of change visible. Trying to prevent every change during a sprint would be unrealistic and, in some cases, irresponsible.

When Change Must Enter a Sprint, Have the Conversation

When a genuinely urgent change needs to enter a sprint, bring it into the open.

There should be a conversation between the product owner, the team, and the scrum master. That conversation may be short. It may take two minutes. But it should happen.

The key question is:

Can we accommodate this change without affecting the sprint goal?

If the answer is yes, the team may be able to absorb the change. Teams make small adjustments all the time.

Change Is Allowed. Hidden Tradeoffs Are the Problem.

If the answer is no, the change may still be worth making. But now the tradeoff needs to be explicit.

Something else may need to come out. Stakeholders may need to be told that a previously expected item will not be delivered. The sprint goal may need to be renegotiated. In rare cases, the sprint may need to be canceled.

Those are all legitimate options.

Acting as if urgent new work can be added without consequences damages trust.

When organizations repeatedly add work to a sprint without acknowledging the cost, they create the very problems they hoped Scrum would solve: unpredictability, unfinished work, frustration, and declining trust.

Scrum Struggles When Organizations Try to Do Too Much at Once

Frequent interruptions are often a symptom of a larger problem: lack of organizational focus.

Many organizations are trying to do too many things at the same time. They have too many initiatives, too many urgent requests, too many stakeholders, too many priorities, and too little willingness to say “not yet.”

Scrum makes this visible.

A sprint creates a short planning horizon for deciding what the team can accomplish next. A sprint goal identifies the outcome that matters enough for the team to organize around it. A product backlog makes visible what is more important than what.

Those are uncomfortable questions in an organization that wants everything at once. Avoiding hard choices pushes the difficulty onto teams and product owners.

Product owners are often asked to satisfy too many stakeholders. Teams are asked to start more work than they can finish. Leaders ask for predictability but continue changing priorities. Everyone wants the benefits of focus without making the tradeoffs focus requires.

That does not work.

Focus Requires Saying “Not Yet”

A product owner can help by bringing focus to the team. That means saying what should be done and, just as importantly, what should not be done right now.

But product owners also need support. A product owner who is surrounded by stakeholders who believe every request is urgent will struggle to create focus unless leaders help establish the expectation that not everything can be first.

Scrum exposes the need for difficult prioritization.

Leaders Cannot Treat Scrum as Something That Happens Only on Teams

One of the biggest mistakes leaders make is treating Scrum or agile as something isolated to the teams.

Teams can be agile and do Scrum. But that is not sustainable if the surrounding organization remains largely unchanged.

Scrum Needs the Right Environment

Scrum asks teams to focus, collaborate, inspect, adapt, and deliver valuable increments of work. For that to happen, leaders have to create an environment where those behaviors are possible.

That often means eliminating silos and forming cross-functional teams. It means giving teams a challenge and then getting out of the way enough for them to solve it. It means resisting the temptation to second-guess team decisions. It means allowing teams to tell the truth about overly optimistic deadlines, unrealistic scope, and risks they see in the work.

A team cannot do its best work while being pressured to commit to things it does not believe are feasible.

A team cannot be self-managing if every meaningful decision is made somewhere else.

A team cannot deliver predictably if leaders constantly redirect it and then act surprised when the original plan is not met.

Good leadership support means shaping the environment so teams can succeed.

When a desired deadline or desired scope is not feasible, leaders and teams should treat that as a shared problem to solve. It should not become a team failure or a negotiation in which the team is expected to eventually give in.

Maybe the scope can be reduced. Maybe more time is needed. Maybe a different approach is possible. Maybe another initiative should be delayed. Maybe the organization needs to accept more risk.

The first step is telling the truth.

Scrum works better in organizations where truth is welcome.

Scrum Masters Need to Work Beyond the Team Boundary

When Scrum is not working, Scrum Masters sometimes stay too close to the team.

They facilitate the events. They coach the team. They encourage better collaboration. They help with retrospectives.

All of that can be useful.

But many of the impediments that keep Scrum from working live outside the team.

Frequent interruptions may come from stakeholders. Unrealistic pressure may come from leaders. Overloaded product owners may be caught between too many competing demands. Reporting requirements may distort how the team uses Scrum.

If the biggest impediments are organizational, the Scrum Master’s work cannot stop at the team boundary.

Scrum masters may need to educate people outside the team about the impact of interrupting a sprint. They may need to help leaders understand what Scrum is making visible. They may need to make organizational impediments explicit. They may need to help the team and product owner protect the sprint goal. They may need to challenge habits that make Scrum feel like ceremony instead of a way to deliver value.

The scrum master helps the organization use Scrum for its intended purpose, without becoming the Scrum police.

Be Careful When Adding Rules to Teams

Scrum and agile teams are meant to be self-managing.

Self-managing teams still work within constraints. Organizations will always set some boundaries, and that is normal and appropriate.

A company can tell a team what problem it needs solved. It can establish standards for security, compliance, architecture, or tooling. It can ask teams to coordinate with each other in certain ways.

Constraints are not automatically bad.

The challenge is knowing when there are too many.

Each rule may seem reasonable by itself. But teams experience the total weight of all the rules, policies, approvals, templates, expectations, and reports placed on them.

At some point, one additional rule becomes the straw that breaks the camel’s back.

The team stops feeling empowered. Team members stop thinking, “How should we solve this?” and start thinking, “They just tell us what to do around here.”

That is a dangerous shift.

A useful test for organizational constraints is this:

Is this constraint truly for the benefit of the teams and the work, or is it mainly for the convenience of oversight?

Standardizing on a common tool for product backlog management or defect tracking may help teams. It can make movement between teams easier. It can support coordination. It can reduce confusion.

Mandating that every daily scrum must happen before noon because a development director wants time to read the notes in the afternoon is different.

That serves reporting convenience by centralizing a decision that should remain with the team.

Some organization-wide rules are useful. Others mainly make the organization feel more in control. A useful rule helps teams move faster, coordinate better, or both.

Don’t Fix Scrum in One Big Batch

When Scrum is not working, organizations often want a big reset.

They want to redesign the process. Rewrite the working agreements. Schedule training. Change the tooling. Update the roles. Fix the backlog. Improve the meetings. Clarify the metrics. Repair the relationship between teams and stakeholders.

These may be necessary. But trying to fix everything at once usually creates more confusion than progress.

Improve Scrum the Same Way Scrum Improves Work

Use agile to improve your use of Scrum.

Inspect. Adapt. Improve iteratively and incrementally.

Ask, “What do we believe is the biggest root cause of Scrum not working well here?”

Then try to improve one thing. Maybe two, if you can do so without creating confusion.

If work is carrying over every sprint, maybe the first experiment is to leave the team alone for a sprint or two and see what changes.

If Scrum meetings feel wasteful, maybe the first experiment is to agree on the purpose of each event and redesign it to achieve that purpose.

If sprint planning is painful, maybe the first experiment is to improve refinement just enough that fewer unresolved issues enter the sprint.

If teams are overcommitting, maybe the first experiment is to pull in less work and inspect whether finishing more creates more trust and energy.

If sprint goals are vague, maybe the first experiment is to make the goal real enough that it can guide tradeoff decisions during the sprint.

Trying to perfect Scrum in one giant batch misses the point.

Scrum is built on inspection and adaptation. Use those same ideas to improve Scrum itself.

Done Well, Scrum Feels Good

When Scrum is working, it feels like progress rather than bureaucracy.

Teams finish work. Stakeholders respond to what they see. Users get value sooner. The business sees impact. Team members feel trusted. Problems surface earlier. Decisions become clearer. The organization learns faster.

That creates a virtuous cycle.

Progress creates energy. Energy improves collaboration. Better collaboration improves delivery. Delivery creates trust. Trust makes it easier to focus. Focus helps the team make more progress.

Done well, Scrum feels good.

Scrum is not effortless. It feels good because people can see that the work matters and that their way of working is helping them do that work better.

That is very different from Scrum as ceremony, reporting, or compliance.

If your organization is doing Scrum but not getting the benefits you hoped for, start with better questions than whether everyone is following every rule correctly:

• Are our Scrum events creating clarity and energy?
• Are we protecting the sprint goal enough for it to matter?
• When priorities change, are we making the tradeoffs visible?
• Are leaders creating an environment where teams can focus and tell the truth?
• Are product owners supported in saying what should not be done yet?
• Are scrum masters helping remove impediments beyond the team boundary?
• Have we added rules that make Scrum heavier without making work better?
• Are we trying to fix everything at once, or improving one thing at a time?

Scrum works best when people understand why the practices exist.

The practices matter because they help teams and organizations deliver value, learn from feedback, make tradeoffs, and improve. The Scrum Guide, a consultant, or an organizational rule can describe the practice, but they cannot substitute for understanding why the practice exists.

If Scrum is not doing that for you yet, do not give up on it too quickly.

And simply doing Scrum harder will not help.

Inspect what is getting in the way. Pick one thing to improve. Try a change. Learn from it. Then improve again.

That is how Scrum starts working.

Too often, though, it gets treated as fixed. The leader says what they want and when they want it, leaving the team to figure out how to make it happen. If the work does not fit, the problem somehow becomes the team’s problem alone.

That is not the best way to approach planning.

Most leaders want more than can reasonably be achieved in the time available. That is not because they are unreasonable. It is because they are trying to create value, respond to pressure, and move quickly. They want the most they can get. That is normal.

But when what is wanted exceeds what can be done, the answer should not be, “Team, go solve that.” It should be a shared problem. The leader and the team should work together to find the best way forward.

That may mean delivering fewer features by the desired date. It may mean extending the date. It may mean simplifying part of the request. Whatever the answer is, the responsibility for finding it should be shared.

Why Leaders Default to Pressure

This situation frustrates leaders as much as it frustrates teams. A leader wants something important. The team says it cannot do everything in the available time. That is not a satisfying answer for either side.

Without a better response, many leaders default to pressure. They tell the team, in effect, “Go figure out how to make it happen.”

That reaction is understandable. Part of what drives it is hierarchy. Part of it is urgency. People are busy and want an answer fast, not a discussion of trade-offs or which subset of the request would best meet the real need. And part of it is experience. Many leaders have seen teams miss badly, gold-plate work, or let things drift because no one forced a hard conversation about time.

So some leaders conclude that the only way to get what they need in a reasonable timeframe is to set an aggressive deadline for the team and keep the pressure on.

This Has to Be Balanced

Leaders are usually well-intentioned. They are overloaded. They are moving fast. It is natural for them to want a quick yes-or-no answer.

Teams, meanwhile, do not create unreliable plans because they want to. Their plans are often unreliable because they are pressured into answering too early, or because they haven't had the chance to develop the skills needed to turn estimates into reliable plans. If organizations want better planning, they need to help teams develop those skills.

I do not see this as a story about bad leaders and innocent teams. I see it as a system problem. Leaders often push too hard because teams have not always been reliable. Teams are not always reliable because they are often pushed too hard. Both sides have work to do.

What Better Leaders Do

The best leaders respond differently when they hear that a request is too much for the available time.

They get curious, not judgmental.

Instead of reacting with frustration, they ask what is making the request too large. Instead of treating the team’s answer as resistance, they treat it as information. They want to understand what is driving the difficulty.

Sometimes it is one feature or edge case that has an outsized impact on the schedule. If a leader understands that, the conversation changes. It is no longer about whether the team is trying hard enough. It becomes a discussion about what matters most.

That is what I mean when I say planning should be a shared problem. The team is not there just to receive demands and go make them happen. The team is there to help the organization make good decisions about what can be done, by when, and at what cost.

A Good Example of Shared Problem Solving

I worked with a team that was building human resources software. They were about to begin work on a feature that would let a manager approve an employee’s request for time off. The feature was going to take longer than the leader, Adam, wanted.

Adam handled that well.

Instead of just pushing the team to go faster, he asked what was making the feature big.

It turned out that much of the complexity came from a relatively infrequent situation: employees with two managers. The team needed to figure out how approvals should work in that case. Would both managers need to approve the time off? Would some organizations accept approval from only a primary manager? Would others accept approval from either manager? Answering those questions was enough to push the feature beyond the desired timeline.

When Adam heard that, he decided to simplify the initial release. The initial version would ship without full support for employees with two managers. For that first release, the manager who had first been assigned to the employee would approve the vacation request. That was good enough because full support for the more complex case was expected only a week or two later.

That is a good example of planning as a shared problem. Adam did not dump the problem on the team. He helped solve it by understanding where the complexity really was and making a thoughtful tradeoff.

The Goal Is Often Not Everything

When a team tells a leader, “No, we cannot do all of that by then,” leaders sometimes hear that as the end of the conversation.

Usually it is the start of a better one.

A team may not be able to deliver everything a leader wants by a given date. But that does not mean there is no good solution. It often means there is another solution that is almost as good, or good enough to meet the real need.

That is the mindset I would like more leaders to adopt. The goal is not always to get everything. It is to find the best good-enough solution.

That may mean dropping a less important feature. It may mean simplifying a workflow. It may mean releasing an initial version that handles the common case first and the harder case shortly after. Those are not failures. They are often the smartest decisions available.

The mistake is hearing the team’s “no” as a refusal instead of hearing it as the beginning of a problem-solving discussion.

To help with conversations like this, I created the Overcommitment Toolkit for Leaders. It includes a shared planning worksheet, better leader questions, and a simple guide for working through scope, date, and tradeoff decisions with a team.

Teams Have a Responsibility Too

Saying that planning should be a shared problem does not let teams off the hook.

Teams have an important responsibility here: they need to create reliable plans.

Reliable does not mean perfect. A team does not need to hit every sprint goal exactly. It does not need to meet every milestone with perfect precision. But it needs to be reliable enough that the business can make sound decisions based on what the team says.

That is the standard I care about most. A reliable plan is one that leads to the right business decision.

Suppose a team says something will take three months, and it winds up taking a little more than three months. That plan may still have been reliable enough if it helped the business make the right choice about whether to invest in that work. On the other hand, if the team routinely misses badly, leaders stop trusting it. And once leaders stop trusting the team, it becomes much harder to have the kind of shared planning conversation I am advocating here.

A team that has delivered reasonably reliably over time earns credibility. When that team says, “No, we cannot do all of that in three months,” a leader is far more likely to believe it and engage in solving the problem together.

What Is at Stake

When planning is not treated as a shared problem, the cost is not just a worse plan.

Teams stop being treated like equal partners. Instead of being included in the decision about what gets done by when, they become the place where demands go. That hurts morale. It makes planning feel political. And it makes teams less likely to bring up hard truths early, because they have learned those truths are not welcome.

When that happens, leaders do not just get worse planning. They create a culture in which the team feels acted on rather than worked with.

That is not a culture where the best decisions get made.

Start the Conversation There

A leader’s desire for a set of features by a given date should be treated as the starting point of a conversation.

Leaders should make that request knowing it is entirely possible the team will say it is too much or too soon. In fact, most of us want more than can be achieved. That is normal. What matters is what happens next.

The best leaders do not assume the team’s job is to somehow make the impossible happen. They get curious. They ask what is driving the size. And they work with the team to find the best good-enough solution.

Teams, for their part, need to become reliable enough that leaders can trust what they say. Organizations need to help them develop those planning skills.

A leader’s request is the beginning of the discussion, not the end of it.

Want a practical tool for these conversations?

Download the Overcommitment Toolkit for Leaders. It includes a shared planning worksheet, better planning questions, and a simple guide to separating forecasts, plans, and commitments so leaders and teams can work toward the best good-enough solution together.

They struggle because they’re trying to use stories to do too many jobs at once—capture requirements, prevent misunderstandings, document edge cases, satisfy compliance, and (somehow) still fit everything into a sprint. The result is predictable: stories that are either so vague they force guessing, or so detailed they become miniature specifications.

The Story Critic skill, developed by Mountain Goat Trainer Cort Sharp, can be added to AI platforms like ChatGPT and Claude. You can try the Story Critic below, download a skill you can install, or use it through a free Mountain Goat Essentials account.

The skill is designed to help with the day-to-day reality for team-level practitioners—developers, testers, analysts, designers, and product owners—who have to refine, estimate, split, and deliver work. It helps create backlog items that are better conversation starters while still pushing you toward clarity on what “done” means.

User stories are supposed to shift the focus from writing requirements to talking about them, and the conversations matter more than the sentence on the card.

What the Skill Does (and Why It Makes Two Separate Judgments)

The Story Critic makes two different calls about every item:

1. Headline Coaching Assessment: How strong is the item as written?
2. Backlog Placement Guidance: Is this level of detail appropriate for near-term work or does it belong lower in the backlog?

That second judgment matters because a light story can be excellent if it’s intentionally lower in the backlog. And a detailed story can also be excellent—if you’re actually going to build it soon. That “just in time and just enough” mindset is a big part of how I think about writing and refining backlogs.

What the Story Critic Looks for in a Good Backlog Item

It’s not trying to turn your backlog into perfectly templated user stories. In fact, one of its best traits is what it doesn’t care about:

• It won’t scold you for writing “I can…” instead of “I want…”
• It won’t demand acceptance criteria on every item
• It won’t treat formatting as the point of the exercise

Instead, it focuses on the things that actually determine whether a team can refine and deliver:

• Outcome Clarity: What changes for the user (or system) if this is done?
• Scope Focus: Is it one idea, or several bundled together?
• Testability: Can the team answer, “What must be true for this item to be considered complete?”
• Backlog Fit: Is it the right amount of detail for where it sits?

In other words, it’s trying to help your team spend refinement effort where it creates the most value—keeping the top of the backlog sprint-sized and workable without turning refinement into paperwork.

The Headline Coaching Assessment Levels

The skill uses six levels. Think of these as “what kind of conversation do we need next?” rather than as grades:

• Ready for Implementation: clear, testable, small enough for near-term delivery.
• Ready for Refinement: focused, structured; estimate with minor clarification.
• Nearly There: strong intent/value; a few gaps will create friction.
• Good Start: meaningful idea; still too vague to estimate well or begin work on.
• Needs Significant Refinement: unclear, bundled, solution-heavy, or hard to test.
• Not Yet a Story: a task/fragment without a clear outcome.

A team can use these levels as a quick triage mechanism: Which items are close enough to estimate? Which need story splitting? Which should stay light for now?

Backlog Placement Guidance: How It Relates (Without Being the Same Thing)

After the headline assessment, the Story Critic adds one of four placement labels:

• Appropriate for lower backlog
• Appropriate for near-term work
• Too light for near-term work
• Too detailed for lower backlog

This is where teams often get tripped up. They assume “more detail” always means “better story.” But detail is only valuable when it’s timely. The whole point of writing stories is to preserve agility—so you can change direction and learn as you go—not to lock yourself into yesterday’s assumptions.

Practically, the relationship looks like this:

• A story can be Good Start and Appropriate for lower backlog (a perfectly fine placeholder).
• A story can be Ready for Refinement and Too detailed for lower backlog (overspecified far too early).
• A story can be Needs Significant Refinement and still be Appropriate for near-term work (because you’re about to do it, but you need to split and clarify first).

Multiple Output Formats (So You Can Match the Moment)

The skill supports multiple output styles, which is important because teams need different feedback at different times:

• Quick critique: headline + a few priorities (great right before refinement)
• Full critique: a structured, detailed coaching review (great when an item is stuck)
• Batch review: scan a set of items and identify patterns across the backlog
• Rewrite-only: when you mostly want a cleaner version (without the long diagnosis)

Examples (Zoom Product Backlog)

Below are three ways a team might use this skill.

Example 1: Submitting a Simple Story (Quick Critique)

Prompt

Give me a quick critique of:

When I schedule a Zoom meeting, I want to get a URL so that I can share it.

Example Output (Quick Critique)

When I schedule a Zoom meeting, I want to get a URL so that I can share it.
- Ready for Refinement - Clear outcome, but the team will immediately ask what “get a URL” includes (where shown, when available, and whether it’s copyable).

### Backlog Placement Guidance
Appropriate for near-term work
- **Top Coaching Priorities:**
  - Clarify where the URL appears and when it’s generated (after save, on invite screen, in calendar integration, etc.).
  - Make the completion signal observable: The team understands what must be true for this item to be considered complete.
- **One question to unlock the outcome:** Where in the scheduling flow does the user need the URL, and what’s the minimum UI that makes it shareable?

That’s the kind of feedback teams can act on immediately in refinement without turning a small story into a dissertation.

Example 2: Submitting a Story with Acceptance Criteria (Full Format)

This one is intentionally realistic: a story with a lot of acceptance criteria. That’s common when teams are trying to reduce risk or prevent rework—especially on UI-heavy features.

Prompt (Acceptance Criteria Shown In Part For Readability)

Critique this story:

As a Zoom meeting participant, I want to be able to chat via text with others in the meeting so that I can ask questions and such without interrupting the meeting.

Acceptance criteria (not all shown):
- Chat is available to all authenticated meeting participants while the meeting is in progress.
- A participant can send a text message to everyone in the meeting.
- A participant can send a 1:1 direct message to another participant.
- Incoming messages appear in near real time without requiring a page refresh.
- Unread message indicator is shown when the chat panel is closed/minimized.
- If message delivery fails, the sender is notified and can retry.
- Only meeting participants can view messages for that meeting.
- Messages persist for the duration of the meeting so participants can scroll back.

Example Output (Full Format)

As a Zoom meeting participant, I want to be able to chat via text with others in the meeting so that  I can ask questions and such without interrupting the meeting.

### Headline Coaching Assessment
- Needs Significant Refinement
- Strong user outcome, but the acceptance criteria bundle multiple message types and UX behaviors into what is likely an epic that will be hard to estimate without story splitting.

### Backlog Placement Guidance
Appropriate for near-term work

### Coaching Snapshot
- **Item Type:** User Story  
  This is a user-facing capability with a clear benefit: ask questions without interrupting.
- **Structure:** Clear  
  Who + capability + why are present; the criteria add useful detail.
- **Outcome or Result Clarity:** Concrete and Observable  
  “Participants can send and receive chat messages during a meeting” is demonstrably true.
- **Focus:** Multiple Objectives  
  The criteria cover several distinct slices (everyone chat, 1:1, delivery behavior, indicators, persistence, permissions).
- **Testability:** Needs Clarification  
  Many parts are testable, but “near real time” and “authenticated participants” need a shared interpretation for verification.
- **Acceptance Criteria:** Present but Needs Refinement  
  Helpful and mostly aligned, but large enough that it risks becoming a mini-spec instead of supporting refinement.

### Strengths
- The core outcome is clear and valuable during meetings.
- The criteria include a strong completion signal around permissions (participants only).
- The criteria acknowledge failure cases (delivery fails, retry), which teams often discover late.

### Top Coaching Priorities
1. **Split this into a smallest viable slice** (start with “message everyone” before adding 1:1 and ad-hoc group messaging).
2. **Keep the criteria that define ‘done’ and move optional enhancements into follow-on items** (emoji, advanced indicators, performance targets, etc.).
3. **Clarify the few terms that will block estimation** (what “authenticated participant” means and what “near real time” means in testable terms).

### Split Guidance (Optional)
- Split by message target: everyone-first, then 1:1, then ad-hoc group messages.
- Split by experience: send/receive messages first, then unread indicator, then persistence/scrollback enhancements.

### Questions to Ask During Refinement (Optional)
- Are guests included, or is chat restricted to signed-in participants only?
- Is persistence strictly “during the meeting,” or should there be any after-meeting access?
- What’s the minimum acceptable “real time” behavior we can verify in tests?

### Improved Version(s)
- **Rewrite #1 - Same Template, Improved Clarity**  
  As a Zoom meeting participant, I can send and read text messages during a meeting so I can ask questions without interrupting.

- **Rewrite #2 - Alternative Template (Optional)**  
  When I’m in a Zoom meeting, I want to message other participants in text so I can participate without speaking over the meeting.

Notice what the critique is doing: it’s not rewriting everything. It’s trying to get the team to the point where they can estimate and deliver by splitting the work, which is often the real lever in refinement.

Example 3: Submitting a Product Backlog with Multiple Items (Batch Review)

In practice, teams often want a fast scan across a backlog. They’re trying to decide, “What’s close? What’s risky? Where should we spend refinement time?”

Prompt (One Product Backlog, One Item With Acceptance Criteria)

Batch review these backlog items for Zoom:

1) As a Zoom meeting participant, I want to be able to chat via text with others in the meeting so that I can ask questions and such without interrupting the meeting.
   (Includes acceptance criteria)

2) When a Zoom meeting ends, I want Zoom to close so that I stop sending audio and video.

3) When I schedule a Zoom meeting, I want to get a URL so that I can share it.

4) When my mic volume is too low or too high, I want Zoom to adjust it so I always sound awesome.

Example Output (Batch Review)

1) As a Zoom meeting participant, I want to be able to chat via text with others in the meeting so that  I can ask questions and such without interrupting the meeting.
- Needs Significant Refinement — Great outcome, but bundled scope across multiple message types and UX behaviors.
### Backlog Placement Guidance
Appropriate for near-term work

2) When a Zoom meeting ends, I want Zoom to close so that I stop sending audio and video.
- Ready for Refinement — Clear safety outcome; the team will just need to clarify what “close” means across platforms and edge cases.
### Backlog Placement Guidance
Appropriate for near-term work

3) When I schedule a Zoom meeting, I want to get a URL so that I can share it.
- Ready for Refinement — Clear value; needs minor clarification about where/when the URL appears.
### Backlog Placement Guidance
Appropriate for near-term work

4) When my mic volume is too low or too high, I want Zoom to adjust it so I always sound awesome.
- Good Start — Intent is clear, but “adjust it” hides important questions (how, when, and what constraints).
### Backlog Placement Guidance
Too light for near-term work

Patterns Across The Set
- The strongest items have an observable outcome and a clear completion signal.
- The weakest items are “clear in spirit” but hide the key decisions the team needs to estimate.

Rewrite (Weakest Item)
- When my mic volume is outside an acceptable range, Zoom can automatically adjust input gain so my volume stays within that range.

This is the kind of output teams can use to choose a short refinement agenda: split chat, clarify “close,” clarify where the URL appears, and pull the mic story forward with a better outcome definition.

How I Recommend Teams Use This

If you try this skill once and treat the output as a verdict, you’ll be disappointed. That’s not what it’s for.

Where it helps is as a lightweight coach in three places teams already spend time:

• Before refinement: run quick critiques to surface the top 1–2 questions you’ll need to answer anyway.
• During story splitting: use it to confirm you actually reduced scope rather than just rearranged words.
• Before sprint planning: batch review the top of the backlog to spot “too light” items before the meeting starts.

Refinement is hard enough when the backlog is good. When it isn’t, refinement becomes a recurring meeting where everyone feels busy and nobody feels confident. A tool that nudges items toward better conversation—and clearer “done”—can save teams from a lot of avoidable pain.

Install

You can download a zip file containing the skill and then install it within ChatGPT or Claude.

You can also sign up for a free MGS Essentials account, which gives you access to the Story Critic as well as other AI tools developed specifically for agile teams.

Make the Skill Your Own (by Editing a Few Files)

If you like what the Story Critic does, you can make it even more valuable when you tune it to match your team.

You don’t have to rewrite the whole skill. Small, targeted edits change the coaching in useful ways:

• Update the rubric to match what your team actually values in refinement. If you care most about “what must be true when we’re done,” make that explicit. If you want the coach to push harder on story splitting, say so.
• Add examples that look like your backlog. The fastest way to steer the coach is to give it a handful of “good” and “needs work” stories from your product domain—same vocabulary, same kinds of constraints, same level of detail you consider healthy.
• Keep a few regression test examples—stories you can re-run after edits to confirm the skill still behaves the way you want. Think of these as unit tests for your coaching style.

A practical starting point is to tune three things:

1. Vocabulary: product terms, roles, and common nouns the skill should preserve in rewrites.
2. Strictness: what “near-term work” requires on your team (for example, a clearer completion signal).
3. Splitting: state which of the SPIDR splitting patterns you prefer or tell it to use a different splitting approach

The goal isn’t to turn the Story Critic into a rulebook. It’s to turn it into a coach that speaks your team’s language and helps you get to better refinement conversations faster.

Most teams do not need a leader to pressure them into overcommitting.

They’ll usually do it on their own.

That may sound surprising. We often think of software developers as skeptical or cynical. But in my experience, developers are often deeply optimistic. They believe in making things better. They’ve seen how technology can improve lives and change businesses. That optimism is part of what makes them good at what they do.

It also shows up in their estimates.

Ask a team how much they can do in a sprint, a quarter, or by the end of the year, and most teams will choose a bit too much. Sometimes a lot too much.

That doesn’t mean they are careless. It means they are human.

And that is exactly why leaders need to be careful. If a team is already prone to overcommitting on its own, any added pressure from above can push that team into dramatically overcommitting.

I learned this the hard way early in my career. When I was first promoted into leading a team, I thought deadlines would be pretty simple. My management philosophy, if you could call it that, was this: ask team members for estimates, assume those estimates are optimistic, and then hold people to their own optimistic estimates.

That did not work.

The problem was not that my team was irresponsible. The problem was that I was treating optimism like a contract.

Teams Are Already Optimistic

This is the first thing I want leaders to understand: overcommitment usually starts before a leader says a word.

Software teams often make reasonable plans based on incomplete information. They do their best. They look at the work in front of them. They make assumptions about what will go well. They imagine a path through the work and estimate based on that path.

That is normal.

But because they are optimistic, they often lean toward the best or near-best case without realizing it. And because software work contains uncertainty, even a sensible plan can fail.

Think about driving across town for an appointment. You consider the distance, the time of day, and the usual traffic. You conclude that 30 minutes is enough, and most of the time you’re right. But one day a train blocks the tracks for 10 minutes, and suddenly you’re late.

Your estimate was not foolish. It was the best estimate. It just failed in that instance because of bad luck.

The same thing happens to teams.

Sometimes a team really does plan poorly. But sometimes the team chose the most likely outcome and still missed because uncertainty showed up in an inconvenient form.

Leaders need to make room for that reality.

How Leadership Pressure Causes Teams to Overcommit

Because teams are already optimistic, pressure matters more than many leaders realize.

Sometimes leaders apply pressure intentionally. They want more, they want it sooner, and they say so directly.

But pressure also shows up unintentionally.

A leader can create pressure with a question, a tone of voice, or even body language. I once worked with a leader named Erin who was a genuinely upbeat and positive person. As she walked through the office, she would greet people with questions like, “Getting a lot done today?”

She did not mean anything harmful by it. In fact, her bigger concern was quality. She wanted the team to slow down enough to do good work. But what the team heard was daily pressure about productivity.

When I pointed this out, she changed her greeting to something deliberately silly: “Staying bug-free today?”

That small change mattered. It signaled what she actually cared about. And because it was almost humorous, it broke the old pattern.

That example sticks with me because it shows how easy it is for leaders to communicate one thing and be heard another way.

Even a simple “How are things going?” can feel like pressure if team members hear it as, “Tell me you’re on track.”

What Pressure Does to Teams

Pressure does not remove uncertainty. It changes how teams behave around uncertainty.

When teams feel pressure, they tend to choose their most optimistic estimate instead of their most realistic one. They become less willing to expose risks. They stop looking very hard for what could go wrong, partly because discovering bad news becomes uncomfortable.

The risks do not disappear. They just go underground.

That is one of the most dangerous effects of pressure. It doesn’t just distort what teams say. It distorts what they are willing to examine.

Sometimes pressure also pushes teams toward longer hours. In a true crisis, working a bit extra this week may be fine. But that is not a long-term strategy for sustained productivity. Eventually, excessive effort leads to fatigue, mistakes, and lower quality.

And once quality starts slipping, teams often make the situation worse by rushing. They start saying things like, “We’ll clean that up later,” or “We can do that in another sprint.”

Urgency is fine. Rushing is not.

I like the distinction often attributed to John Wooden: be quick, but don’t hurry. That is exactly what leaders should want from teams. Move with energy, but not with panic.

Forecast vs. Plan vs. Commitment

One reason leaders and teams get into trouble is that they use the same words to mean different things.

A forecast is a prediction about the future.

A plan is what we expect to do based on that forecast.

A commitment is what we are confident we will do, with enough margin to make that credible.

Those are not interchangeable.

A team may estimate individual backlog items and, from those estimates, assemble a sprint plan or a three-month milestone plan. That plan can be thoughtful, disciplined, and useful. But it is still not a guarantee.

A commitment is different. A commitment requires margin.

If I think I can drive across town in 30 minutes, that is a plan. If I need to truly commit to being there on time, I might leave 40 minutes early. The extra time is not waste. It is the cost of certainty.

Leaders understand this idea in other parts of business. A company may internally forecast earnings of $5 per share. But when it communicates externally, it might commit more conservatively to $4.50. Same business, same leaders, same reality. They understand that commitment requires room for things to go wrong.

Software development is no different.

So yes, leaders can ask for commitments. They can ask for commitment to a sprint, to a feature, or to a multi-month goal. But they need to recognize that committed scope must be smaller than planned scope, and planned scope must usually be smaller than optimistic scope.

How Anchoring Pushes Teams Into Overcommitment

One of the most common ways leaders cause overcommitment is through anchoring.

Anchoring happens when a leader frames the answer before the team has done its own thinking.

A leader asks, “Can you deliver these features in three months?”

That sounds innocent enough. But it is not neutral. The team has now heard both the amount of work and the desired timeframe. They know what answer the leader is hoping for. They want to be helpful. They want to please people. So instead of independently determining what is realistic, they start searching for a path to yes.

I saw this vividly years ago when I was a VP of development at a public company. My boss asked whether a certain product could be delivered by the end of the year. We needed revenue in the current year, and that product could help.

I went back with my team and worked through the plan. Our initial answer was something like mid-February. We cut some things, revised the plan, and managed to get a plan that said mid-December. Great, we thought. We would meet the business need.

What I had failed to account for was that our customers would not make beta testers available in November and December. They were too busy. That caused the release to slip into January.

Now step back and look at what happened. On an 11-month effort, we missed by only a couple of weeks. That is actually pretty good planning. But because the whole point was to get revenue booked that year, the outcome was a failure.

And I think the failure began with the question.

Had my boss asked, “When can we get this?” I likely would have returned with February or March. That would have led to the correct business decision: don’t do the project for this purpose. But “Can you do it by the end of the year?” anchored us to a desired answer, and we (I) found a way to almost get there.

Almost was not enough.

Ask for Truth, Not Reassurance

The best leaders make it clear what they are asking for.

Do they want a forecast? A plan? A commitment?

They also make it safe to tell the truth.

That safety does not come from saying, “Bring me good news.” It comes from asking questions that invite reality:

• What assumptions are you making that may not hold true?
• What could derail this plan?
• What dependencies are built into this?
• Is this your optimistic case, most likely case, or pessimistic case?
• What should I know about the thinking behind this?

Those are very different from questions that imply, “Please reassure me.”

The difference matters. A healthy check-in is not one that makes the team say everything is fine. A healthy check-in is one that helps the team surface what may not be fine.

And when a leader hears bad news, the most important first response may simply be: “Thanks for telling me.”

That one sentence tells the team that truth is valued.

Planning Should Be a Shared Problem

This is the agile leadership habit I most want to change.

Too often, leaders treat planning as the team’s problem alone. The leader asks for a plan. The team provides one. Then the leader either accepts it or says, in effect, “That’s not good enough. Hit the date anyway.”

That is not planning. That is pressure.

Planning should be a dialogue.

A team should present its plan. The leader should acknowledge the effort that went into it. And if the leader hoped for more, the response should be something like: “I was hoping for more, sooner. What can I do to help us achieve that?”

That changes everything.

Now the conversation becomes collaborative. Perhaps one large feature can be removed. Perhaps a lower-priority outcome can move to a later release. Perhaps a couple of extra weeks changes the risk dramatically. Perhaps adding a person helps. Perhaps the mobile app can come later.

The point is not that every problem has an easy answer. The point is that the answer should not be forced entirely onto the team.

Planning is a shared problem.

The Cost of Repeated Overcommitment

When teams repeatedly overcommit, the first damage leaders notice is usually missed goals.

The deeper damage is loss of credibility.

If a team fails to achieve its sprint goal or milestone sprint after sprint, eventually no one trusts the next plan. That is hard on everyone. It is hard on leaders because they stop getting usable information. It is hard on teams because even when they finally tell the truth, nobody believes them.

Repeated overcommitment teaches the organization to distrust reality.

That is why this issue matters so much. This is not just about making one sprint go better. It is about preserving the ability of a team and its leaders to have honest, useful planning conversations.

What Leaders Should Ask Instead

If you are a leader, here is the simplest shift I can offer.

Stop asking questions that reveal the answer you want.

When a leader asks, “Can you do this in three months?” the team has already been anchored. They now know the date the leader wants, and many teams will begin looking for a way to make that answer come out yes.

A better question is: “Here is what I need. When can you do it?”

Let the team answer that question first. Then compare their answer to your hoped-for date. If the answer is later than you want, don’t turn that into pressure. Turn it into a conversation.

Then follow that with questions like:

• What are you assuming will go well?
• What could derail this?
• What dependencies matter here?
• Is this a forecast, a plan, or a commitment?
• What can we do together to improve the outcome?

Those questions do not reduce accountability. They improve it. They help teams think more clearly, speak more honestly, and plan more credibly.

That is what leaders should want.

Teams do not overcommit because they are irresponsible. They overcommit because optimism is natural, software work is uncertain, and leadership behavior shapes what teams feel safe saying.

The best leaders do not squeeze harder. They create the conditions for truth. They distinguish forecasts from commitments. And they treat ambitious delivery as a shared problem to solve together.

That is how you get better plans. And, over time, better outcomes.

Want Help Putting This into Practice?

Download the Overcommitment Toolkit for Leaders. It includes a quick diagnostic to spot overcommitment patterns, a guide to separating forecasts from commitments, and a set of better planning questions you can use to get more honest answers from teams.