So What is Sprint Planning Anyway?
Not all product teams run in sprints. And that's fair.
Maybe your org has legacy systems that move slow. Maybe vendor contracts only change at fiscal year end. Maybe no one's pushed for it yet.
That's exactly where I am with my new product. Lots of baggage in how we do things.
I'm slowly trying to unravel it and move towards agile.
For those who aren't familiar yet, here's the quick version.
Agile is a way of working where you deliver in short cycles instead of one big release.
Scrum is one of the most common frameworks for doing that.
And sprints are those short cycles, usually 2 weeks.
At the beginning of every sprint, the team sits down for a sprint planning.
This is where you decide: what's the goal, and what work are we committing to?
Why it matters:
→ Gives clarity to everyone on what we're building and why
→ Brings the whole team together, not just the PM deciding alone
→ Prevents half-baked items from sneaking in
→ Helps you estimate how much you can take on vs. not
Downsides? Honestly, I haven't found any.
The meeting itself can feel painful if you run it wrong. But the practice? Worth protecting.
The Meeting Before the Meeting
One of the biggest things that helps sprint planning go well is what you do before it starts.
Here's my prep flow:
1. Prioritize the top user stories.
This is the PM's job.
I always prepare 20 to 30% more stories than what I think we'll take in. Not the whole backlog. Just enough so we have room to adjust.
2. Add the "why" and "why now" to every story.
Impact without timing doesn't move people.
If engineers don't understand urgency, they won't prioritize the same way you do.
3. Start detailing next sprint's stories while the current one is still running.
Sometimes that means writing things down. Sometimes it's analyzing user data. Sometimes it's talking to architects.
The point is: don't wait until the sprint ends to start preparing.
4. Delegate discovery work.
This one changed how I work.
When I learned that not everything has to be done by the PM, it shifted how my team operated.
We started assigning who owns the detailing on specific stories. Especially the more technical ones, where engineers have a clear advantage over me.
The overall responsibility still sits with the PM. But the execution? Shared.
5. Run a refinement session mid-sprint.
This is where we check in. Each person leaves knowing what discovery work they need to do before the next planning.
But here's the thing.
It only works if you make it crystal clear why they're spending effort on that story. Why it matters.
Otherwise? People come back a week later with nothing done.
Not because they're lazy. Because they weren't convinced it was worth their time.
The whole point of this prep:
Make sure you and your team do the best clarifying job possible before the sprint even starts.
Because in my experience, the biggest time wasters always come down to two things:
→ Unclear what we wanted to do in the first place
→ Dependencies and blockers from other teams we can't control
The Sprint Planning Flow
Timing depends on your sprint length and team size.
For context, my team was: me as PM, 2 software engineers, 1 delivery manager, 1 SRE, 1 tester.
Here's how we ran it:
Intro (5 min)
I talk about the sprint goal and how it connects to the product goal and roadmap.
Story walkthrough + estimation (45 min)
We go through items one by one.
I kick off each story with the impact, the user, and the "why now."
If I detailed the story, I walk through it. If someone else owned it, they jump in.
Everyone asks clarifying questions. Then we estimate using story points.
We used Fibonacci, but honestly, any scale works.
Capacity check (5 min)
Once everything is estimated, we compare total points to our sprint velocity.
Engineers decide how much is too much. They own that call.
I follow their recommendation. But I always choose which stories to prioritize.
Assignment (5 min)
Each story gets assigned to the person who owns delivering it.
Tasks offline (15 min)
Story owners break down their stories into tasks after the meeting.
We had a definition of done for this. At first, people forgot. But after a few sprints, it became habit.
And it saved us all from staring at the screen together.
Total time: 1 hour.
What We Dropped to Stop Hating It
Most of us run an imperfect version of Agile. And that's fine.
You can't stick to the framework for the sake of the framework.
I actually tried that once. Because sometimes I'm a stickler for "by the book."
We dropped it quickly. Ideal wasn't working.
Here's what we let go of:
→ One single goal per sprint. I would have loved this. But hot fixes overtake plans. Engineers have different skills and ownership areas. One goal didn't always fit.
→ The 2-hour timebox. In an already meeting-heavy environment, that was too long. One hour was enough.
→ Breaking stories into tasks during planning. Moved this offline to save time.
→ Sprint planning every single sprint. Every 6 months or so, we'd skip one and focus on discovery and learning instead.
→ PM-only ownership of story prep. This was the biggest shift. I still owned the "what," the impact, and the "why." But engineers started owning the prep. It freed my time. And made them more engaged.
We also added something: I included my own PM tasks in the sprint. It kept me honest and visible to the team.
💬 Your Challenge This Week
Look at your next sprint planning. Ask yourself:
→ Am I preparing enough before the meeting starts?
→ Is my team doing discovery work, or is it all on me?
→ What one thing could I drop to make it less painful?
Even small changes add up. And your engineers will notice.
Hit reply and tell me: what does your sprint planning look like?
