Sprint planning for small teams: a 45-minute meeting that actually works

Sprint planning has a reputation for being the meeting that eats your Monday. Two hours of estimating, debating and re-ordering a backlog, and the team still leaves unsure what they've signed up for.

It doesn't have to be like that. For a team of three to ten people, a good sprint planning meeting takes about 45 minutes, as long as the right things happen before it and the meeting itself has a clear shape.

Here's the agenda we recommend, and why each part is there.

What sprint planning is for

A sprint is a short, fixed period, usually one or two weeks, in which the team commits to finishing a set of work. Sprint planning answers two questions:

1. Why is this sprint worth doing? (the sprint goal)
2. What will we finish to get there?

Notice what's not on the list: deciding how every task will be done, or estimating work you won't touch for a month. Those are the things that turn a 45-minute meeting into a two-hour one.

Before the meeting (15 minutes, one person)

Most slow planning meetings are slow because the backlog isn't ready. Before the meeting, whoever owns priorities (a product owner, a lead, or a founder) should:

• Put the backlog in order. The most important work at the top. If two things are equally important, pick one anyway.
• Make the top items clear. Each task near the top should have a title someone else understands and, where it helps, a sentence of context or a link.
• Draft a sprint goal. One sentence about the outcome, not a list of tasks. "Customers can pay by UPI" is a goal; "Do tickets 41, 42 and 47" isn't.
• Check who's away. Holidays and time off change how much the team can take on. It's easier to know this before the meeting than to discover it on day three.

The meeting: a 45-minute agenda

1. Look back at the last sprint (5 minutes)

Not a full retrospective, just the numbers that matter for planning:

• What did we finish?
• What's unfinished, and does it still matter?
• How much did we complete compared with what we planned?

That last number is your velocity, and it's the most useful input you have. If the team planned 30 points and finished 22, planning 35 this time is wishful thinking.

2. Agree the sprint goal (5 minutes)

Share the draft goal and ask one question: if we only achieve this, is the sprint a success? Adjust the wording until the answer is yes. A clear goal makes every later decision easier, because "does this help the goal?" settles most debates.

3. Pick the work (20 minutes)

Work down the ordered backlog, top first:

• Size each task as you go. Story points work well because they compare tasks with each other ("this is about twice that") instead of guessing hours. Small teams can keep it simple: 1, 2, 3, 5, 8. Anything bigger than an 8 should be split.
• Stop at your capacity. Use the average of your last three sprints, minus anyone who's away. When the total reaches it, stop, even if there's "just one more small thing".
• Leave some slack. Bugs and urgent requests always arrive mid-sprint. Planning to about 80% of capacity leaves room for them without blowing up the plan.

If an item near the top turns out to be unclear, don't solve it in the meeting. Move it down, give it to someone to clarify, and take the next one.

4. Check the plan (10 minutes)

Look at the sprint as a whole:

• Does everything in it serve the goal? If something doesn't, why is it in?
• Is the work spread sensibly, or is one person holding half the points?
• Are there dependencies, such as waiting on a client, another team or a decision? Name them now.

5. Commit (5 minutes)

Ask each person: can we finish this? Not as a formality; if someone hesitates, take a task out. A smaller sprint the team finishes is worth more than a big one it doesn't, because finishing is what makes your velocity, and next sprint's plan, trustworthy.

Common mistakes

• Planning with a messy backlog. Fifteen minutes of preparation saves thirty minutes of meeting.
• Ignoring velocity. Optimism is not a planning method. Your last three sprints are.
• No sprint goal. Without one, a sprint is just a to-do list with a deadline.
• Estimating everything. Only size what might go into this sprint.
• Changing the plan every day. New work should usually wait for the next sprint. If something truly can't wait, swap it for something of the same size and say so.

After the meeting

Put the plan where everyone can see it: a sprint board with the goal at the top, the days left, and the points done so far. Look at it together at a short daily check-in. At the end of the sprint, compare what you planned with what you finished; that's the first input to your next planning meeting.

Doing this in Tazor

If your team plans in Tazor, everything above has a home:

• Backlog & planning shows the backlog next to your sprints. Give each task story points and move it into the sprint; if a sprint plans more points than your average velocity, its total turns amber.
• Time off shows who's away, so capacity is real.
• The Sprint board shows the running sprint's goal, days left and points done.
• When you complete the sprint, you choose where unfinished work goes, and Reports shows the burndown and your velocity for next time.

You can try Tazor free, or read the sprints guide to see how it works.

---

Short version: prepare the backlog before the meeting, agree one goal, plan to your real velocity, leave some slack, and finish in 45 minutes.