
There was a time when terms like sprints, scrum, and kanban were relevant only to software teams.
Now, everyone from marketers to finance wizards loves being agile.
That's because knocking goal after goal in successive sprints is simply a great way to work.
But a lot can go wrong in a sprint, and trouble usually begins at the beginning.
Poor sprint planning can have you running circles for two weeks (or more) and defeat the entire purpose of a sprint: moving the needle; making progress.
You don't want that for your team, right?
So buckle up, and prepare to become a sprint planning ninja by the end of this blog.
Sprint Planning is one of the five scrum ceremonies. It is a meeting that answers two questions: what you can accomplish in a sprint and how.
You run it before anything else in a sprint, and it becomes the foundation for all the heavy lifting that follows. Think of it as Task 1 on Day 1.
Next, let's talk about the people you need to run an a-okay sprint planning meeting.
You need the product owner, the scrum master, and the team.
They assume the leadership role in a scrum team and understand the product roadmap inside-out.
Key responsibilities -
The scrum master is an expert in the Scrum methodology and acts as a servant leader for the team.
Key responsibilities -
All the specialists working on items in the sprint backlog make up the team.
Key responsibilities -
Seems like we’ve covered all the building blocks of Sprint Planning. Time for some actionable advice.
A product backlog is the ultimate to-do list in a project. It contains feature requests, bug fixes, research, and more.
With time, some of these things become outdated or irrelevant. Markets shift, budgets fluctuate, teams evolve, and customer demands grow.
A refined or groomed product backlog reflects these changes. It keeps items relevant to the latest product roadmap and dumps the rest.
Ideally, backlog refinement should happen before the sprint planning meeting.
The rationale here is simple.
Diving headfirst into sprint planning without a refined backlog virtually guarantees a meeting that exceeds its time cap.
Remember, a little housekeeping (read backlog refinement) goes a long way.
Ever attended a meeting that seemed to go on forever, yet nowhere at all? I know I have.
Parkinson's law can explain this. Work expands (or contracts) to fill the time allotted for completion.
Didn’t follow? Allow me to put it in perspective.
When work neither expands nor contracts, it gets done. So, put a sensible time cap on your sprint planning meeting.
The standard practice is to plan 2 hours (at most) for every week the sprint lasts. By this logic, your sprint planning meeting for a 2-week sprint shouldn't last longer than 4 hours.
Of course, you know your team best and can decide a time cap that feels okay. The idea is to have one.
Atoms make up all matter, correct? Same way, all sprints are made of user stories. They are the smallest unit of work that agile teams deliver.
During sprint planning, teams assign points to user stories. The more points a user story has, the more relevant it is to the sprint goal. Airtight logic, no?
Maybe not.
What if team members disagree on the points allotted to a user story? How do you reach a consensus?
The answer may sound whimsical but works like a charm: Scrum poker.

Here are its ABCs:
After scrum poker, prioritizing tasks in the sprint backlog becomes a cakewalk.
Sprint planning is essentially a negotiation between the product owner and the team. The scrum master, if you have one, acts as the bridge between the two.
The product owner and the scrum master can't miss the planning meeting. They have to run it. That begs the question, what about your team? Can Mark do his own thing while the rest of the folks flesh out the plan? He can catch up later over lunch, right?
We suggest otherwise.
Let's say that Mark understands a user story better than the rest of the team. If he's present in the sprint planning meeting, he can push back when the product owner underestimates the effort finishing said user story requires.
Having everyone present eliminates objections from team members in the middle of the sprint. It also fosters a neat sprint backlog that everyone is excited to tackle.
Team velocity and capacity are telling metrics in agile workflows.
Team Velocity - Average story points (on average) your team completes in a sprint.
Team Capacity - Team's total availability (in hours) for a sprint.
If you know that your team's average velocity for the last 3 sprints was 150 user story points, you'd know that a sprint backlog with 170 user story points is a tad bit unrealistic.
That's all well and good, but what happens when you have to run the next sprint with one team member on a long holiday.
Step 1 - Don't catastrophize. Let Ryan live a little.
Step 2 - Assume reduced team capacity and adjust your velocity.
With 9 out of 10 members available for the sprint, you're operating at 90% capacity. That means you'll likely be able to complete 135 user story points in the sprint (trust us, we've done the math).
See how team velocity and capacity inform sprint planning?
After you wrap up the 'who'll do what' part of the sprint planning, it's time to open the floor to questions.
At this point, the product owner needs to do a few things well -
The last one is key. After hours of planning, everyone in your team may feel drained. But you wouldn't want that to carry forward to the rest of their workdays.
Sprint planning meetings have a lot to cover. Defining the sprint goal, preparing the sprint backlog, assigning user stories to team members, addressing team questions, and signing off on an exciting note.
Without an awesome project management tool, monitoring the rest of the sprint becomes data-entry hell.
We're guessing you already know that and probably use a bunch of tools for -
So much context-switching. Argh! We feel your pain and are sighing on your behalf.
Care to do things smarter? We have just the solution for you.

Heavyweights like Amul, ABB, Adecco, and Ecolab, along with 20,000+ teams, use SmartTask to manage all things agile.
That includes managing sprints.
Plan your resources smarter with one scalable client delivery management system.
Try it Live - It's FREE