DEV Community

alexey
alexey

Posted on

Why your JIRA Velocity and Sprint Reports most likely calculated incorrectly

Have you ever stopped to analyze what work-items are actually counted toward the velocity? If not, you likely don’t get a reliable the Velocity and Sprint Reports.

Here are four common pitfalls that can seriously distort your velocity — and how my app Multi-team Metrics & Retrospective can help fix them mostly automatically:

  1. Do you remove work-items from a sprint only when they were deprioritized and never when they were incomplete before the sprint was completed (to move them to the next sprint or backlog)? If the answer is no — note that the Sprint Report doesn’t consider removed work-items as uncompleted ones.

  2. Do you always put all the work-items in a sprint? The Sprint Report’s ‘Issues completed outside of this sprint’ metric only takes into account work-items that were completed outside of a sprint AND after that add to a sprint. There is quite a high probability that if you analyze at least a quarter, you will see several work-items resolved outside of a sprint and never added to it.

  3. How do you manage duplicates? It depends on your case, but in general if you keep them outside of a sprint they can be lost, if you add them to the sprint you need to make sure that they eventually don’t have estimates. In enterprises there can be dozes of duplicates.

  4. Don’t you have estimates for overlapping activities — for example, when you estimate a story/feature for a sprint (which generally should take into account all the work needed to deliver the task), and after that estimate a bug created by your or an external team?

And as a bonus, if 3 and 4 items resonate with you, and you conduct retrospectives on issues added to a sprint after it was started, it becomes tedious to distinguish Added Scope worth analyzing from the Added Scope that was included for obvious reasons — expected testing or duplicates. Just as a reminder this type of metric is not a separate metric per se in the Sprint Report. Added Issues are just marked with a ‘*’, you need manually and visually scan work-item by work-item.

All the outlined issues can be resolved by educating people, overseeing the processes, and manually maintaining the order.

Or you can use the app I developed which will let you decrease the pain at least twice. The options the app provides:

  1. Automatically include Removed Scope in Final Scope and Uncompleted Scope (if it wasn’t completed) automatically.

  2. Automatically include Scope Completed Outside in Final Scope and Completed Scope automatically

  3. Automatically exclude from all metrics issues linked as duplicate to issues in the same sprint

  4. Automatically exclude from Added Scope (which is a separate metric) and Re-estimated Scope issues linked as ‘testing discovered’ (the link type is automatically created by the app) to issues in the same sprint.

Part of the Configuration Screen:

Image description

The Dashboard View:

Image description

Image description

Top comments (0)