One of the major risks in software development is time. For a myriad of reasons, from aggressive (sometimes unrealistic) estimations to a fundamental misunderstanding of project scope versus team capacity, projects become delayed and deadlines are missed.

In agile development, the concept of velocity was created in order to help reduce time risk and more accurately predict output relative to the amount of effort involved. Velocity uses learnings and previous information on team output to predict the rate at which your team delivers stories. In time, teams can develop a very accurate estimation of how much they can deliver within a given period. This means:

• Better short- and long-term project estimations
• More accurate predictions of when you will be able to deliver user stories from the product backlog
• Greater ability to maintain predictable velocity throughout the duration of the project
• Decreased risk of product delays

This article will talk about the actions needed to gain and maintain predictable, consistent, replicable velocity.

*Important to note is that not all teams have predictable velocities; it is often dependent on the stage of team development. A useful model for analyzing this is Bruce Tuckman’s Stages of Team Formation. Teams that are in the norming or performing stage have developed enough to have predictable velocities while forming and storming teams rarely have predictable velocities.

Story Points

Let’s start with the basics. Story points are a measurement of the amount of effort required to complete a particular user story or feature. Typically, they are expressed in units of effort (in our case numbers) as opposed to time; the more story points, the higher the effort and the longer it will take. Story points also often consider factors beyond effort, such as risk and uncertainty; the more risk or uncertainty, the higher the story point value.

Mike Cohn of Mountain Goat Software gives a good breakdown of the benefits of applying story points rather than time measurements, using the example of running a 5-mile trail: one person argues that it will take 60 minutes, while the other says it will take 30. They can’t put a time estimate on running the trail, because they run at different speeds. However, they can both agree on one thing: the trail is 5 miles.

The same reasoning applies to story points. Developers will work at different speeds, but they can come to an agreement on how much effort a story will take versus an exact amount of time it will take. Story points are an estimation of the ability of the team to deliver rather than the individual.

Estimating Effort

Teams naturally get better at estimating the amount of effort stories take as time goes on. There is greater exposure to particular kinds of features, as well as retrospectives from other projects or sprints that show when too many or too few story points were allocated for particular user stories or features. Because of this, teams reach a point where they can fairly accurately estimate effort in the measure of story points during sprint planning.

Understanding Team Capacity

With the ability to accurately assess effort involved, the story point system can be applied to a team environment. Based on the learnings from other projects and sprints, teams can more accurately predict not only how many story points a certain feature or user story requires, but also how many story points they can complete within a given time frame.

Say your team has completed 12 sprints. In some sprints, you were able to deliver a certain amount of story points, in other sprints more or fewer story points. After a certain amount of time, you are able to calculate how many story points you can deliver, on average, per sprint. As a result, you are able to understand, with a relative degree of accuracy, what your team is able to deliver – for example, a 6 person team has a capacity to deliver 20 story points per sprint.

The combination of a) more accurate effort estimation and b) a known team capacity allows you to make reasonably accurate time estimations and achieve predictable velocity.

Maintaining Predictable Velocity

Having predictable velocity is extremely useful for both short-term and long-term estimations. It provides a level of consistency that allows you to better understand how long a project will take to deliver. Consistency is the key with velocity; there are variables that will affect project velocity should they change, for example:

• The number of people on the project
• Employee events (vacations, illnesses, other leave, etc.)
• Change in project iterations

Typically, velocity will stabilize after about 3 to 6 iterations, however, if the above variables change, you can expect velocity to change as well. If velocity begins to fluctuate widely, it cannot be accurately used as a predictor for delivery time and will need to be revisited.

Taking the steps necessary to gain predictable velocity allows you to estimate more accurately, deliver more consistently, and ultimately reduce time risks that are all-too-common in software development. While it may not totally eliminate project delays, using velocity to predict future iterations and project timelines is a much more effective method that is based on previous experiences and learning.