nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Velocity report

Mike Oragwa

I have observed inconsistency in data with respect to actual committed and completed story points on the velocity report across various sprints. Is this a bug or are there specific considerations to be made before starting and ending a sprint?

For example, the team made a commitment of over 50 story points during the start of a sprint and completed most of the stories, but the velocity report shows 0 for the commitment and 3 for the completed stories. (See attached picture). Screenshot 2024-05-30 at 13.08.21.png

Accepted answers

All comments

Bill Sheboy

Hi @Mike Oragwa

That report, and other sprint reporting, is based upon when the sprint started and ended.

If the user stories were not in the sprint, or not yet sized with story points, those values would not be included in the "commitment" on the report. Similarly, if the sizing changed after the sprint completed, the values would not be reflected.

To check this, find an issue you believe should have been counted on the report, and review the issue history to check:

when was the issue added to the sprint, relative to the sprint start and end
when was the issue field story points set / changed

Kind regards,
Bill

Danut M _StonikByte_

Hi @Mike Oragwa,

Try the following:

- check to see if the issues were added to sprint after the sprint started

- check if the story points were added to issues after the sprint was started

- check if the story points were added to issues after the sprint was closed

- check if the issues were resolved before the sprint start

Also, a better alternative to this Jira report would be the Team Velocity gadget offered by our Great Gadgets app. It is more advanced, works with any type of estimates, can count sub-tasks, offers additional metrics (like scope change, added or removed) and a Data tab with a detailed info about the issues from each sprint. It works differently than Jira report, so it might display correct data.

You could start with a 1-month free trial. If you have any questions, feel fee to contact us at support@stonikbyte.com.

Hope this helps.

Danut.

Mike Oragwa

Thanks @Danut M _StonikByte_ .

Yes, we always ensure the checks you highlighted but the reports always give different data. This is the same for all our scrum teams (over 10 of them).

Mike Oragwa

Thanks @Bill Sheboy .

We always ensure that all stories and tasks have story points, before starting a new sprint, and nothing changes till the end of the sprint.

For example: A team with an average velocity of 50 story points.

In the event that some stories were not completed (10 story points) by the end of the sprint (let's say sprint 5), we move them to a new sprint (Let's say sprint 6) at the point of completing the sprint (usually prompted by jira).

These incomplete stories (10 story points) from sprint 5 are re-estimated in sprint 6 if necessary (especially if a substantial amount of work has been done). Assuming the effort required for completion is 5 story points, new stories are added to sprint 6 in line with the team's average velocity. (Additional 45 story points).

Upon estimations, the new sprint is then started with a total of 50 story points (5 + 45), nothing changes until the end of the sprint and all stories get completed by the end of the sprint.

The expected velocity report is as follows:

Sprint 5: Commitment : 50 , Completed : 40

Sprint 6: Commitment : 50 , Completed : 50

Bill Sheboy

Based on the image you posted, you are using a Jira Cloud, Team-managed Project (TMP) with a Scrum board. Is that correct?

I recommend pausing to review the sprint burndown report for both sprints. That will provide a detailed accounting of what Jira detected as the commitment and changes in scope (i.e., stories in sprint and changes in story sizing). You may need to compare individual story histories if it appears the sizing change impacted the report in an unexpected way.

Additionally, I recommend for the incomplete stories to not resize them at all, and not to move them to the next sprint while the sprint is still in progress. My thinking is, the team...

refined and sized stories based on what they knew at a point in time,
planned a sprint based on their perceived capacity and goal, and
"stuff" can happen that impacts both,
but such disruptions should be exceptions.

If the team left the incomplete stories to carry-over and discussed what they observed / learned at the retro, carry-over becomes less frequent and re-sizing is not needed.

Mike Oragwa

Thank you, but I don't think you understand the scenario.

I mentioned earlier that no changes happen during the sprint. I also mentioned that the incomplete stories are moved to the next sprint upon completion of the sprint, not while it's still in progress. (Usually, Jira will prompt that, when you want to complete a sprint).

Furthermore, I mentioned that the re-estimation happens if a substantial amount of work has been done. This in my view, is not out of place, because the effort required to complete the work has reduced.

Generally speaking, a team may not always complete their stories for many reasons, even when the capacity of the team is known, and the ideal thing to do is to move the outstanding deliverables to the next sprint.

Vasyl Krokha _Broken Build_

Hi, @Mike Oragwa

As mentioned above, the sprint has its specifics, and it’s important to have an estimated scope before the sprint start date and complete it before the sprint completion date.

To investigate what’s happened, you can try (for free) the Velocity Chart Gadget app because it shows much more than Jira:

If the issues are not counted as Initial Commitment (they equal the Jira grey bar) and appear in Final Commitment (1), you added them after the sprint date. They will also be counted in the Added work metric (2).

You will see this in the Estimation change metric if you added issues before the sprint started but estimated them after (3).

To find all these discoveries, you can click on specific sprints and needed metrics to see the issue list in sprint details:

Then you can investigate, issue by issue, why it isn’t counted as completed. It can also be because someone has changed the sprint start date.

I hope you find my answer helpful!

Olexiy

Mike Oragwa

Thanks @Vasyl Krokha _Broken Build_ .

The tool seems not to be available for customers anymore.

Vasyl Krokha _Broken Build_

@Mike Oragwa What do you mean? Do you have it installed in your Jira?

I've changed the link (there was a data center option selected by default, and I changed it to a general link). Could you try one more time?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud