# Why do all the teams that I have worked with always finish a sprint without completion of all the stories?

I am developer, I have worked with three Agile teams for the last eight years, with different organisations. The organisations have had a mix of Scrum, Kanban & Lean Startup Mindsets.

I have observed for almost all of sprints that I have worked with them, the teams usually didn't finish all the stories in the sprint. One place it was 4 week sprint.

All other places it was a 2 week sprints.

In one of the team, we practiced story splitting, Specification by Example & having a lot of constructive discussions during Sprint Refinement. We even added an extra Sprint Refinement day. We are familiar with estimation points.

Is it normal for teams to overshoot their goals ?

• – Todd A. Jacobs Jun 18 at 12:41
• – Todd A. Jacobs Jun 18 at 12:42
• CodeGnome's Scrum Tautology: "Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal." – Todd A. Jacobs Jun 18 at 12:44
• Have you considered the question of why is finishing all the stories in a sprint important? Have you seen issues with these teams that seem related to this? – JimmyJames Jun 20 at 21:13
• Easy - they're doing it wrong ;) – Wayne Werner Jun 25 at 16:13

I cannot speak to your particular situation but yes, it is pretty common that not everything is done.

This is in fact a logical consequence of the structure of the team, and you being a developer are in a prime position to appreciate it.

# Load and delay

If I were to ask you “do you run a server at 100% load?” you would likely laugh in my face. So I might follow up with “OK if that is ridiculous, what sort of load is acceptable?” and you might offer a number of responses including simply “how do you define load?”

But I think we could settle on the idea that more or less no matter what the definitions are, you would not like server loads above, say, 10-25% of capacity: certainly not much above 50%. And were I to ask you “why not?” you would very likely first give the Wrong Answer: that you’re worried about hardware failure. That’s a fair point but usually if you’re doing it right you’re already guarding against that risk. And then second you would give the Right Answer: that you’re worried about latency spikes. If the server doesn’t have spare capacity, it can’t begin a new request until it is done finishing up old ones. And that’s true of people, too.

The core problem is that a sprint model typically assumes one way or another that there is 100% developer load, and developers respond by padding out their estimates with safety buffer so that they can hopefully only operate under 50% load or so. Then you have natural problems dealing with the same two problems: hardware failure (employee burnout) and latency spikes (hey, Legal said one week ago that Floozels must only be awarded for the Flotsam that is also Jetsam—why isn’t this fixed now?!). In practice nobody wants to accept the latency spikes and so they simply throw story points of developer time out of the current sprint in order to keep latency low with their bosses and the business at large. Similarly any “some other issues came up” workloads appearing in stand-up have the same origin. So your developers are taking care of their own health and that means some amount of doing non-work, and this sometimes bleeds into losing story points; and your developers are doing one-off requests or unexpected workloads, and that sometimes bleeds into losing story points. Those are the two main sources.

In fact the problem is somewhat larger than this because safety factor in estimates is much much bigger than even the typical advice to “always multiply estimates by N” suggests. The reason is that the private estimate for completion completes the goal with, say, a 90-95% probability, which for realistic situations might already add a factor of 2 of safety versus the 50/50 chance of completion that we should idealistically be able to target; furthermore a PM then buffers those estimates with some additional padding anywhere from 20-100% when communicating with the business as a whole. Take any software project, and something like three-quarters or more is safety buffer. We devs would be completely scandalized at the idea that any project would ever run over-time or over-budget if we understood how much safety buffer we have to spare to complete it. The typical excuses we give, “oh we will be late because in our last week a hurricane took out our data center causing all of our systems to be down for several days, but the team worked together and pushed really hard and we got everything working and we’re only going to be late by three days” are laughable simply because given the safety buffer we should have delivered way before that hurricane hit.

# Waste and purpose

So there is a paradox of we have huge safety buffers and we still deliver late. The solution to the paradox must be waste; we must be wasting all of that precious safety buffer. This happens in many different forms and enumerating all of them would make this answer very long. However I think we need to point the finger first squarely at management simply because the developers lied in the first place; they padded their estimates first from 50% to 95% and then they added another factor-of-two on top of that, and this means that management has not created a space where they feel safe in being totally honest with their estimates. Why do I feel free to take care of myself by answering a question on Project Management SE? Because I am at the start of a sprint and everything has luxurious unspent safety buffer still and so nothing seems desperately urgent. Come back to me on the last three days of the sprint and see if I am still on PMSE, heh.

I can also give a quick sort of aspirational vision for how to solve it. In theory there is a dependency graph of tasks-to-be-done for your Sprint Goal or any other release you have, and it typically involves some real stinkers that nobody wants to take on, like “figure out why the QA server is crashing even though we have implemented workarounds to make it not crash so that QA is unblocked, we have no idea what’s causing it, good luck, don’t break anything.”

If you think about commits on this sprint to your develop or master branch, you see that even though the dependencies are in many cases not enough to structure the thing completely, the tasks will ultimately form a directed acyclic graph and there is some critical path from sprint-start to sprint completion: the path through this graph of work-as-done which takes the longest amount of time. Then there are several side-paths—other devs working on important things which are not on this critical path—which have to merge into that critical path. I don't care about them unless they delay the critical path, really: people can be free to goof off within some reason on their side-paths.

In the ideal project there is therefore at any given time exactly one developer who is in a state of panic. They are working on the critical path, and they know that this responsibility is upon them. The critical path is something of a baton or hot potato that they are looking to pass off to the next person as soon as they can; and they are given considerable power to loop in other developers to help them with their task, or to compromise scope of their feature to be good enough to pass the baton on. PMs and other facilitators have several roles:

1. They encourage people. Deadlines in this model are routinely missed because they only have a 50/50 chance of being completed, so facilitators need to remind people that this is okay and we have a project safety buffer precisely for this; this thing is still urgent because we’re now digging into the project safety buffer but we have it so that we can use it when this happens.
2. They prevent burnout by ensuring that the baton keeps being passed from person to person (as others are given a great deal more latitude to rest).
3. They coordinate dynamical changes to the critical path. Suppose the schedule looks like this:

Time:          0     1     2     3     4     5     6     7     8
Side-Path:      [Alice-----][Bob-------][ safety buffer ]
\
Critical Path:  [Carol-----------------------------------][Dan----...]


in this diagram, Alice and Bob are on a side-path; they both have a 50/50 shot of completing in 2 units of time, Bob’s work can’t start until Alice’s is merged. They share a safety buffer of 3 units of time for their thing before it merges into the critical path; it is needed when Carol hands off her changes to Dan; she has a 50/50 shot of completing in 7 units of time. Now when this schedule meets reality, you have to accept lots of “it’ll be done when it’s done” and trust these four to be doing their best; Carol is aware that the entire project right now is riding on her work and is in the state of panic. But what can happen is that Alice was pulled into something else and it is t=3 and she has at least one time unit before she can finish and hand it on to Bob at t=4; but Carol is estimating that her task was much easier than expected and is going to be handed on to Dan at t=5 or t=6. So in theory facilitators should be noticing when the safety buffers on these side projects are running out or when the tasks on the critical path are getting done early (either alone is enough to potentially lead to a shifting of the critical path) and letting folks like Carol know that they’re no longer custodians of the hot-potato: that it has shifted and they can relax a little because now the person who is most affecting our precious safety buffer and hence our ability to meet the deadline is Bob, who now needs to feel that responsibility.

If facilitators can do all of that with compassion then they can build a trust and hypothetically deliver projects significantly faster, because the key feature here is that we are treating the safety buffer as a precious resource. Teammates are under pressure proportionate to their ability to affect that buffer: the ones who most affect it are therefore not wasting it with “oh let me go check Reddit...”. The others are allowed to rest so that you get the benefits of a well-rested team. And finally, we do not waste anything we get when someone delivers early because we communicate.

Note that this is a very pretty vision but I have to attach some caveats. This is not a universal structure of all business. It is a derivation of some general principles for a specific context where every object being produced is a fundamentally new artistic endeavor and only is produced by some big complicated cooperative effort. Your software teams may be working in a different business sector which does not work this way: for example Valve no longer makes big software games to be bought for a big price tag but instead makes skins and user customizations sold on Steam to get a lot of micro-sales; one can imagine that the Valve Before would have strongly benefited from this sort of structure whereas the Valve After probably would not see those sorts of returns. But those sorts of patterns are pretty common in software development so it is reasonable to think that many software shops would benefit from something looking similar to this.

• I joined PM just to upvote this answer, because it perfectly captures the problem with the server analogy, and even has some good recommended solutions (e.g. splitting into critical/non-critical paths). Awesome! – Jared Smith Jun 19 at 13:18

In addition to the questions that Daniel poses, I'd pose a different one first:

Is the team achieving its Sprint Goals?

The Sprint Goal for a team following Scrum is the objective that should be met at some point during the Sprint by implementing Product Backlog Items selected for the Sprint. It can help focus the team's efforts toward specific work and objectives should issues arise or decisions need to be made about what work to do.

If the team is regularly achieving the Sprint Goal, then it may not be an issue that the team is not completing all of the work in the Sprint Backlog. However, it is still something to talk about with the team as there may be concerns around capacity and Sprint Planning.

If the team is not regularly achieving the Sprint Goal, then that should be addressed and the team needs to work with the Product Owner to craft an achievable Sprint Goal and plan the work to achieve it within the Sprint.

• Absolutely. I probably should have led with this – Daniel Jun 19 at 13:15

It is common, but it isn't right. Here are a few things to consider that may be contributing to this challenge:

1. Is the team focused on delivering a potentially shippable product increment each sprint or just doing work in a larger project? I hear a lot "it doesn't matter, it all has to be done on the deadline". If I hear that, they're probably right. They probably aren't actually practising Scrum and they're just all working toward a large release with 2-week pace-markers.

2. Are people breaking down their work small enough? Large work items make it hard to wrap things up at the end of the sprint.

3. Does the development process have large wait states built in? This is really the same problem as 2, but the solution is different - instead of just breaking things down, you need to drive out those wait states.

4. Is work in the team siloed? It's not that people can't have areas of expertise, but when you silo off work, often people are taking on new work to keep busy instead of helping each other wrap up work in progress.

• Additional: is the team being distracted by tasks which are unrelated to the sprint goal – Jo Silverton Jun 19 at 7:30

If you are using story points and tracking your velocity then this should rarely happen.

When the team fails to complete stories in a sprint then the velocity will tend to compensate for this by dropping. As the velocity gets lower the team should be bringing less in to sprints.

e.g.

A team brings 30 story points in to a sprint but only completes 25 story points

The rolling average of velocity for the team is reduced from 30 to 27

The team brings 27 story points in to the next sprint and manages to complete 24 story points

The velocity again falls, down to 25

In this way the team should be guided by the velocity until they are bringing a realistic amount of work in to each sprint.

As a good guide, Mike Cohn recommends that a team completes all their planned work in a sprint 80% of the time.

If this is not happening then things to look out for include:

• The team is taking credit for stories that are incomplete at the end of the spint
• The team is ignoring their velocity and is focusing on what people expect them to get done
• The team treats finishing the planned work before the end of the sprint as a bad thing
• The challenge then is getting everyone to believe velocity is not a performance metric. – Patrick McElhaney Jun 19 at 11:02
• @PatrickMcElhaney 100 upvotes for that comment. – Carl Witthoft Jun 19 at 15:03
• Mike Cohn's book is Agile Estimating and Planning. Well worth reading for any Agile team! – CJ Dennis Jun 20 at 6:28

This is Push Response.

There is a disconnect between the reality and the promised. The Business sector is coming in with their expectations to push a project forward but not allowing Project/Product Management to actually finish a sprint and the leadership of the Technical Team doesn't feel comfortable reigning in their expectations.

I have found that going for a 3-week Sprint instead of a 2-week Sprint, but aiming for the 2 weeks, is more beneficial. If we are ahead a few days we gain a pad going forward and know that having a completed sprint saves us time going forward. If we push the wall to 3 weeks but get a fully completed sprint and ability to circumvent issues by being proactive in completing the sprint we have less issues on roll-out.

As Director of Automation, I use a gentle Push Back - explain the technically-reachable goals, going 3 and 6 months out, with the current resources and constraints. If there is a significant increase with regard to time then we adjust the time-frames and alert the Business Team. If there is a minor increase in time then we go to Change Management and implement.

it is a pobulare problem, had you changing your team members? is this situation occurs for all project? who participate the estimation process? you can learn from your data, do a statistical study through your different projects, compare the same user stories in different projects(is it the same team), i think it isn't pure agile development, starting from me we have to think Agile, not practice Agile, we have like this situation in our team but, and because we are new in Agile, we do so like learning of our projects to determine what is the wrong action. I can say we also tend to be Agile but really some thing make us Mini-Waterfall, it isn't an essay practice to estimate the story effort without uncertainty, but more by more projects, i believe we can reach to the perfect state when your estimate fit with your team effort.

The Sprint is just a timebox for turning some Product Backlog Items into a Done increment. It's as simple as selecting some stuff to get Done (at the start of the Sprint) and check the stuff that actually got Done (at the end of the Sprint).

The percent that actually gets Done varies from Sprint to Sprint. People get tired, sick, holidays. A team member leaves, another one joins the team. The Product Owner changes. All these events affect the Velocity (which is the speed of turning PBIs into a Done increment).

Then again, the Scrum Team formulates a Sprint Goal at the beginning of the Sprint.

Remember: the Sprint Goal only refers to the most important items in the Sprint Backlog.

If the time is not enough to deliver all items (it almost never is), some items are more important than others. The Product Owner clarifies which ones have higher priority and which ones can be left out.

I think a Scrum team deliveres on average 60% to 80% of what was planned. If we were to use the MoSCoW method:

• 60% of the items selected into the Sprint Backlog are MUSTs
• 20% are Shoulds
• 20% are Coulds
• The rest are Won'ts

The Product Owner is able to clarify at any time if an item is a Must, a Should, a Could or a Won't (do this time).

If the team constantly delivers its sprint goals, then the team is performing well because it is constantly delivering the Musts.

During Sprint Planning, the Scrum Team needs to be aware of the fact that something might be left out. The Product Owner might on purpose suggest a few important items and a few lower priority items. It's up to him (her). But even between those most important items, some of them are more important than others.

So, during Sprint Planning the team should discuss practical availabilities and raise any issues which might affect the velocity (sickess, holidays, deaths, births), in order to get closer to delivering everything that was planned.

Scrum is about people. If the people can't perform for some reason, it is how it is. The best you can do is get the real picture and do some real estimates and planning. You'll get less things Done (due to things out of your control), but you might also get almost everything Done (out of what you have planned).