Velocity is a simple tool that measures the pace at which teams get work done. The sum of the estimates for your artifacts—user stories, backlog, defects—successfully completed in an iteration is your velocity. Measuring velocity helps you set realistic goals while planning for your iterations and releases. Measure velocity using the same units as your features, such as days, hours, or points.
Your iteration and release cycles should be relatively short, so velocity can be measured and validated early on in a project. Team velocity generally becomes stable after three to six iterations. If velocity fluctuates too much for more than one or two iterations, your team may need to re-estimate their release plan.
Velocity works best on the team level. Multiple teams and departments vary widely from each other, so estimating velocity on a higher level than a team often produces inaccurate results. Velocity is most accurate for a stable team. When team members leave, your velocity will change. For example, if 25% of your team moves to another team, decrease your velocity by at least 25%.
Your goal should be optimal velocity, not maximum velocity. If your team is pushed into maximum velocity, often the product suffers. Don't ignore defects, testing, and other quality factors just to show maximum velocity.
Record the total number of estimate units the team believes they can complete in an iteration or release with the Planned Velocity field.
Estimating your first iteration's velocity
Your team's velocity will quickly become evident during the first iteration. If it is overestimated, velocity will decrease until features are removed; if it is underestimated, velocity will increase until features are added. See the Sizing and Estimates Overview for more information.