The Velocity indicates the amount of value delivered in each sprint, enabling you to predict the amount of work the team can get done in future sprints. It is useful during your sprint planning meetings, to help you decide how much work you can feasibly commit to. The team's velocity can be estimated based upon the total estimate (for all completed stories) for each recent sprint. This isn't an exact science — looking at several sprints will help you to get a feel for the trend. For each sprint, the Velocity Chart shows the sum of the Estimates for complete and incomplete stories. Estimates can be based on story points, business value, hours, issue count, or any numeric field of your choice.
Importance of velocity
Velocity is a key feedback mechanism for the Team. It helps the team to measure whether process changes it makes are improving its productivity or reducing it. While a Team's velocity will oscillate from Sprint to Sprint, over time, a well-functioning Scrum Team's velocity should steadily trend upward by roughly 10% each Sprint.
It also facilitates very accurate forecasting of how many stories a Team can do in a Sprint. For forecasting purposes the average of the last three Sprint's Velocity should be used. Of course, this means it takes three Sprints of experience for a Team to determine its Velocity accurately, which can sometimes be difficult to explain to impatient stakeholders. Without Velocity, Release Planning is impossible. By knowing Velocity, a Product Owner can figure out how many Sprints it will take the Team to achieve a desired level of functionality that can then be shipped. Depending on the length of the Sprint, the Product owner can fix a date for the release.
The velocity metric is used to reconcile velocity changes - an increase in accepted bugs or chores can explain a dip in velocity. It’s also helpful for managing technical debt: keeping chores at a steady level ensures a focus on keeping your systems and code in peak condition. There are several things you can do with a velocity chart:
Monitor overall project health
The Velocity chart visualizes a number of project trends: iteration velocity (including average velocity), accepted stories by type, and volatility metrics. This makes the Velocity chart an ideal gut check for overall project health.
Understand velocity trends
Accepted points may be low for a particular iteration when there is a large number of bugs, chores, or zero-point stories. The Velocity chart makes these “bug/chore walls” visible by showing iteration velocity dips alongside an increase in accepted bugs.
Volatility is a relative measure of predictability. Frequent velocity peaks and valleys may imply an unpredictable project, whereas smoother iteration-by-iteration velocity suggests a more predictable one.
Why do we need velocity?
Predict how much scope can be delivered by a specific date
Predict a date for a fixed amount of scope to be delivered
Understand our limits while defining the amount of scope we will commit for a sprint
Can an incomplete user story be counted in velocity?
No, you shouldn't. Incomplete is undone. Velocity is about finished, delivered user stories. Here are some reasons why you shouldn't count incomplete user stories:
We can't really figure out how much is ready and how much is not; it will be a wild guess.
We may be led by a false sense of accuracy, due to the use of fractional numbers.
Incomplete means the user story still has no value for the customer.
Determining team velocity
An existing team can determine its velocity by completing the following steps:
Agree on a project iteration (for example, 10 workdays).
Gather a list of what the team completed in the previous 10 work days.
List the work completed in story points to establish their sum and corresponding velocity value.
Plan to deliver this number of story points in the team's first iteration.
Add or remove points in the next iteration based on whether the team completes the targeted number of story points.
Most teams determine their baseline velocity within about three iterations.