Does that sound like your Scrum team? Is the sprint goal that big of deal? In short yes, the sprint goal is a VERY BIG deal. Here's why.

A team that regularly misses its sprint goal is thought of as a team that:

• can't plan its work
• does not really know its own capacity
• does not estimate stories and/or tasks very well
• does not have sufficient competence to do the work they have been asked to do
• is not trustworthy -- they don't do what they said they will do

Of these the last is the most damning. They can't be trusted to do what they said they would do. In many organizations, that is the prevailing perception of IT in general -- they never do what they said they will do -- and that perception is one the primary things we are trying to change by transitioning to agile techniques. But achieving the sprint goal is, as all things agile, a matter of balance. Do I want the team to meet its goal for every sprint? No, that team is not aggressive enough. Do I want the team to regularly miss the sprint goal? No, that team is not disciplined enough. So how do we achieve the right balance...

Get Commitment

Many recommend the direct question "Can you commit to delivering this story?" before the story is added to the sprint backlog. New Scrum teams in particular are not accustomed to this level of commitment so as the Scrum Master I want to continually remind the team that it will be expected to achieve whatever goal it sets. Along those same lines, we want to be sure that the goal is set by the team, no one else. Recently, I came across a team whose goals were being (unduly) influenced by management resulting in much more work being planned than the team could possibly do in a sprint. That is just setting the team up to fail and that is exactly the result that was being achieved. Agility is about changing beliefs and behaviors. The belief here is that the team is free to set its own goals; the behavior it that once the team sets a goal, it is accountable for meeting it.

Plan for Success

Missing the sprint goal is often setup in the sprint planning meeting. Does the team have a plan for completing the stories it takes on for the sprint? Does it know what is needed to complete the story? Does it have everything (tools, hardware, software components, etc.) it needs? Does it know what constitutes "done" for each story? Many of those questions are also common reasons why teams don't achieve their sprint goals. Also look at the size of the stories being taken into a sprint. Are they too big for a sprint? Are they all the same size? Ideally the team should have one story that will take "most" of the sprint to complete, and then a series of smaller stories that can be completed throughout the sprint, completing a story at least every day or two.
Make Sprint Goals Visible

Sprint goals need to be very visible and I would look to the Scrum Master for this. Every team member should be able to fall out of bed in the middle of the night and recite the sprint goal -- these 5 stories for 21 points. It needs to be that engrained, and that is the Scrum Master's job. Sprint goals should also be public. Post them in the team room or area. Post them on the project website. Post them in public areas; a wall outside the team area(s), in the break room, or near the copy machines. It can create some conversation about what the team is doing, and it puts everyone on notice of what the team is striving for (including the team itself).

Track Progress Toward the Goal

Most teams use a classic sprint burndown chart of some kind, which is good, but it is not enough. The classic burndown tends to keep the focus on tasks and hours and rather than stories, so also track a story point burnup chart. How many story points have been completed by each day in the sprint? This will put the focus on completing stories, where it needs to be. It will also point out some planning ills such as the team taking on stories that are too big. I almost always also track the sprint history as well. Sprint by sprint how many points were targeted (the sprint goal) versus how many points were actually delivered. It will show the trend for the team; is it too aggressive or too conservative? I would expect to see some misses, but the team should be meeting its goal most of the time.

Keep the Big Picture in Mind

Scrum teams can come to view the world only in the context of the current sprint and rarely look beyond. That manifests itself in several ways but can also be a part of missing sprint goals. As a Scrum Master I do want the team focused on the current sprint goal, but I also want them aware of how the current sprint fits into the bigger picture. The sprint goal is not the end, it is a step toward the end. Missing a sprint goal means we have impacted that end and most likely need to add a sprint to the release, or remove work from the release. The team needs to feel that consequence and be accountable for explaining it. That conversation should be part of the sprint review and/or planning meetings. The visual side of this is the release burndown (or burnup) chart that projects a release schedule based on the team's story point velocity.

In the end, meeting sprint goals is more about mindset than process and that shouldn't be surprising. A Scrum team is more self-organizing than a traditional team -- and will continually become more self-organizing over time. That adds unfamiliar accountabilities to the team. Early on Scrum Masters should protect their teams and not allow these new accountabilities to cripple the team during its initial learning stages. As teams mature however, we need to encourage them to be more open and transparent about their commitments (which go beyond just the sprint goal), and make team accountabilities public. Then missing a commitment can become what it should be; a learning opportunity that can benefit the team and all of its stakeholders -- not just business as usual.