One of the biggest mistakes I see organizations make day after day is when they confuse the importance of goals with the importance of plans. Plans are important, yes, but goals are far more important. When an organization realizes the truth I will explain in this blog post, they take a BIG step toward allowing their product development, service, and support teams to become self-managing. Once you take that step, you’re on your way toward 3x to 5x’ing your teams’ productivity.

Dinner on the Table

Let’s start with a quick story.

It’s 4 in the afternoon on a Tuesday and you need to get dinner on the table. But – oh no! – you haven’t done the grocery shopping yet and don’t have anything in the kitchen you need to put dinner together in time. So, deciding you’ve had enough of restaurants and fast food, you get in the car, drive to the grocery store, buy what you need, and make a quick dinner. As the clock chimes 6, you sit down with your grateful family to a hastily-made, but delicious, dinner. Congratulations! you’ve made it through another day!

But, let’s be real. Things happen.

What if there’s road construction blocking your route to the grocery store? You take another route.

What if the grocery store is closed because of a power outage? You go to a different grocery store.

What if you get a call from a family member asking you to make an extra stop while you’re out? You figure out a way to make that stop before the grocery store. That might involve taking a different route to the first stop and then planning another route to the grocery store.

No big deal, right? You and I do this kind of thing every day.

Sprint Goals and Sprint Plans

Now, let’s think about that story in terms of Scrum. The goal was to get dinner on the table by six. The plan was to take a car, drive to the store, buy groceries, come home, and make dinner. For a Scrum team, the Sprint Goal represents the goal the Scrum team wants to achieve. The plan is how the Scrum Team is going to achieve the goal.

Again, let’s be real. As in our dinner story, things happen that can cause the plan to change.

What if the team is missing crucial information they need to complete work on a product backlog item and the one person that has the answer is on safari in Africa? Does the team sit there and wait until the safari is over? No. They find another solution or make a decision for now that can be changed later when that key person returns.

What if the team runs into unanticipated problems getting a backlog item solution to work properly? Does the team just keep pounding away on the planned solution? No. They find another answer. They try something else.

In my CSM and CSPO classes, I frequently use the example of a team trying to implement an automated background check when a person registers as a driver in an Uber-like product. During the Sprint, the team discovers that they won’t be able to complete the automation as planned.

So, they decide on a different solution: they will make it so the background check can be done manually (for now). This approach allows the Sprint goal to be achieved (new drivers can register) even though someone will need to – temporarily – handle the background checks manually. A new product backlog item is added to automate the background check later, when the underlying problems with the automation can be examined and corrected.

Developers on the Scrum team can make any changes they need to make to the Sprint plan (their approach to accomplishing the Sprint Goal) as long as they don’t threaten the achievement of the Sprint Goal. Once the organization understands this basic premise, some surprising realities are revealed. Here’s two of the biggest truths:

Truth #1: Measuring Velocity is a Waste of Time

Velocity is a measure of the completion of the Sprint plan. But the Sprint plan is merely a forecast. Think about it. If you’re in your car driving to the grocery store and there’s construction blocking your way, do you sit there looking for ways to crash through the detour and drive through the construction zone? Do you consider yourself successful, not because you put dinner on the table, but because you got to the grocery store using the exact route you planned? Of course not.

Measuring Scrum teams based on their velocity is like measuring your ability to drive through a construction zone. You become focused on getting the plan done, for better or worse. A Scrum team’s focus should be on accomplishing the goal, not completing the plan.

Truth #2: Getting Everything Done is Not an Accomplishment

Likewise, some organizations measure their team based on how much work the team completed compared to how much was planned. Think about this: you know the least about a plan at the moment you create it. This means that all plans are wrong. So, why focus on getting something done that is wrong from the very beginning?

Stop measuring your Scrum team on their ability to finish tasks (a very “waterfall” approach) and start measuring your teams on their ability to set and achieve challenging Sprint Goals. Look at plans (the backlog items and tasks in the Sprint Backlog) as a forecast – “this is what we THINK we need to do this sprint – but it will likely change.”

What are your thoughts?

Have you experienced this problem with plans changing and Sprint goals being ignored? Leave a comment below or tweet me @ArtisanAgility.