Sprint planning with velocity means sizing the next sprint by what the team finished in recent sprints, not by what it hoped to finish. Velocity is the work a team completes per sprint, usually in story points. Read three or more past sprints, find the typical level, compare estimates with time spent and plan up to it.
Why plan a sprint on past results?
The usual sprint planning goes like this. The team opens the backlog, takes the top tasks, and keeps adding until the sprint "feels full". Two weeks later, part of the work rolls into the next sprint.
Nobody planned badly on purpose. Optimism is built into the process. Each task looks manageable on its own, and nobody adds up the interruptions, reviews and urgent fixes that will arrive mid-sprint.
Past sprints already contain the answer. They show how much the team really finished, under real conditions, with all the interruptions included. Planning on that number is less exciting than planning on ambition. It is also far more accurate.
There is a second benefit. A plan the team can actually complete changes how the sprint feels. Finishing everything on day ten builds trust with stakeholders. Carrying work over every time teaches everyone to treat the sprint plan as a wish list.
Why is one sprint not enough?
A single sprint is a poor guide. It may have been unusually quiet, or full of holidays, or derailed by one urgent client issue.
Take two invented sprints as an illustration. In one, the team planned 60 hours of estimated work, spent 72 and finished everything. In another, it planned 58 and spent less, but several tasks moved to the next sprint unfinished. Which one shows the team’s real pace? Neither, on its own.
What matters is the pattern across several sprints. Three is a sensible minimum; five or six give a steadier picture. Look for the level the team reaches again and again, and for the sprints that stand out. An outlier usually has a reason: a public holiday, a new team member, a big unplanned incident. Note the reason and set that sprint aside.
The typical level is a guide, not a limit. If the next sprint has a holiday in it, plan below the level. If a hard deadline needs a push, the team can decide to go slightly above it, knowing what it is doing.
What do story points, estimate and time spent tell you?
Each completed sprint can be read through three numbers. Each answers a different question.
| Number | What it measures | What it tells the team |
|---|---|---|
| Story Points | The relative size and complexity of completed tasks | How much work the team gets done per sprint, independent of hours |
| Estimate | The hours the team expected the completed tasks to take | How much time was planned |
| Spent | The hours actually logged on those tasks | How much time the work really took |
Reading them together is where the value lies. If story points stay steady but time spent keeps exceeding the estimate, the team sizes work correctly but underestimates hours. If time spent matches the estimate but story points fall, the tasks are getting harder or more time goes to work outside the sprint.
The difference between story points and hours as units deserves its own discussion; our article on effort estimation covers it. For sprint planning, the point is simpler: use whichever unit the team estimates in, and check it against hours actually logged.
How do you use the backlog without overcommitting?
The backlog is a list of everything the team could do. It is not a list of everything the team must do next.
A practical approach:
- Order the backlog by priority before the planning meeting, so the discussion is about scope, not sorting.
- Check that the top tasks have estimates. A task without an estimate cannot be compared with the team’s typical level.
- Fill the sprint up to the typical level from past sprints, adjusted for holidays and known absences.
- Stop there. Leave the rest in the backlog. If the team finishes early, it pulls the next task in.
Carryover deserves attention too. A task that moves from sprint to sprint is a signal. Either it is larger than estimated, it depends on something outside the team, or nobody really owns it. Split it, unblock it or drop it. A Kanban board helps find where such tasks get stuck; our article on finding bottlenecks on a Kanban board shows how.
What if the team has changed?
Past sprints describe the team that did them. When the team changes, the numbers need adjusting.
- A new member joins. For the first sprint or two, expect little extra output. Onboarding takes time from the people who help.
- Someone leaves or goes on long leave. Reduce the level roughly in proportion to their share of the work, then watch the next two sprints.
- The type of work changes. A team moving from new features to maintenance may finish more tasks, but smaller ones. Story points help here more than task counts.
After any change, treat the next two or three sprints as a new baseline.
How do you plan several sprints across projects?
Many service teams do not work on one product. The same people split their week between several projects, each with its own sprint.
Planning each project’s sprint in isolation hides the overlap. A developer may look half-free in each of two projects and be fully booked in reality.
The fix is to see active sprints from all projects on one board, grouped by project. The team lead then sees the total load per person across projects before committing to anything new. Each project keeps its own sprint and backlog. Only the view is shared.
How sprints work in Weenvo
In Weenvo, sprints are switched on in a board’s settings. A board can cover one project or several. The Manage sprints view holds the backlog, the list of tasks not yet in any sprint, and the sprints themselves. Tasks are dragged from the backlog into a sprint, and each sprint can be started, stopped, edited or deleted. Every sprint row shows the number of tasks, the start and end dates and the total estimated hours.
The Board tab shows the tasks of running sprints, in the columns and groups set for the board. Finished sprints lists completed sprints with their tasks, dates and final metrics, including Story Points, Estimate and Spent. Time spent comes from the time people log on tasks, so the numbers reflect real work. The Weenvo wiki on sprints walks through the set-up.
Sprints sit inside project and task management, and time logging is part of time management in the same system, so there is nothing to import before the planning meeting.
The team reads the totals of completed sprints and works out the typical level from them.
Start free and plan the next sprint on the team’s own numbers.
FAQ
How do you calculate velocity for sprint planning?
Add up the story points of tasks completed in each recent sprint, then look at the typical value across three or more sprints. Exclude sprints with an obvious one-off reason, such as holidays. Use that typical value as the guide for the next sprint’s scope.
How many past sprints should you use?
Three sprints is a reasonable minimum, and five or six give a steadier picture. Older sprints matter less if the team or the type of work has changed. After a big change, start a new baseline.
What is the difference between velocity and capacity?
Velocity is how much work the team has completed per sprint in the past. Capacity is how much time the team has available in the coming sprint, after holidays and other commitments. Good planning uses both: velocity sets the usual level, capacity adjusts it for the sprint ahead.
What happens to unfinished tasks at the end of a sprint?
They return to the backlog or move to the next sprint, depending on priority. A task that keeps moving is a warning sign. It may be too large, blocked or without a clear owner, and should be split, unblocked or dropped.