...
|
...
|
...
| |
Team • Cross-team Velocity Chart for Scrum boards answers the following questions:
Use it as one of the gadgets on your Jira Dashboard. |
...
/wiki/spaces/VEL/pages/3124690945 article gives the essential information on how to configure and read Team Velocity Chart.
Refer How to install the app and gadgets article if you don’t know how to add “Team Velocity Chart” gadget to your Jira Dashboard.
Best practices
Setting up your Team Velocity Chart
...
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
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Here are the good equations that help to understand metrics a little bit better (plus do a cross-check):
Explanation: “Initial commitment” plus all types of scope adjustments lead to the “Final commitment.”
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.
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
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. |