Estimating Velocity

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, for example, 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 stabilize 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.

Estimating your first iteration's velocity

Your team's velocity will quickly become evident during the first iteration. If it's overestimated, velocity will decrease until features are removed; it if's underestimated, velocity will increase until features are added. Generally, plan velocity at 33% of available time per team member. This percentage allows for meetings and administrative activities that take away from actual development time.

Example

Your team has five developers and uses two-week iterations. Five developers times 10 days equals 50 developer days. Plan on 17 ideal days worth of work in the iteration.