There are some simple guidelines for estimating initial velocity of your scrum team prior to completing the first iteration (see FAQ’s below), but after that point you should use proven, historical measures for planning features. Within a short time, velocity typically stabilizes and provides a tremendous basis for improving the accuracy and reliability of both near-term and longer-term planning of your agile projects. Agile delivery cycles are very small so velocity quickly emerges and can be validated very early in a project and then relied upon to improve project predictability.
Is velocity really that simple?
Yes, it is. Do not try not to overcomplicate velocity – it really is a straight forward concept and a great deal of its value lies in its inherent simplicity. Many managers and teams new to agile methods tend to overanalyze the concept of velocity and heap too much complexity around it. After a few months of agile project experience, most people will experience an “ah ha” moment with velocity, shedding any baggage they’ve associated with it and appreciating its simplicity and intrinsic value.
Velocity charts
Along with release and iteration burndown charts, measuring the velocity of agile teams has proven to provide tremendous insight/visibility into project progress and status. A velocity chart shows the sum of estimates of the work delivered across all iterations. Typically, velocity will stabilize through the life of a project unless the project team make-up varies widely or the length of the iteration changes. As such, velocity can be used for future planning purposes. While typically reliable for a couple iterations out, if you accept that priorities, goals, and teams may change over time and therefore the confidence level of an iteration far in the future, velocity can be used to plan releases much further into the future.
Initially, teams new to agile software development should just dive in and select an initial velocity using available guidelines and information. Very quickly (as fast as the next iteration), velocity can be measured and adjusted. Velocity, along with granular features (e.g., user stories, backlog, requirements, etc.) and high-level and/or relative estimation (in terms of points, ideal days, or even hours), tremendously simplifies and accelerates the whole project planning, estimation, status tracking, and reporting process.
Agile scrum FAQ’s
How is velocity of an agile development team calculated?
Velocity is the sum of the estimates of delivered (i.e., accepted) features per iteration.
What unit is used to measure velocity?
Velocity is measured in the same units as feature estimates, whether this is story points, days, ideal days, or hours that the scrum team delivers – all of which are considered acceptable.
How is the first iteration’s velocity estimated?
For an agile team’s first iteration, a general guideline is to plan initial velocity at one-third of available time. If you’re estimating ideal programmer time then this accounts for meetings, email, design, documentation, rework, collaboration, research, etc. As an example, with six programmers and two-week iterations, a total of 60 programmer-days (6 programmers x10 days) are available. In this situation, a good start would be to plan 20 ideal days worth of work in the iteration. If using actual time, include enough of a buffer to account for standard project 1) overhead and 2) estimation inaccuracy. Also, remember that velocity will quickly emerge during the first iteration. If underestimated, velocity in the first iteration will rise as new features are included; and if overestimated, velocity will decrease as features are removed. For the second iteration, the scrum team should then use the first iteration as a guideline.
Do meetings, phone calls, email get included in velocity?
This depends on whether these items are estimated and included in the iteration plans. They are typically not included – a goal of velocity is relative consistency and predictability across iterations in terms of an agile team’s ability to deliver.
Should velocity be accumulated across all agile development teams or projects?
Velocity is very much a localized measure. In addition to different team members with different team “personalities”, projects typically possess unique characteristics in terms of estimating techniques, detail process, technology, customer involvement, etc. As a result, this can make organization-wide analysis very inaccurate. If, on the other hand, all of your teams estimate exactly the same, develop exactly the same, test exactly the same, and track exactly the same, then by all means, maybe you are the exception.
What if velocity fluctuates?
Velocity will typically fluctuate within a reasonable range, which is perfectly fine. If velocity fluctuates widely for more than one or two iterations, the scrum team may need to re-estimate and/or renegotiate the release plan.
How long does it take for velocity to stabilize?
For most agile development teams velocity will typically stabilize between 3 and 6 iterations.
How do I estimate future iterations?
Future iterations use the proven history of the team to determine how much the team can do. Therefore, velocity is the right measure to use for planning future iterations.
How do I estimate velocity if project teams change size?
Velocity relies on team consistency in order to be most valuable. If your agile team changes, use common sense in planning future iterations. If 20% of your team is unavailable for a couple iterations, then reduce planned velocity by 20% or so. If this includes a couple of key players, in particular a customer that may be less available, then reduce the estimate a little more. It will only take the length of the next iteration to understand better what the team can deliver and thus their new velocity.
Does maximum velocity mean maximum productivity?
Absolutely not. In an attempt to maximize velocity, a team may in fact achieve the opposite. If asked to maximize velocity, a team may skimp on unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimize refactoring, or many other key benefits of the various agile development practices. While potentially offering short-term improvement (if you can call it that), there will be a negative long-term impact. The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.
How do we measure velocity if our iteration lengths change?
You don’t, at least not nearly as easily. Velocity’s value comes from its inherent consistency. A fixed iteration length helps drive the reliable rhythm of a project. Without this rhythm, you are constantly revising, re-estimating, and reconciling, and the ability to predict out in the future is minimized due to inconsistent results. If, on the other hand, almost everyone is going to be out a week for the holidays or a couple days for company-wide meetings, then by all means simply use common sense and adapt iteration dates or velocity accordingly. Like most agile practices, these are guidelines, not rules.
