What is sprint planning?
Sprint planning is the agile ceremony where a team selects work items from a prioritized backlog and commits to completing them within a fixed timebox, typically one to two weeks. It is the starting ritual of each sprint in scrum-based teams: the Product Owner presents the highest-priority backlog items, the development team discusses feasibility and scope, and the group agrees on a sprint goal - a short statement that defines what this sprint will deliver.
The output of sprint planning is not a detailed project plan. It is a focused set of work items that the team believes they can complete within the sprint, along with a shared understanding of what "done" means for each one. The sprint backlog becomes the team's contract for the next one to two weeks: these items and nothing else, unless the team collectively agrees to a scope change.
Sprint planning exists to solve two problems that unstructured work creates. First, it forces prioritization - the team cannot work on everything, so they must choose the most valuable items. Second, it creates predictability - stakeholders know what will be delivered and when, at least within the sprint boundary.
Sprint cadence vs. kanban flow: what is the difference?
The fundamental difference between sprint-based and kanban workflows is how work enters and leaves the system.
In a sprint model, work enters through the planning ceremony at the start of each sprint. The team commits to a fixed scope, and new items (unless they are emergencies) wait for the next sprint. Delivery happens at the end of the sprint - the potentially shippable increment. This creates a cadenced rhythm: plan, build, review, demo, reflect, repeat.
In kanban, work enters the system whenever it is prioritized and capacity opens up. There is no batch commitment - items flow through the board one at a time, constrained by WIP limits rather than sprint scope. Delivery is continuous: as soon as a card reaches Done, it ships. There are no sprint boundaries, no planning ceremonies, and no velocity tracking.
| Aspect | Sprint (Scrum) | Continuous (Kanban) |
|---|---|---|
| Work intake | Batched at sprint start | Pulled when capacity opens |
| Commitment | Fixed scope per sprint | No scope commitment |
| Delivery | End of sprint | Continuous |
| Planning overhead | 2-4 hours per sprint | Minimal or none |
| Responds to change | Next sprint (days to weeks) | Immediately |
| Constraint mechanism | Sprint capacity | WIP limits per column |
Neither approach is universally better. Sprint cadence gives stakeholders predictable delivery windows and regular demo opportunities. Kanban gives the team maximum flexibility and eliminates the overhead of batch planning. Many high-performing teams land somewhere in between - a topic we cover in detail in our kanban methodology guide.
How do you model sprints on a kanban board?
Not every project management tool has native sprint features - dedicated sprint backlogs, burndown charts, velocity tracking. Flux is a kanban-first tool: it excels at continuous flow with real-time sync, WIP management, and multi-board views. It does not have built-in sprint primitives, and that is a deliberate design choice.
But if your team wants a sprint cadence for planning purposes while keeping the benefits of kanban flow, you can model sprints effectively using columns, labels, and board structure. Here is how.
Method 1: Labels as sprint markers
Create a label for each sprint: "Sprint 14", "Sprint 15", etc. During your biweekly planning session, tag the selected backlog items with the current sprint label. During the sprint, team members pull from the backlog but prioritize items with the current sprint label. At the end of the sprint, filter by the sprint label to see what was completed.
This approach preserves continuous flow - items are not locked into a sprint column - while still giving you sprint-level visibility. The label becomes your sprint boundary without restricting how work moves through the board.
Method 2: Columns as sprint stages
If your team prefers a more visual sprint boundary, create columns that represent the sprint lifecycle: "Sprint Backlog" (committed items for this sprint), "In Progress", "Review", "Sprint Done". At the start of each sprint, move selected items from the main Backlog into Sprint Backlog. At the end, archive or move completed items and clear Sprint Backlog for the next cycle.
This method creates a clear visual separation between sprint work and everything else. The trade-off is an extra column to manage and the need to physically move cards during planning.
Method 3: Separate boards per sprint
For teams that want complete isolation between sprints, create a new board for each sprint using a sprint board template and use the multi-board view to see all active sprints at once. This is the cleanest separation but creates more boards to manage. It works best for larger teams where multiple squads run their own sprints.
Which estimation technique should you use?
Estimation is the most debated aspect of sprint planning. Some teams invest hours in it; others skip it entirely. Here are the four most common approaches, with honest assessments of each.
T-shirt sizing (XS, S, M, L, XL)
The fastest estimation method. Each item is categorized by relative size without attaching a number. T-shirt sizing is best for initial backlog grooming and rough prioritization - it tells you which items are large enough to break down, without the false precision of story points. Apply it as a label on each card and use it to sequence work: pull small items when you need quick wins, schedule large items when you have uninterrupted time.
Story points (Fibonacci)
The classic scrum estimation method. Items are assigned points from the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) representing relative complexity and effort. Over multiple sprints, the team's average points completed per sprint (velocity) becomes a forecasting tool for future planning.
The upside of story points is that velocity trends are useful for long-range forecasting - if the team consistently delivers 30 points per sprint, a 90-point epic will take roughly three sprints. The downside is that points are often gamed, debated endlessly, or inflated over time. If your team spends more than 15 minutes estimating a single item, the estimate is not adding value.
Time-based estimates
Estimating in hours or half-days. This is the most intuitive method and the one most likely to be wrong. Software tasks are notoriously difficult to estimate in time because the variance between best-case and worst-case is often 5x or more. Time estimates work for well-understood, repetitive tasks (data migrations, standard CRUD endpoints) and poorly for novel work (new integrations, performance optimization, architecture changes).
No-estimate: uniform sizing
The increasingly popular alternative: skip estimation entirely. Instead, break every work item into pieces small enough to complete in one to three days. If an item is too large, break it down further. The team's throughput (cards completed per week) replaces velocity as the forecasting metric.
This approach works best for teams with experienced developers who can intuitively scope work and the discipline to break large items down. It eliminates estimation meetings entirely and shifts the focus to the skill that actually matters: decomposing complex work into small, shippable increments.
How do you run an effective sprint planning session?
Regardless of estimation technique, the planning session itself should follow a tight structure. Bad sprint planning drains energy; good sprint planning creates focus.
Before the session
- Groom the backlog. The Product Owner (or whoever owns prioritization) should have the top 15-20 backlog items described, roughly scoped, and ordered by priority before the planning meeting. Planning is not the time to write card descriptions from scratch.
- Review the previous sprint. Look at what was completed, what spilled over, and what was blocked. Carry-over items should be discussed first - are they still the highest priority, or should they be re-prioritized?
- Check team capacity. Account for time off, on-call rotations, and any known meetings or commitments that reduce available work time. A two-week sprint with a public holiday is not a two-week sprint.
During the session
- Set a sprint goal. One sentence that captures what this sprint delivers. "Ship the new onboarding flow" or "Resolve all P0 performance issues." The goal guides trade-off decisions mid-sprint.
- Walk the top items. The Product Owner presents each candidate item. The team asks clarifying questions and flags risks. If a card is unclear, it goes back to the backlog for refinement - do not commit to work you do not understand.
- Commit to scope. The team selects items until they hit their capacity limit. Do not overcommit. Completing 80% of a smaller scope builds more trust than completing 60% of an ambitious one.
- Timebox the meeting. Two hours maximum for a two-week sprint. If you cannot finish planning in two hours, your backlog is not groomed or your items are too large.
After the session
Tag committed items with the sprint label or move them to the Sprint Backlog column. Ensure every item has an assignee. Share the sprint goal in your team channel. Then stop planning and start building.
Sprint review and retrospective: closing the loop
Sprints have two closing ceremonies, each serving a different audience.
Sprint review
The sprint review is a demo for stakeholders. Show what was built, collect feedback, and update the backlog based on what you learn. Keep it under 30 minutes. The goal is to validate that the team built the right thing, not to present slides about velocity. If something shipped that stakeholders can use, show them using it.
Sprint retrospective
The retrospective is the team's internal reflection: what went well, what did not, and what to change. The most effective retro format is simple: each team member writes one card for "went well" and one for "needs improvement." Discuss each card. Pick one concrete action item to try next sprint. Do not pick five - pick one and actually do it.
The retrospective is where process improvement happens. If your retro consistently produces the same complaints without changes, the ceremony is theater. If it produces one small improvement per sprint, the team gets measurably better every two weeks.
For teams that find sprint ceremonies too heavyweight, kanban offers a lighter alternative that still delivers predictable results. See our project management pillar guide for a comparison of all the options and guidance on choosing the right approach for your team.