If you’ve ever worked with a Scrum Team that’s struggling to achieve its Sprint Goals, you’ll probably recognise the situation I’m about to describe.
The team begins a new Sprint with plenty of enthusiasm, everyone agrees on the work they hope to complete, and the Sprint Planning meeting finishes with a reassuring sense that things are under control.
Then, somewhere around the middle of the Sprint, problems begin to emerge. A requirement turns out to be more complicated than expected, somebody is waiting for an important decision, testing takes longer than anticipated, and before long the team is discussing which items will have to be carried forward into the next Sprint.
Now, an occasional disappointment is hardly unusual in project management, and I certainly wouldn’t expect every Scrum Team to achieve everything it originally anticipated. After all, one of the reasons we use Scrum is that we’re dealing with complex work where we can’t always predict exactly what will happen.
However, when a team repeatedly finishes its Sprints without achieving the outcomes it set out to deliver, I think it’s worth looking beyond the usual explanations about poor estimates, unexpected interruptions or people simply having too much work to do.
What interests me is that the underlying problem is often not a lack of effort or commitment.
In fact, I’ve encountered situations where people are working extremely hard, attending all the expected Scrum events and doing their best to meet their responsibilities, yet the team continues to struggle. The difficulty is that the way the work has been organised makes it unnecessarily hard for everyone to achieve a shared objective.
So, let’s explore why Sprint Goals are missed, what the warning signs look like, and how we can make some practical improvements without turning Scrum into yet another complicated management procedure.
First, Let’s Understand What a Sprint Goal Is Supposed to Achieve
Before we investigate the problems, I think we need to be clear about something that can easily become confused in everyday Scrum practice. A Sprint Goal is not simply a list of Product Backlog items that the team has agreed to complete. It’s a statement of the valuable outcome the Scrum Team intends to achieve during the Sprint, providing a common purpose that helps the Developers make sensible decisions as the work progresses.
Imagine that a team is developing an online booking system for a hotel group. During Sprint Planning, the Developers might select several Product Backlog items relating to searching for rooms, displaying availability and improving the booking process. If their Sprint Goal is simply to complete those individual items, they may find themselves concentrating on finishing tasks without considering whether the work actually delivers something useful when brought together.
A much better Sprint Goal might be to enable customers to search for available rooms and view suitable accommodation for their chosen dates. Now the team has a meaningful outcome to work towards, and that outcome helps guide decisions when difficulties arise. If one proposed enhancement turns out to be more complicated than expected, the Developers can discuss with the Product Owner whether the scope of the work can be adjusted while still protecting the Sprint Goal.
This distinction matters because Scrum is designed to encourage collaboration around valuable results, rather than simply reward people for completing individual tasks. A Sprint Goal gives the team something to work towards collectively, and it provides a useful basis for inspecting progress throughout the Sprint.
Why Sprint Planning Sometimes Creates More Problems Than It Solves
One of the most common difficulties begins during Sprint Planning itself, particularly when the discussion becomes dominated by how much work the team can fit into the available time.
It’s understandable, of course, because people want to make good progress and nobody likes the idea of leaving capacity unused. However, when the main objective becomes filling every available hour with tasks, there’s a danger that the team will make commitments based on an unrealistically optimistic view of what can be achieved.
Suppose a team has six Developers and a two-week Sprint. Somebody calculates the available working days, makes an allowance for meetings and holidays, and concludes that the team should be able to complete a particular quantity of work.
That may provide a useful starting point for discussion, but it doesn’t tell us whether the work is sufficiently understood, whether important dependencies have been resolved or whether the Developers have the particular skills needed to complete the selected items.
I’ve always believed that planning should help us make better decisions rather than create an illusion of certainty. In Scrum, the Developers select the work they believe they can undertake, taking account of their previous performance, current capacity and the complexity of the Product Backlog items. The Product Owner helps clarify priorities and the value being sought, while the Scrum Master helps everyone understand and use Scrum effectively.
If Sprint Planning is regularly producing a workload that looks impressive on paper but proves impossible in practice, I’d want the team to examine how those decisions are being made. Are people genuinely discussing uncertainty and capacity, or are they feeling pressured to accept a target that has already been decided for them? The answer can reveal a great deal about why Sprint Goals are being missed.
The Hidden Danger of Starting Work That Isn’t Properly Understood
Another difficulty arises when Product Backlog items enter a Sprint before the team has developed a sufficiently shared understanding of what’s required. This doesn’t mean that every detail must be specified in advance, because Scrum is intended to accommodate learning and discovery.
However, there’s a considerable difference between accepting some reasonable uncertainty and beginning work without understanding the problem well enough to make a sensible forecast.
Let’s return to our hotel booking system. The Product Owner wants customers to be able to cancel bookings online, which sounds straightforward enough until the Developers begin investigating the existing reservation system.
They discover that different hotels have different cancellation policies, some bookings involve third-party payment providers, and the rules for refunds aren’t nearly as clear as everyone originally assumed.
The problem isn’t necessarily that somebody failed to write a sufficiently detailed user story. It may be that the team hasn’t had the opportunity to discuss the requirement with the right people, explore the technical implications or identify the decisions that need to be made before meaningful development can begin.
This is why Product Backlog refinement is so useful, even though Scrum doesn’t prescribe it as a separate formal event. By discussing upcoming work, breaking down items where appropriate and identifying uncertainties before Sprint Planning, the team can make better-informed decisions about what is realistic.
Refinement won’t eliminate every surprise, but it can prevent a great many avoidable ones.
Why Too Much Work in Progress Can Slow Everybody Down
Here’s another situation I’ve seen repeatedly. A team begins a Sprint with several important Product Backlog items, and individual Developers immediately start working on different parts of the system. Everybody appears busy, progress reports suggest that plenty of activity is taking place, and yet very little work actually reaches completion.
The reason is often that too many things are being developed simultaneously. One item is waiting for testing, another requires clarification, a third has encountered a technical problem, and several more are partly complete.
As the Sprint approaches its end, the team suddenly realises that although substantial effort has been invested, it has very little finished work that meets the Definition of Done.
This is where I think the idea of concentrating on finishing work before starting more work becomes particularly valuable.
Instead of allowing everyone to pursue separate items independently, the Developers can collaborate to move the most important work through development, testing and integration until it is genuinely complete. Sometimes that means somebody helping with testing rather than starting another feature, or two people working together to resolve a difficult technical issue.
The important point is that we’re trying to improve the flow of completed, usable work rather than simply maximise the number of activities taking place. A team that completes fewer items but delivers a coherent, valuable Increment may achieve considerably more than one that starts a great deal of work but finishes very little.
When the Daily Scrum Becomes a Status Meeting
The Daily Scrum is another area where relatively small misunderstandings can have a significant effect on the team’s ability to achieve its Sprint Goal.
In some organisations, the event gradually becomes a meeting where individuals take turns reporting what they did yesterday, what they intend to do today and whether they have any problems. Those questions can sometimes be useful, but they’re not the purpose of the Daily Scrum.
The Daily Scrum exists so that the Developers can inspect progress towards the Sprint Goal and adapt their plan for the next day’s work. That means the conversation should be concerned with whether the team is moving towards the intended outcome, what is preventing progress and what adjustments would improve the chances of success.
Imagine that the hotel booking team discovers that an important payment integration is taking longer than expected. In a conventional status meeting, the Developer responsible might simply report that the work is delayed and promise to continue investigating.
In a more effective Daily Scrum, the Developers could discuss whether somebody else can help, whether another piece of work should be postponed or whether they need to speak with the Product Owner about adjusting the scope.
The difference is that the team uses the information to make decisions rather than merely report it. When that happens consistently, problems become visible earlier and the Developers have more opportunities to respond before the Sprint Goal is threatened.
The Scrum Master Cannot Remove Every Obstacle Alone
There’s a tendency in some organisations to assume that whenever a Scrum Team encounters a problem, the Scrum Master should immediately take responsibility for fixing it.
Now, helping to remove impediments is certainly an important part of the Scrum Master’s accountability, but that doesn’t mean the Scrum Master should become the team’s personal problem-solving department.
Suppose the Developers need access to a specialist from another department, but that person’s manager has assigned them to several competing projects. The Scrum Master may be able to help the team raise the issue, explain its impact and encourage the right people to agree on a sensible solution.
However, the underlying difficulty may be an organisational problem involving priorities, resource allocation or management decisions that sit outside the Scrum Team’s immediate control.
This is where the Scrum Master’s wider responsibility becomes important. Scrum Masters help the organisation understand how Scrum works, encourage effective collaboration and help address barriers that prevent the team from delivering value.
Sometimes the most useful contribution isn’t resolving a particular technical problem, but helping the organisation recognise why the same kind of obstacle keeps appearing.
At the same time, Developers should be encouraged to take responsibility for their own work and collaborate directly wherever possible. If every small difficulty has to pass through the Scrum Master before anybody can act, the organisation may unintentionally create another bottleneck while trying to remove the existing ones.
Why Changing Priorities Can Destroy a Sprint’s Focus
Let’s imagine that our hotel booking team has agreed a Sprint Goal centred on helping customers search for available rooms. A few days into the Sprint, somebody from senior management asks the Developers to stop what they’re doing and implement an urgent reporting feature.
Two days later, the marketing department wants a promotional change, and shortly afterwards another stakeholder requests an improvement to the payment process.
Each request may appear perfectly reasonable when considered on its own, particularly if the people making them believe their needs are urgent. However, when the team continually switches between competing priorities, the original Sprint Goal becomes increasingly difficult to achieve.
Developers lose time changing context, partially completed work accumulates and the team may begin to feel that Sprint Planning is little more than a formality.
This is one of the reasons the Product Owner’s accountability for maximising product value and managing the Product Backlog is so important. Stakeholders should be encouraged to discuss their needs with the Product Owner rather than independently redirect the Developers whenever something new occurs.
Of course, circumstances can change during a Sprint, and Scrum doesn’t require the team to ignore important new information. The Developers and Product Owner can clarify and renegotiate scope as more is learned, provided that changes don’t endanger the Sprint Goal.
If the Sprint Goal itself becomes obsolete, the Product Owner has the authority to cancel the Sprint, although that should be an exceptional decision rather than a routine response to changing priorities.
What matters is that the team has a clear objective and a sensible way of handling requests that might interfere with achieving it.
How to Recover When a Sprint Is Already Going Wrong
Now, suppose you’re halfway through a Sprint and it’s becoming obvious that the team is unlikely to achieve its Sprint Goal.
The temptation may be to ask everybody to work longer hours, postpone testing or simply hope that the remaining problems will somehow resolve themselves before the Sprint ends. I’ve never been particularly enthusiastic about any of those options, because they tend to conceal the real difficulties and create additional problems later.
I’d begin by asking the Developers to examine what has actually been completed, what remains unfinished and which obstacles are preventing progress. The discussion should concentrate on the Sprint Goal rather than treating every selected Product Backlog item as equally important. If some work can be simplified or deferred without undermining the intended outcome, the Developers can discuss those possibilities with the Product Owner.
For example, our hotel booking team may have planned to provide several search filters, including price, location, room facilities and customer ratings. If the team discovers that the customer ratings integration is proving unexpectedly difficult, it may still be possible to deliver a useful search capability without that particular filter.
Whether this is acceptable depends on the Sprint Goal and the value the Product Owner is trying to achieve, but the important thing is that the team considers the options while there’s still time to act.
I’d also want to understand whether any remaining work is being held up by dependencies that could be resolved through collaboration. Sometimes two Developers working together on an urgent problem can achieve more than several people continuing independently with lower-priority activities.
The objective isn’t to make the progress report look better; it’s to give the team the best realistic opportunity to deliver the valuable outcome it agreed to pursue.
How Sprint Retrospectives Can Prevent the Same Problems Returning
One of the things I particularly like about Scrum is that it provides a regular opportunity for the team to examine how it’s working and decide what could be improved.
Unfortunately, Sprint Retrospectives sometimes become rather predictable conversations in which people identify familiar problems, agree that communication needs to improve and then return to their work without changing very much.
I think the real value of a Retrospective comes from understanding why difficulties occurred and agreeing on practical improvements that the team can actually test.
If the same kinds of Product Backlog items repeatedly turn out to be more complicated than expected, for example, the team might decide to involve a technical specialist earlier during refinement.
If testing regularly becomes a bottleneck towards the end of a Sprint, the Developers might experiment with completing and testing smaller pieces of work throughout the Sprint rather than leaving most of the testing until the final few days.
What matters is that improvements are specific enough for the team to recognise whether they’re making a difference. A general intention to communicate better is difficult to evaluate, but an agreement to review unresolved dependencies before Sprint Planning gives the team something concrete to try.
And I wouldn’t introduce a dozen improvements at once, because that can create more disruption than benefit. I’d much rather see a team choose one or two changes that address its most significant difficulties, try them during the next Sprint and then inspect whether the results justify continuing with them.
A Practical Example: Turning a Struggling Scrum Team Around
Let’s bring these ideas together with a realistic example. Imagine that a company has a Scrum Team responsible for improving its online customer service portal. The team works in two-week Sprints, but over the last several months it has repeatedly struggled to achieve its Sprint Goals.
Product Backlog items regularly carry over into subsequent Sprints, stakeholders are becoming frustrated and the Developers feel that they’re constantly working under pressure without seeing enough finished results.
After discussing the situation, the team discovers several connected problems. Sprint Planning has been dominated by estimates of how much work can be completed, rather than by a clear discussion of the outcome the team is trying to achieve.
Some Product Backlog items are insufficiently understood, important decisions are being made late, and Developers are starting new work while earlier items remain unfinished. To make matters worse, stakeholders frequently approach individual Developers with urgent requests that haven’t been discussed with the Product Owner.
Rather than introducing an elaborate recovery programme, the team agrees to make a few focused changes. The Product Owner and Developers spend more time refining upcoming work and identifying unresolved questions. During Sprint Planning, they establish a clearer Sprint Goal and select a realistic amount of work to support it.
Throughout the Sprint, the Developers concentrate on finishing important items before starting additional work, while the Daily Scrum becomes a genuine opportunity to inspect progress and adapt the plan.
The Product Owner also works with stakeholders to establish a more reliable way of considering new requests, so that important information can still be addressed without continually disrupting the team’s focus. At the Sprint Retrospective, everyone examines whether the changes have helped and identifies what should be improved next.
Now, I wouldn’t promise that these adjustments will suddenly make every Sprint successful, because complex work will always involve uncertainty. However, the team should begin to develop a clearer understanding of its capacity, improve the flow of completed work and become better at recognising problems while there’s still time to respond. And that, to my mind, is a much healthier way of improving performance than simply demanding that everybody works harder.
Why Velocity Isn’t the Answer to Every Scrum Problem
Before we finish, there’s one more point I’d like to explore, because I know how tempting it can be for organisations to measure Scrum performance primarily through velocity.
If a team uses story points, velocity can help it understand roughly how much estimated work it has completed in previous Sprints, and that information may be useful when forecasting future capacity.
However, velocity doesn’t tell us whether the team has delivered something customers value, whether the Sprint Goal has been achieved or whether the product is becoming more useful. It’s also a poor basis for comparing different teams, because story points are relative estimates and teams may interpret them differently.
Imagine that one Scrum Team reports a velocity of sixty points while another completes thirty. Without understanding how each team estimates its work and what value it has delivered, those figures tell us very little about which team is performing better.
In fact, if management begins rewarding teams for increasing velocity, there’s a danger that people will simply change how they estimate work rather than improve the outcomes they’re delivering.
I’d much rather see teams use appropriate measures to support their own planning and improvement, while keeping their attention on the value of completed product increments and progress towards meaningful goals. Measures should help people understand performance and make better decisions, not become targets that encourage the wrong behaviour.
What I Would Do Before Your Next Sprint
If your Scrum Team is regularly missing Sprint Goals, I wouldn’t begin by introducing more meetings, more reports or a complicated set of performance measures.
I’d start by bringing the team together for a constructive conversation about what is making delivery difficult, with particular attention to the way Sprint Goals are established, how work is selected and what happens when unexpected problems arise.
I’d ask whether the Developers have enough information to make realistic decisions during Sprint Planning, whether the Product Owner is providing clear priorities and whether the team is genuinely collaborating to complete valuable work.
I’d also examine whether organisational pressures are making it difficult for people to concentrate on the Sprint Goal, because sometimes the most important improvement requires support from outside the Scrum Team itself.
Once we’ve identified the main difficulties, I’d agree on a small number of practical changes and give the team an opportunity to test them. The next Sprint then becomes a chance not only to deliver a useful product Increment, but also to learn whether the team is developing a more effective way of working.
And if I could leave you with one thought, it would be this: when a Scrum Team repeatedly misses its Sprint Goals, the answer is rarely as simple as asking people to work harder or produce more accurate estimates.
More often, we need to understand how the team is planning, collaborating and responding to uncertainty, because improving those things gives us a much better chance of delivering results that matter.
Develop Your Scrum Skills With Projex Academy
If you’ve found this article useful and would like to develop a deeper understanding of how Scrum works in practice, you might like to explore my Scrum Masterclass at Projex Academy. It covers the Scrum framework, including Sprint Planning, the Product Backlog, Scrum accountabilities, Sprint Reviews and Retrospectives, helping you understand how these elements work together to support effective delivery.
You may also be interested in our PRINCE2 Scrum Masterclass, particularly if you’re working in an organisation that needs to combine Scrum delivery practices with broader project governance.
And if you’re preparing for a project management qualification or simply want to strengthen your professional knowledge, you can explore our full collection of Projex Academy courses.
My aim with all these Masterclasses is to help you understand not only the terminology and framework, but also how to apply what you’ve learned when you’re faced with the kinds of situations that occur on real projects.
Because knowing what Scrum says we should do is useful, but understanding why it works, and how to respond when things don’t go according to plan, is where that knowledge becomes genuinely valuable.
Dave Litten
Project Management Trainer, Author and Founder of Projex Academy
