We all know what good sprints should look like. But we aren’t always good at “eating our vegetables” when it comes to sprint planning. And if the planning part isn’t healthy, your sprint is probably going to end up as a struggle. I’ve experienced enough of those firsthand that I now work hard to avoid them by following a few important guidelines in the sprint planning process.

Guideline #1: Small stories are a good thing!

I once worked on a project where the product manager had written a high-priority story for a checkout modal. 

The modal would display different messages depending on the type of user logged in to the app. The modal also calculated a percentage discount to offer to the user. The discount was dependent on the value of a couple of user attributes. The modal would then redirect the user, based on user type, to a checkout page with the discount already applied.

When we broke down each step, the story came out to be twenty points. Our sprint capacity was eight points. It was not possible to be done in the sprint. When I pushed back on the PM and asked him to break it down into smaller stories, he declined with the reasoning that “The modal is useless unless we deliver it all at once.”

This story might sound like I’m knocking product management—and, okay, in this specific case, I am—but stories aren’t really about one specific person or role. Building a product is a group effort. Being able to discuss, push back, and adapt stories to make sure the product is as successful as possible is critical.

Ultimately, no one wants to pick up a task that has an essay for its description. There are just too many things that can go wrong. Stories aren’t always going to be perfect from the start and some of them take more back-and-forth discussion than others, but managing scope goes a long way toward getting it done.

One caveat: sometimes stories can be too small. For example, ask yourself: “If I showed this story to someone outside my team, would they understand what I want?”

Sure, “I want a button on the landing page,” might get you what you asked for—but probably not what you wanted. Keep it small…but not too small.

Guideline #2: Good sprint planning is collaborative

From writing stories to showing a demo, the most successful iterations are ones where all team members are involved and invested. Different roles on a team have subject matter expertise in different areas and everyone should bring that knowledge to sprint planning and be ready to share it—maybe it’s a story that should have been a spike, for example, and it takes a developer to realize and explain why.

In highly collaborative teams, accountability for research falls on everybody—developers, PMs, designers—regardless of seniority. That collective knowledge leads to a better product and better team morale, which in turn drives commitment to a better product…it’s a positive feedback loop that benefits everyone.

Along those lines, understanding the why behind a story is always helpful. Context not only influences what a developer builds, but it creates buy-in for the product. You’re more likely to be invested in and care about what you’re doing when you know why you’re doing it!

So have everyone attend the sprint planning and collaborate for a better sprint.

Guideline #3: Incomplete sprints are not bad sprints

At Stride, we like to say, “Outcomes over output.” Meaning, it’s more valuable to align on the right thing and make progress toward that, rather than do a whole lot of the wrong thing.

There are times we can be too focused on capacity and hitting goals, and not on the actual outcomes. It’s like cooking for someone who follows a vegetarian diet and making that person the most amazing, succulent, perfectly-cooked…steak. It doesn’t matter how delicious a steak eater might find the meal. It has no value to the target consumer.

The outcome was supposed to be a vegetarian meal. Instead, the output was a steak—and a hungry diner!

Sometimes it takes slowing down and potentially enduring an incomplete sprint in favor of realigning on the right outcome rather than simply trying to produce output with little or no value.

Sprint planning made simple

Focusing on small stories, collaboration, and outcomes seems pretty straightforward. I know simple-seeming things can be pretty hard. If you’re struggling with sprint planning, my advice is to start with only one guideline and go from there. Just like the product itself, team practices - including sprint planning - are about outcomes, not outputs!

‍