Happy Friday!

Back in 2011 the world's most popular agile framework, Scrum, changed. You see prior to that, every time the team planned a sprint they were told they had to commit to completing everything they planned. After 2011, the team was asked to craft goals for their sprint that they would be judged on.

Sprint commitments were abandoned because they were overwhelmingly unsuccessful. Teams never felt they could plan less, and always failed to meet that commitment. Leadership lost trust in these teams who couldn't even do 2 weeks of work, etc. It didn't inspire growth. It led to resentment, distrust, and many bad decisions.

Sprint goals appeared to be an answer to these issues by simply asking teams to come up with a goal for the sprint. A simple statement that expressed why this next sprint was worth it. This way, the team could look at requests, backlogs, and their sprint and apply the simple test of, "Does this help us get closer to our goal," before working on it or not.

At least, that's the theory.

As it turns out, almost every team says their sprint goal is to complete their work. This is about as useful and productive as a cat trying to bury a turd on a marble floor. Or as useful as teams estimating in story points that are just hours. If you say something like one story point is 6 hours, I'm looking at you.

I'm going to pick one reason why teams keep picking a goal of completing work.

They don't know why their sprint matters!

Most teams have been organized as units of labor. They are fed work at regular intervals and expected to provide software as a product. They have no idea why they're working on what they're working on. They work on what's in front of them because someone said it was important.

Imagine that wasn't the case, though. Imagine the team did know what mattered to the company and business. Imagine they all knew the strategy, quarterly goals, and product KPIs. Suddenly, they could create a goal that is tied to something important to everyone. Suddenly, they can provide alternatives and options. Suddenly leadership can look at a goal and know it is fruitful instead of looking at the bag of work and trying to make sense of it.

I'll admit it. I think sprint goals are as awesome as they are weird. I think that, like most things in Scrum, they provide you with an opportunity to eliminate the gap between labor and impact while providing even more decision-making opportunities.

What do you think about sprint goals?

Sincerely,

Ryan