Use Velocity-Based Planning

Story points are a means of measuring the size and complexity of work items. Velocity is a measure of the rate of progress, which is based on the rate at which work is being completed, measured in story points. Velocity-based planning is the use of story points and velocity to plan work and track it.

Velocity-based planning and tracking is not part of textbook Scrum, but in my experience, it should be. Story points and velocity should be used in the following ways.

Sizing the product backlog

Story point estimation is used to size the product backlog. The sizes of items in the product backlog are estimated using story points, and the story points are added to compute a total size for the backlog. This is done early in a release cycle and as work is added to or removed from the backlog. The extent to which this is done is driven by the team’s need for predictability, which is discussed in the “More Effective Agile Predictability” chapter.

Calculating velocity

The amount of work the team commits to each sprint is counted using story points. The number of story points the team delivers each sprint becomes the team’s velocity. Velocity is calculated on a sprint-by-sprint basis, and average velocity is also calculated.

Sprint planning

The team uses story points as the basis for planning how much work it can commit to in a sprint, based on the team’s observed velocity.

If a team has been averaging 20 story points per sprint, and the team’s proposed sprint goal would require the team to complete 40 story points, the team should scale back its plans. If one of the team members is going on vacation or if several team members will be attending training, the team should commit to fewer story points for that sprint than it has been averaging. If the average of 20 story points has been accomplished through many late nights and weekends and is not sustainable, the team should plan for a lower number. If the team has been accomplishing its sprint goals comfortably, it might commit to a higher number than its average velocity. In all cases, the team uses its average velocity as a reality check for its sprint planning.

Release tracking

The average velocity can be used to estimate or forecast how much time is needed to complete the work in the product backlog. If the product backlog consists of 200 story points and the team has a velocity of 20 story points per sprint, it should take the team about 10 sprints to complete the work in the backlog. I cover specifics of how that works in “More Effective Agile Predictability.”

Accounting for the effect of process changes, staff changes, and other changes

Velocity can be used to measure the effect of process changes, staff changes, and other kinds of changes. I cover specifics in the “More Effective Agile Process Improvement” chapter.