Sprint Planning, Estimating and Velocity

This post describes the basics of an agile workflow. The focus of agile is to produce working software. Agile involves the end user so that you build the software that they want. Agile adapts to change by dealing with small units of work and not planning too far ahead.

In short, agile avoids the waterfall problem of spending 6 months building a product that nobody wants.

The basis of most agile teams is the sprint. Sprints are typically 1 week or 2 weeks long. In order to start a sprint, a team needs to estimate their work and decide how much of it to put into their sprint.

To do that, we need to talk about sprint planning, estimating and velocity…

Why sprints?

When planning a project, sprints are used to break it up into manageable units. This allows Project Managers to plan long term projects because they can estimate how many sprints are required.

Sprint Planning

1. The team has an estimating session:

Projects Managers, Developers and QAs break large projects into stories. Stories are small units of work that should take no longer than a couple of days. Each story should deliver real value. Each story should be testable and deployable on its own

The team now needs to estimate each ticket. You can either do this using t-shirt sizes (small, medium, large) or you can use arbitrary points (1, 2, 3, 5, 8). The idea is to get away from estimating in terms of time and to instead estimate in terms of the ticket complexity. Each ticket should be relative to the others, for each ticket you should ask ‘is this more or less complex than the previous ticket?’

2. The team has a sprint planning session:

Having estimated all of the stories the team can decide how many stories to pull into their next sprint. The stories that they pull into the sprint are determined by two factors: velocity and priority.

Velocity is the number of points that the team completed in their previous sprint(s). That means only stories that are done, tickets that have been developed and just need to be tested don’t count.

Priority is decided by the project manager/business stakeholder. Highest priority tickets are usually those that are most needed and can be shipped first.

The team should pull in extra stories, highest priority first, until the points in the current sprint equal the team’s velocity.

Velocity will automatically stabilise

The benefit of velocity is that it will automatically stabilise over time.

If the team completes less work than their sprint target, their velocity will automatically decrease on their next sprint. Meaning they will commit to less work and hopefully achieve their target next time.

If the team completes more work than their sprint target, their velocity will automatically increase on their next sprint. Meaning they can commit to more work.


There are a couple of preconditions the must be met in order for velocity to be useful:

  1. The team must not change. Establishing a consistent velocity happens over time and is only meaningful when the same team is working together. If the team is constantly changing then velocity will also change – making it useless as a planning tool.
  2. The team should work at a consistent intensity. There is always a temptation to work late or work on weekends when a project deadline looms. The problem with this is that it causes a spike in velocity. As a result, the team will take on more work next sprint which they will be unable to complete.
  3. The team should only take on as many points as their velocity allows. Sometimes the business may be disappointed by how much the team can complete. However, it is better to be honest than agree to take on too much and fail.
  4. Team members should not be ranked by velocity. Velocity is not a good performance indicator. If developers know that it is being tracked they will start to increase their estimates and they will rush tickets – sacrificing quality.