Cross-team velocity chart for Scrum boards

Owned by Vasyl Krokha
Last updated: Nov 07, 2024 by Tetiana Kamenkova (Deactivated)
4 min read

Team • Cross-team Velocity Chart for Scrum boards answers the following questions:

  • What is the productivity trend for a particular team?

  • What is the productivity trend for a set of teams?

  • How does a team deliver on its sprint commitment?

  • How does a set of teams deliver on its sprint commitment?

  • To what extent sprint’s scope is subject to change?

Use it as one of the gadgets on your Jira Dashboard.

Basic configuration

Let’s analyze the velocity of a team named “Alpha.” This team follows the Scrum process and uses story points (SPs) to estimate and track their progress.

Here is the configuration of the gadget. First, you need to specify the Scrum board, and you are ready to start.

The Analysis of Velocity Chart

Analysis of Sprint 1

Initial commitment

We see that the team committed to delivering 32 story points (SPs) at the Sprint Planning meeting. This metric reflects the total scope added to the sprint before hitting the “Start Sprint” button on the Jira Scrum board.

Final commitment

The "Final commitment" metric reflects any changes to an active sprint's scope - it means that if any work was added or removed, or an issue's estimate was changed after the sprint’s start event, these changes would be reflected in the Final commitment.
The final commitment is 36 SPs, more than a team committed to Sprint Planning (32 SPs). The chart (Estimation change metric) shows this happened because the work estimate increased.
By checking details about sprint issues (click anywhere on the area of Sprint 1), we find out that user stories' #4 and #6 estimate has been increased by 2 SPs each:

Added work

As we see, no issues (user stories, tasks, bugs, etc.) were added during the sprint.

Removed work

No work items were removed during the sprint.

Estimation change

The estimation change is 4 SPs as the estimate has increased during the sprint by 2 SPs for user stories #4 and #6.

Not completed work

User story #6 (estimated at 5 SPs) hasn’t been completed during the sprint - that’s what this metric reflects.

Completed work (initial)

On Sprint Planning, the team committed to delivering 32 SPs but hasn’t completed user story #6, which was estimated as 3 SPs on the planning. So, team Alpha managed to deliver 29 SPs.

Completed work

This metric reflects any sprint scope changes due to added work, removed work, or estimation changes that may happen during a sprint. That’s what we see on the chart:

  • User Story #4 estimate was increased by 2 SPs

  • User Story #6 wasn’t completed, and its estimate increased by 2 SPs

Here are the good equations that help to understand metrics a little bit better (plus do a cross-check):

  1. Final commitment = Initial commitment + Added work - Removed work + Estimation change

Explanation: “Initial commitment” plus all types of scope adjustments lead to the “Final commitment.”

  1. Final commitment = Completed work + Not completed work

Explanation - final commitment is the amount of work by the end of the sprint, which consists of completed and not completed work by the end of the sprint.

Analysis of Sprint 2

“Initial commitment” and “Final commitment” metrics are equal, with 31 SPs. However, we see that 5 SPs of work have been added, and 5 SPs have been removed. That shows that team Alpha is well acquainted with the velocity concept, and when the scope of the sprint increases by 5 SPs, then some work should be removed from the sprint to meet the commitment.

Note that in the list of issues for Sprint 2, we see that bugs #5 and #4 have been added during the sprint (marked with an asterisk). Bug #3 and user story #7 were removed.