How to handle 50% of worse than average sprints?

Question

If I understand Scrum correctly, this is how I determine the work my team can take on in the next sprint:

1. I average the number of completed points for the past several sprints.

2. This quantity is our average velocity. Next sprint, we take on that many story points.

This is an average, so if history repeats itself, this sprint it is 50% likely that we are taking on too few story points, and 50% likely that we are taking on too many story points.

In the 50% case we have taken on too many story points we could:

• Fail to complete the sprint. This means we will fail to meet our sprint commitment half the time.

• Work extra to catch up. The problem is that this ratchets only one way. We will accomplish the sprint, and the number of story points completed will reflect that. Since we always finish, over time, our average will trend upward to the point where we are always accomplishing a large number of story points and staying late.

---

Is my understanding of average velocity and sprint commitments correct?

If so, what should we do for the 50% of sprints where we are behind average?

If not, what have I gotten wrong?

Answer 1

Is my understanding of average velocity and sprint commitments correct?

Yeah, you have the gist of it.

If not, what have I gotten wrong?

The thing you overlooked is that story points are the things you get done. It is nigh impossible for everyone to work on stories right up to the end of the sprint. If you're doing things right, most of your developers will be "idle" for a few days while the stories are being tested (and your testers in the middle of the sprint as development is in full swing).

I put idle in quotes because your developers aren't sitting around watching cat videos, they're fixing bugs, polishing up some code/unit tests, adding some documentation around processes, thinking about the design for stories in the backlog or one of the other dozens of useful things that a development team can benefit from but don't fit well into a story.

So while you will over-guess 50% of the time and under-guess 50% of the time, that doesn't mean you're going to fail the sprint or have to work overtime. It means that you won't have quite as much time to do this miscellaneous work (unless you really miss your estimates). But that's not a big deal, since the miscellaneous work isn't time sensitive, and things will even out in the long run.

Answer 2

Is my understanding of average velocity and sprint commitments correct?

Unfortunately, you've been misinformed about a few things regarding Sprint Planning in Scrum. First, the Development Team (DT) is

...structured and empowered by the organization to organize and manage their own work. - Scrum Guide

The word for this is self-organizing. This includes the work of forecasting the work that will be done in a given Sprint. The DT is not told what it will work on each sprint, it is rather empowered to choose its own work. The DT might need information like historical velocity, a well-refined Product Backlog, and the next Sprint's DT capacity to create a forecast. Ultimately, it's the DT's determination of what can and cannot be accomplished in a Sprint that should prevail in their forecast; they should not be told how much work they will do.

Notice also, forecast and not commitment. The c-word was removed from the Scrum Guide because it was being used to abuse the Development Team. Forecast is the preferred term.

Regarding the probability of missing the Sprint forecast on the low or high end, I don't see that as being of importance. At some point, more analysis does not yield better accuracy and I think we're beyond that point now.

Also, a Sprint can only be "Canceled;" it can never fail. A Sprint is canceled only when the goal of the sprint becomes completely obsolete and irrelevant. This is very rarely the case. If a forecast is incorrect, you just keep calm and Scrum on. Have you retrospective. Next Sprint, your forecasts will be better :).

Answer 3

First, your velocity is from your previous sprint, or sometimes from an average of a few recent Sprints (Yesterday's Weather), and not an average of all past sprints. Of course, if you have no historical data from your team or company, you need to come up with a reasonable value for your first sprint. On your second sprint, you take in the completed story points into the sprint. If you were to graph it, you may see variations over the first few sprints (for example, 17 in the first sprint, 22 in the second, 26 in the third, 24 in the fourth). That is to be expected as you normalize your teamwork and estimation process, along with gain a better understand of the project (technology, domain).

That isn't to say that you don't adjust. For example, if you have a week that is a holiday week, be sure to account for the holiday where work is closed. If you know that team members are taking a vacation, plan for fewer people working. Of course, unplanned events do happen as well, but you can explain those in a sprint retrospective and you can decide how that influences the number of story points that you bring into the next sprint.

As far as what to do, "fail to complete the sprint" is different than "we didn't complete all of the stories". To me, a failure of a sprint means that you didn't produce a potentially shippable product at the end - none of your stories are complete, you don't have a build, you can't demonstrate any added value to the customer or users.

Whatever you do, you shouldn't work late or excessive over time. This is called the sustainable pace (Agile Alliance, Scrum Alliance).

The indicators that there may be issues is if:

• Your team is not working a sustainable pace. You need to work overtime to complete the story points planned for a sprint. Make your sprints smaller to complete on-time without the added pressure.
• Your velocity doesn't normalize over time. No one is expecting velocity to never change, but if you notice spikes or swings, deal with those in your sprint retrospectives. Figure out what's causing them and address the root causes.

Answer 4

Agile methodology varies from company to company, in one implementation it could be vastly different from another. I've worked under Agile with two companies. In the first company I was in they took their metrics pretty seriously, in the second company not really at all. So for all you know nobody is paying attention to your metrics.

All that said, it sounds like you're concerned with not meeting your sprint goals, or what happens when you have an inaccurate estimate. I think this type of concern and outlook is common, but it's not particularly important. Agile, above all, is a software development system which does a few things:

1. Keeps developers moving
2. Increases transparency
3. Allows for reflection and gradual process improvement

At the end of the day, if you mis-estimate a sprint, or fail a sprint, it's not really that big of a deal. The people who are above your team in your company are likely more concerned that your team is consistently moving, and projects are being brought to their logical completion.

As an individual under Agile you should be most concerned with how much work you're effectively completing in reference to the rest of your team. If you're new, you can't be expected to be too productive, but at some point in your term of employment you should be around on par with at least some of your team. If you're not outputting work, you're not really doing your job.

Answer 5

Is my understanding of average velocity and sprint commitments correct?

Your average velocity is spot on. In my experience this is very useful for long term estimates of completion - assuming you have a large backlog; but not as useful for sprint planning commitments.

The process I have seen followed for sprint planning is to pull stories from the top of the backlog and let the team decide if they can achieve them. Teams have decided this based on gut feel, breaking down to 1/2 day tasks, pressure from Product Owner, alignment with a sprint goal, best guess (based on velocity) or some combination of them all.

Occasionally the Product Owner has allowed for skipping a couple of items so that more can be added.

Sometimes the team and product owner pre-agree stretch items to move onto.

Answer 6

This is an excellent question and is very important for teams to improve. The topic is deceptive and is widely misunderstood. The original purpose of story pointing was to find a quick and acceptably accurate method of estimating the Level of Effort (LOE) needed to complete functionality that was defined in stories. The overall objective: give teams a method of FORECASTING or predicting how long it would take to complete an effort (such as a project). Your understanding of Velocity is right: it is the AVERAGE points per Sprint completed (truly DONE). So if you have a project to deliver, and it is 250 points, and your team averages 25 points per sprint, the project will take roughly 10 sprints, plus or minus some buffer time.

Some luminaries, such as Ken Schwaber, suggest that velocity and points only be used for mid- to long-term forecasting. They suggest using task hours as a second "sanity check" on what can actually be done in a sprint. So the amount of points in each sprint may vary depending on capacity. Others (including myself), believe that a mature team will settle into a very consistent sizing pattern that can accurately predict capacity, and eventually task hours become a useless additional burden. (It is critical to perform for new teams for at least 6 to 12 sprints, IMHO, until the team's understanding of points and story sizing is accurate.)

Your first little error is that you said the team should know velocity and bring in that many story points. Actually, coaches encourage teams to deduct 10% to 20% and commit* to that level instead. So if your team tends to complete 25 points per sprint, don't fill up the sprint to 25 points, but rather, stop at 20 to 22 points. Remember: it is perfectly FINE to bring in stories when the other work is done. So you might "commit" to 22 points and complete 28. That is great. Just be careful to not encourage the team to "sandbag" and constantly under commit. There's nothing wrong with stretching to see if we can do more.

Now, to your point about the variance between sprints. It is a very common (but NOT OPTIMAL) pattern to see a team that completes 20 points one sprint, then 50, then 22, then 45, then 15, then 60. If you calculate the deviation, it may show swings of 50% to 100% sprint after sprint. Why do teams complete just 15 points in one sprint, and then 60 in the next?

It might mean that the team really doesn't know what they can get done. (Hey, we completed 50 points last sprint, we can do it again this sprint).

OR, it might indicate that product owners are forcing the team to over commit, or are adding work after the sprint start, etc. These are just some of the ANTI-PATTERNS that could be causing this wild swing in completed points.

This Predictability measure is an important one for scrum masters to observe and bring to the team's attention. Often, the reason they completed few points in one sprint, and then many points in the next sprint is what I call the "ROLLING WAVE OF INCOMPLETE WORK". Here is a very common pattern:

The product owner is under pressure to meet a date. So the team feels the need to try to get a lot of work done. They start out as a new team, and aren't sure what they can actually get done.

So sprint 1, they plan the sprint and as they are in Forming phase, can't complete all the work. In fact, they have more incomplete work than done work. The incomplete work is STARTED but INCOMPLETE. It is moved to the next sprint, and this time they have more done work than incomplete. By the next sprint, that large load of incomplete work drops into DONE and the team's confidence soars.

The product owner is excited and so they increase their load again. At the end of this sprint, they have a HUGE amount of incomplete work, and a disappointing amount of DONE work.

Here you begin to see the WAVES of Done vs Incomplete alternating sprint after sprint. If teams don't realize what is happening, this pattern can continue for months. But on average, they complete around 24 points per sprint. So what happens when they quit over-committing?

You'll note that they STILL complete 24 to 26 points, but the carry-over work is reduced. Now, instead of being overwhelmed trying to complete an impossible amount of work, which also destroys team morale, the team can begin to improve their processes.

Over time, velocity will begin to increase, without the huge swings in Done-vs-Incomplete work.

If you don't allow the team some "slack time", they will NEVER have time to perform work that will make them leaner, faster, better. Dev-Ops, for example, can't happen. Test Automation--Who has the time for that!? But these are precisely the things that teams need to work on so they can increase velocity.