Velocity is a method of determining how many story points of work a team can commit to in a future sprint based on how many story points of work a team was able to complete in previous sprints. As a safe, general rule, a team should never commit to more story points in a sprint than their average velocity over the 2-4 previous sprints.

But velocity is more than a simple math exercise. There are good velocities. And there are bad velocities. How do you know one from the other? Some characteristics of a good velocity:

Most characteristics of a bad velocity are simply the opposite of a good velocity, such as committing to a number of story points that is only based on the number of team members available during the sprint. Or not factoring the potential complexity of a new series of features as they relate to the amount of time your support organization will need to be ready for the upcoming product release, the amount of time it will take your sales team to learn how to successfully engage potential customers, or by not accounting for the amount of time it may take a training team (or a documentation team) to produce customer-facing material.

Good velocity? Bad velocity? The reality is that most Agile teams consistently live somewhere in-between. Business priorities change. Challenging defects are discovered. Team members get sick. External dependencies can be hard to predict. But a little strategy can go a long way. Your team's velocity is important. So it's equally important to consider your velocity within the context of the work that your team is doing and how it relates to your product's release cycle, your team's relationship to other teams, and so on. For example, a bad idea might be to switch your automated testing platform four times in one calendar year. Every time you change platforms, you may be removing valuable points from your velocity. Another way a little strategy can help is for the product owner to have a good idea of what the product roadmap looks like in relation to the work the team will be asked to do during the upcoming release. For example, if one feature enhancement requires your engineering team to reconfigure the back-end, it's probably better to do that work earlier in the release cycle rather than later.

A good velocity helps your team deliver as much value as possible. A good velocity is what your team wants. Your team will need to work hard to learn what its good velocity looks like. Sometimes the old adage "do less to do more" can help a team understand what their velocity should be. If your team finds itself consistently underperforming its story point commitments (even by a point or two, per sprint), or if your team finds itself consistently finishing stories on the very last day of the sprint, right before the sprint review, then your team should consider committing to fewer story points. Over the next 2-4 sprints, this will lower your team's velocity, but it will also give your team a chance to see if a smaller commitment translates into a more successful sprint.