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:
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.
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.
Track volatility
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?
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:
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:
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.
Most teams determine their baseline velocity within about three iterations.