Sprint Goals DONT Work - Or Do They?

0:00So someone recently tried to point out to me that sprinkles don't work. Well, I don't know if that's true. I mean, on the surface, sprinkles sound beautifully simple. It's an easy thing. Set a goal for the team, organize the work around it, track progress daily and finish with success. Sounds easy enough, and that's exactly why it's so difficult. Behind this deceptively simple concept hides one of the most difficult ideas in agile. The Scrum Guide says it this way. It says Scrum is lightweight, simple to understand, difficult to master. Sprinkles are a perfect example of that. Even when you think you're doing them right, you might not be. What if I told you that there could be a better way? When you're launching a new product,

1:02Sprinkles feel natural. The product vision breaks down into features, and each feature becomes a clear target. That makes sense. That resonates in our minds. So for example, deliver accounts summary notifications for these three user scenarios. So far so good. Everything seems great. The team decomposes the goal into a number of backlog items, organized the work, and starts building a product. But then reality hits. Bugs, support cases, production issues appear, all stealing precious time for the planned goal. The result? A partially completed goal that rolls into the next sprint. Kicking off the new sprint, the team adds the new goal to the old one, and suddenly you've created a composite goal, a laundry list of everything a team hopes to finish Sunday. Before a long, the sprint goal loses all its meaning, and they become glorified list of backlog items, or they disappear all together in favor of chasing the velocity number, right? Because we all know the focus on output is so strong. All of a sudden, the clear focus and alignment

2:03took common purposes long gone, just like that. And often the teams don't even realize they drift away from the common purpose. Let's flip the scenario. What if the team does hit the sprint goal, but does so early? Now what did I do? Do you start fixing bugs and paying down technical debt? Do you expand the goal to take on new work and to sprint early and start a new one with a new goal? While there's no clear answer, there is some clear guidance that I can give you. Anytime a team finishes early, they should get a head start on an item and an expert. What that means is they're not saying, oh well, we'll go pull something in because that's that's deceptive, that's not cool. Because the team never committed to that original item and at least leadership with the impression if they don't finish it, that they're not finishing the work they committed to when an actuality that was not one of the original items that they did commit to. So the better set is let's go get a head start on the first item in an expert. And in doing so, we can, if we finish it, we can pull it in and take credit for it. If we don't finish it, it's no harm, no foul, because it was

3:06never part of our original sprint. And when product managers think only in terms of features and not goals, this problem magnifies. It becomes worse. Bugs and tech that rarely ever have a home in any kind of feature driven prioritization. That's why we detect that sprints. So teams either force them in and make a fake goal or ignore them entirely and say come back to buy them later, which is the other reason why you make a tech debt sprint. We can talk about that separately. Now imagine your product grows. Three teams each with its own sprint goal. What happens when they depend on each other? Team A needs an API update from team B to complete its goal, but team B is busy chasing its goal. Who stops and who waits for who and who fails? You might say we have feature teams that own their own vertical slices. Great. But who owns the quality across all the slices? If one team changes another piece, another person, another team's code, will they catch every regression? Probably not. Dependencies will still surface, just in less obvious ways.

4:08This is where your concept of the scrum of scrum should come in and save the day. The coordination meeting of team leads or one individual from each scrum team, it helps, but it's also fragile. On a human element, we don't function that way. Constant communication and manual synchronization just aren't our thing. And when every team is chasing its own north star, proverbially, collaboration turns into a competition for people. Too many goals equals too many missed targets, equals too many opportunities. So, sprint goals aren't just hard to get right. They work only in very specific conditions. Small independent teams, working on new isolated functionality with minimal dependencies and distractions from an outside world. Outside that context, they collapse under their own simplicity. scrum has its limits. And if you question why, despite all best efforts, things still turn into well a crap show. And here's the answer. Here's your answer to that. If you stop hiding behind

5:13a very easy and forever acceptable excuse that you're doing it wrong, and give some independent thought to what we observed. Well, maybe just maybe, we'll begin to realize why pure idealistic concepts like sprint goals and pure scrum still miss the mark. After all, do we even want to succeed? I mean, we try. We make things work. We follow advice over and over. But at some point, we have to stop perfecting the technique and start looking at our results. Instead of isolated sprint goals, create a list of centralized protocols. Protocols tend to give you better and more clear direction in from what I've learned. And it's easy for you to grab onto, and it usually makes more sense. A particle gives direction to everyone. One direction, one north star, everything's aligned. We're good to go. If something where urgent comes up, like a critical support issue, the priority naturally determines when it gets addressed, no need to rewrite the goal. The goal stays put. But naturally, it becomes delayed by making way for something that's much more

6:17critical. So you have to align how you're going to have inflow management of ticketing, of objections, of things that need to be fixed. There are going to be these things, and not say no, I'll go away. They will happen. You just need to know how to deal with them. This also means that teammates working on a highest priority item for the goal. Team B should do everything in their power to help do their part instead of attempting to reach their own independent goal before they left their head to help. Imagine Team B, a quarterback responsible for throwing the perfect pass in Team A, running for a touchdown. Team B must throw the ball perfect, perfectly timed, and must be a complete pass no matter what. This comes with a new profound realization. Dependencies exist only in places where every team is siloed and serves itself above everything else. A well-written product goal also shifts focus from feature delivery to outcome delivery, from build this integration to increase user signups by 10%. That subtle change drives better collaboration and better decisions.

7:20Teams understand the why behind the what, not just the what and how we're going to get it done. And because protocols are bound by an arbitrary time box, sorry, because protocols are not bound by arbitrary time boxes, quality no longer suffers for the sake of a deadline. You finish when a goal finishes, and it's supporting offense, and you're wholly, truly done. It just makes sense. Sprinkles were meant to help teams focus, but practice shows they often help fragment teams and break them down. They don't scale across teams, they break under dependencies, and they lose meaning in the moment exceptions appear, which in a real world could mean every single sprint. So instead of chasing these magic unicorns, give teams a single clear product goal or alley around, one direction if you will, one purpose, one alignment, a foundation for strong, continual flow, shared focus, and progress it actually matters. That's better agile, and that's the way that we're all going to become better human beings. That's going to do it. I hope you enjoyed this episode. If you have a

8:21topic you want us to discuss, learn more at agile.ad.com. We'd love to hear from you, and it's always we encourage you to stay healthy, stay well, and stay agile, my friends. Until next time, do take care.