1 small change Scrum Masters can introduce for better sprint planning meetings

Mediocre software teams only discuss what they are supposed to build during their planning meetings.

I’ve run hundreds of sprint planning meetings, across dozens of teams in my career. I always focused on trying to define exactly what the team should be building. Sketching, questioning, defining, and eliciting details from a product owner.

But it wasn’t until I reframed my outlook on planning that success started to click.

Deciding what NOT to build is just as important as deciding what to build

When a sculptor creates a statue out of solid marble, they’re defining that work of art by what it’s NOT. Software can be the same way:

• “This feature does not need to support a mobile view.”
• “This feature does not need to handle more than 20 users at a time.”
• “This feature does not need to use the updated style guide.”

By reframing the team’s outlook during planning, the Scrum Master can first help the team understand what they’re not building, so they don’t waste their time talking about it later.

Start your next planning meeting by discussing what you’re not building

You’ll be surprised how quickly this exercise goes from silly (”we’re not building the space shuttle”) to serious (”wait, we’re not hooking this up to SSO?”) as assumptions bubble up to the surface and the team is forced to explore what they’re NOT doing.