Sprint planning is the meeting where a team agrees on one goal for the next sprint and picks the work that gets them there. Done well, it takes under two hours for a two-week sprint and ends with a short, realistic list everyone believes in. This guide covers how to prepare, how to run the meeting, and how to set it up in AlianHub.
Key takeaways
- A sprint without a goal is just a to-do list with a deadline.
- Plan from last sprint's real numbers, not from hope.
- Most planning problems are backlog problems in disguise.
- Leave slack. Something unplanned will always arrive.
- Let AI draft the breakdown, then let people decide the commitment.
What sprint planning is for
A sprint is a fixed stretch of time, often one or two weeks, in which a team finishes a set of work. Sprint planning answers three questions:
- Why is this sprint worth doing? That is the sprint goal.
- What will we finish? That is the selected work.
- How will we do it? That is the breakdown into tasks.
The goal is the part people skip, and it is the part that saves the sprint. When something unexpected lands midweek, the goal tells you what to protect and what can slip.
Before the meeting: prepare the backlog
Most painful planning meetings are really backlog grooming sessions that ran late. Do this work a day or two before.
Order the backlog
The product owner, or whoever decides priority, puts the top items in order. The team should not be debating priority in the planning meeting.
Make the top items ready
A ready item has a clear description, an agreed outcome and no open questions that block starting. If the team cannot explain how they would know it is done, it is not ready.
Check capacity
Count who is actually available. Holidays, support rotations and onboarding all eat into a sprint. A workload view that shows planned hours per person against capacity makes this a two-minute job instead of a guess.
Tip: write capacity on the whiteboard, or the top of the sprint notes, before anyone mentions a single task. It anchors the whole conversation.
Running the meeting, step by step
Here is a simple agenda that works for most teams.
| Step | Time for a 2-week sprint | Output |
|---|---|---|
| Review last sprint's numbers | 10 minutes | Realistic capacity |
| Agree the sprint goal | 15 minutes | One sentence |
| Pull work from the top of the backlog | 30-45 minutes | Selected items |
| Break items into tasks | 30 minutes | Owned tasks |
| Confirm the commitment | 5 minutes | Team agreement |
1. Look back before you look forward
Start with what the team actually finished last sprint. Velocity, the points completed per sprint, is a better guide than anyone's optimism. If you finished 30 points last time, planning 45 this time is not ambition, it is a slipped sprint.
2. Write the sprint goal
Keep it to one sentence a stakeholder would understand. "Customers can pay by invoice" is a goal. "Do tickets 101 to 117" is not.
3. Select the work
Pull items from the top of the backlog until you reach your capacity, then stop. If an item does not serve the goal, ask whether it belongs in this sprint at all.
4. Break it down
Split each item into tasks small enough to finish in a day or two, with an owner. This is where hidden work appears, such as a migration nobody mentioned or a review that needs another team.
5. Commit with slack
Leave room for the unplanned. Many teams hold back a share of capacity for bugs and support. A sprint you finish builds more trust than a sprint you overfill.
Sprint planning in AlianHub
AlianHub includes sprints alongside its List, Board, Table, Calendar, Gantt and Workload views. Here is how the pieces fit a planning session.
- Backlog and sprint lists. Put candidate work in the project, then group the selected tasks into the sprint, for example "Sprint 4".
- Workload view. See planned hours per person and day against capacity before you commit.
- Burndown and Gantt. Engineering teams get sprints that show progress with a burndown and a Gantt chart for dependencies.
- Velocity report. The portfolio reports include velocity in points per sprint, so your look-back step uses real numbers.
- Sprint notes. Keep the goal and decisions next to the work, not in a separate document.
You can see these views on the features page and the engineering setup on the teams page.
How to do this in AlianHub with AI
AlianHub's AI features take the typing out of planning. People still own the commitment.
- Open AI, then the AI project generator (or Write with AI). Enter a brief such as "Plan a two-week sprint to launch our new pricing page, with design, build, QA and a launch checklist."
- Answer the generator's questions, then review the plan: lists, tasks and sub-tasks. Nothing is built until you accept it.
- For a single backlog item, write a brief of at least 40 characters in the task and run the Intake skill (brief.parse). It proposes subtasks with estimates and lists the open questions.
- In the Ask box, scope to the project and ask "Who is over capacity next week?" before you commit.
- In the Agents tab, set a Reporter (digest.ceo) to L3 so it posts a digest on a schedule during the sprint.
- Approve or decline the proposed breakdowns in AI, then AI Inbox. Agents may set In progress or In review, but no agent closes a task.
More on the limits on the AI controls page.
A business scenario: planning that ends on time
Picture a product team whose planning meeting regularly runs over because half the items arrive unsplit. Before the meeting, the product owner runs the Intake skill on the top backlog items. Each comes back with proposed subtasks, estimates and open questions.
The meeting now spends its time on the goal and the trade-offs, not on typing subtasks. Open questions are answered before work starts, so fewer items stall midweek. During the sprint, the Reporter's digest flags stuck tasks early, which means fewer surprises at the review and fewer missed release dates. The team ships more of what it plans, which is how a small team keeps pace with a growing roadmap.
Common sprint planning mistakes
- Planning to 100 percent capacity. Something always comes up.
- No goal, or five goals. One clear goal beats a list of priorities.
- Debating priority in the room. Settle it before the meeting.
- Huge items. If it cannot finish in the sprint, split it.
- Ignoring the last sprint. The numbers are there for a reason.
If you are choosing between sprints and a continuous flow, our post on kanban vs scrum compares the two.
FAQ
How long should sprint planning take?
A common guide is up to two hours per week of sprint, so up to four hours for a two-week sprint. Teams with a well-prepared backlog often finish much faster.
Who should attend sprint planning?
The people doing the work, the person who owns priority, and whoever facilitates. Stakeholders can share context at the start but should not decide the commitment.
Does AlianHub support story points and velocity?
AlianHub's reports include sprint velocity in points per sprint, and engineering sprints show a burndown and a Gantt chart. You can try them in the live demo.
Can AI plan the sprint for us?
AI can draft the breakdown from a plain-language brief, which saves real time. The team should still check capacity and agree the commitment.
Try running your next planning session in a real sprint board. Open the AlianHub demo, or self-host it free for your team, and send this guide to whoever runs your next planning meeting.