Sprint Planning: A Step-by-Step Guide

Sprint planning is the meeting that kicks off every sprint. The team agrees a sprint goal, picks the backlog items that will achieve it, and works out how to deliver them. Done well, it takes an hour or two and produces a plan everyone believes. Done badly, it takes all afternoon and produces a wish list.

Most bad sprint planning is decided before the meeting starts, by what was (or was not) prepared.

Before the meeting

Preparation is the Product Owner's job, with help from the team during backlog refinement.

• Order the backlog. The top items should reflect current priorities, not last month's. See backlog management for keeping it lean.
• Make the top items ready. Each should have a clear description, acceptance criteria and a rough estimate. Read how to write user stories if yours keep arriving vague.
• Know your capacity. Count leave, public holidays, support duty and that client workshop on Thursday.
• Check the last sprint. Unfinished work needs a decision: carry over, re-estimate or drop.

Running sprint planning step by step

1. Set the sprint goal first. One or two sentences describing the outcome, e.g. "Customers can reset their password without contacting support." The goal gives the team something to aim at when details change mid-sprint.
2. Pull items that serve the goal. Start from the top of the backlog and ask, for each item, "does this help the goal?"
3. Size against capacity, not hope. Use recent agile velocity as a guide, adjusted for this sprint's availability. If the last three sprints delivered around 30 points, planning 45 is not ambition, it is fiction.
4. Break items into tasks. Developers split the selected stories into concrete tasks or sub-tasks. This is where hidden work appears: migrations, test data, environment config.
5. Assign owners and testers. Make it clear who builds and who tests each item, so QA is not a surprise at the end.
6. Confirm and commit. Read the goal and the list back. If anyone has doubts, deal with them now.

Running sprints right now? See how Flow handles boards, sprints and burndown together. Get started with Flow →

Common sprint planning mistakes

• Planning to 100% capacity. Something will interrupt. Leave room.
• No sprint goal. Without one, the sprint is just a to-do list and any trade-off becomes an argument.
• Estimating in the meeting from scratch. That is what refinement is for.
• Ignoring testing. If QA effort is not in the plan, it will not be in the sprint.

Jira, Linear and sprint planning tools

Jira has mature sprint planning with backlogs, estimation fields and sprint reports, and it is flexible enough to fit almost any process. Linear takes a faster, opinionated approach with cycles that roll automatically, which many product teams love for its speed.

Teams delivering for clients often need one more ingredient: a link between the sprint, the testing of its work and the client's acceptance.

How Flow helps

• Sprints with start, complete and bulk-complete. Sprint progress and burndown appear in Flow's project reporting.
• Tickets with an assignee and a tester. Every item carries estimate, priority and the person who will test it, so QA is planned, not bolted on.
• Sub-tasks and bulk updates. Break stories into sub-tasks in planning, and bulk change assignee or priority with one-click undo.
• Person workload. Livex Flow shows each person's workload, so you can spot someone overloaded before you commit.