It helps them measure whether process changes they make are improving their productivity or hurting 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.

The Velocity Chart shows 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.

To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration. It’s just that simple. You also total up the estimates for the tasks finished during the iteration. Both of these measurements are used for iteration planning.

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.

How Do You Read A Velocity Chart?

1. Story points (Y-axis) In the Agile velocity graph, the Y-axis can be used to measure the number of total story points that can be completed in one sprint by a team.
2. Sprints (X-axis) It displays the sprints completed by the team.
3. Estimation (Gray Bar)
4. Completed (Green Bar)

Simply add up the total of story points completed from each sprint, then divide by the number of sprints. So, your average sprint velocity is 96 ÷ 3 = 32.

A successful PI planning event delivers two primary outputs:

• Committed PI objectives – A set of SMART objectives that are created by each team with the business value assigned by the Business Owners.
• Program board – Highlighting the new feature delivery dates, feature dependencies among teams and relevant Milestones.

Both the development team and the product owner write the acceptance criteria. In practice, the user story already contains the acceptance criteria when it enters the Sprint Planning meeting or the acceptance criteria it is defined during the Sprint Planning by the Development Team and the Product Owner.

Story Points represent the effort required to put a PBI (Product Backlog Item) live. Each Story Point represents a normal distribution of time. For example,1 Story Point could represent a range of 4–12 hours, 2 Story Points 10–20 hours, and so on.

Story points enable the team to estimate stories in comparison to other stories, instead of forcing them to determine the time it will take to complete each story. Velocity is then worked out based on how many points the team can complete in each sprint.

4 hours

The story points should not be used to compare people performance or track project progress. The most important reason is that story points are just an estimation of complexity. Sometimes it’s much easier and quicker to finish many simple tasks rather than find out a solution for a complex issue.

Story points estimates can encourage a number of bad behaviours. They can encourage teams to “game the system” by continually increasing their estimates. This seems to increase velocity, but is fake and makes a mockery of the process.

The way we do story point estimation is better than hourly estimates as it is more accurate and has less variation. Story points are therefore faster, better, and cheaper than hours, and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

How do we calculate Story Points?

1. Adjust the Definition of Ready.
2. Use the first story as a benchmark.
3. Compare stories in the first sprint.
4. Determining the implementation effort in time.
5. Starting the sprint.
6. Repeat the process for a few sprints.
7. Compare the complexity to the very first story.