Velocity Chart shows incorrect commitment/completed values for past sprints

[Elijah Smith]

We have spent a fair bit of time reading documentation for how to properly setup Jira columns for the "Velocity Chart" to work correctly. I know that To-do items should always be the leftmost column, and completed items should always be the rightmost.

It seems like our Velocity Chart data is accurate once the sprint completes, but once we look back to 3 or 4 sprints ago, the data looks like many tickets/work items are just inexplicably missing. The further back, the more tickets are gone. Has anyone else seen or noticed this, or have thoughts as to what might be going on?

Picture for reference. 

Here is what an item that has dropped off looks like. Notice the sprint has been set to None (nothing anyone on my team is knowingly doing).

Thanks in advance for any ideas!

[Vince D'Onofrio · Accepted solution]

This was resolved but I didn't see an answer that worked. For posterity, I had this same issue and resolved it by editing the Scrum Board Filter Query. The query only included issues from the past 30 days so after two sprints (~28 days) all of the reports were skewed and no longer displayed all of the completed tickets.

Go to your board and then to the active sprint. Click the 3 dots in the top right and click "Board settings". Under Filter and Saved Filter, click "Edit Filter Query" and then edit the query to remove any time restraints. 

The reason we had this in the first place is that we were using a Kanban board and didn't want older resolved issues to display. After the switch to Scrum, we used the same filter and which had the unintended side effects.

[Elijah Smith]

Thanks Vince,

This is actually exactly correct. We realized this after the fact that we had strange filter queries set up as well that were time based.. I think this was the root of the problem.

[Trudy Claspill · Accepted solution]

Hello @Elijah Smith 

You posted a "Delete" comment here. Is this still an open question for you, or is that an indication that you figured out the answer for yourself?

[Elijah Smith]

Sorry, this is still an open question. I accidentally posted an answer and couldn't delete it.

[Nic Brough -Adaptavist-]

I deleted the comment for you

[Trudy Claspill]

@Elijah Smith 

Looking at the example issue I see that it shows two previous sprints (202 and 203). What are the start and end dates of those sprints? And what is the date that the issue transitioned to the right-most column of the scrum board?

If the transition date is not within the range of the sprint, then the issues was "completed" outside of a sprint. In that case it should show up in the Committed points for each sprint to which it was assigned, but would not show up in the Completed points of any sprint. The Sprint field will also show as None (+ for history of previous sprints) for a completed issues when issue is "completed" outside the scope of a sprint.

[Elijah Smith]

@Trudy Claspill , here is our current velocity chart. Notice how Sprint 202, which previously had ~30-40 completed issues, now has 0.

Once our issues are in the "completed" column, they sometimes continue to spill over into subsequent sprints as the QA process progresses. Could this cause it to get pulled out of the sprint where it was assigned?

For example, even if it was assigned and completed in Sprint 202, if it is not closed until 203, does that mean it gets pulled from 202 -> 203?

[Elijah Smith]

Based on your response, it sounds like "None" is getting applied due to our QA process spilling over, which probably pulls the tickets out of the actual sprint due to being completed in a different one. Does this sound correct?

[Elijah Smith]

Sprint 202 went from Dec 2 to Dec 22. Here is the history on an individual issue:

Note, "Waiting For QA" is the first status that is in the right-most column. After that, "Testing", "Resolved", and "Closed" all also map to the right-most column.

[Trudy Claspill]

What were the dates for sprint 203?

I would need to do some experimentation because I have not had this particular scenario before.

When an issue moves to the right most column, regardless of which one of multiple statuses in that column it matches, I believe that is when it should be counted as Completed for its current Active sprint and for the Velocity chart.

I'm not entirely clear what happened to this issue on Dec. 22 related to the changing of the Sprint field.

If the issue was in sprint 202 and in the right-most column, and the sprint was then completed, the issue should've been considered "completed" in the Velocity Chart and in the sprint report for sprint 202. It should've "disappeared" from the board. How did it get assigned to another sprint (203) if it was no longer on the board? Or am I incorrect and it did not disappear from the board when sprint 202 was completed?

This is a puzzler.

[Elijah Smith]

Hi Trudy,

Thanks for your responses!
Sprint 203 went from Dec 22 to Jan 12.

It's strange, now that I'm looking at examples from our current tickets, it seems they are behaving as you described they would - if they were in a right-most column status when the sprint was completed, they are NOT assigned to the next sprint, even though they haven't been fully closed yet.

However, looking at the individual ticket example I gave above, this does not seem to be the case. You can see it moved into Sprint 203 on Dec 22 even though it was in TESTING.

I know we are not very consistent and sometimes messy with how we move tickets from one sprint to the next, and even with closing out our sprints. I wonder if we usually have a workflow where we move all open tickets into the NEXT sprint before closing out the current sprint?

I'll watching this process more closely at the completion of our next sprint.

[Trudy Claspill]

If you moved tickets from sprint 202 to sprint 203 before 202 was completed, that should be reflected in the Sprint Burndown for 202. You should see there a notation about the issue being removed from the sprint.

Also look at the Sprint Reports for 202 and 203. That is where you will see notations about what issues where completed within the sprint, in addition to issues that got added to the sprint but where "completed" while they were outside of the sprint.

The fact that the sprint field says "None" tells me that somehow the issue was "completed" outside of any of the sprints to which it got assigned. So do take a look at the Sprint Report and Sprint Burndown for both 202 and 203 to see what you can find there for the particular example issue.

Is it possible that the mapping of statuses to columns was changed? On Dec.22 might the Testing status not have been mapped to the right most column? If that was the case, then when sprint 202 was closed the issue would have been considered incomplete, and may have been moved to the next sprint (203). And in that case it would not be counted in the Completed issues for sprint 202 in the Velocity Chart.

[Elijah Smith]

What I'm seeing in the Sprint Reports, is slowly, over time, all tickets that were completed eventually trickle off and do not show. Tickets that were not completed within the sprint remain. (Mostly these are tickets that were de-prioritzed or put on indefinite hiatus)

We have a QA board that also shares these same statuses. The QA board will move tickets through multiple statuses that all map to "complete" (rightmost) on the Dev board. 

Is it possible that as this QA process is ongoing (updating the status), and the ticket is not currently active in a Sprint, the sprint field gets set to "None"? And when this happens, it gets removed from the Sprint Reports?

That seems like the most logical explanation from my point of view.

[Trudy Claspill]

Do I understand correctly that you have 2 boards for the same issues, and these boards have different status/column mappings? Can you share the column/status mappings for each board?

I would not be surprised if having two boards for the same issues, using all the same statuses but mapped to columns differently, and using sprints in both, could have unexpected impact to your sprint reports.

We often see posts where a team wants to be able to track the "completion" of Development work in a sprint based on an issue going into a Test status, and then also want to be able to track completion of Testing work as the issue works its way through another set of statuses.

In my experience trying to do this for one issue that moves through all the statuses will lead to unexpected reporting results. I think that is what you are experiencing.

If you want to track the work of the two teams as completed separately you should use discrete issues for the two teams' work. When the dev team completes their work on an issue, have that trigger the start of work on a separate issue for the testing effort. Let the two work efforts be tracked in discrete issues independently.

[Elijah Smith]

Dev Board column mapping:

QA board column mapping:

Thanks again for all your help Trudy. Sounds to me like we should be copying the dev ticket into a QA ticket (or something similar?) once it hits QA. Is this the recommended approach / what you have seen?

[Trudy Claspill]

Hello Elijah,

Yes, that is the approach I've seen that is more effective for teams that want to track completion of Development work separately from the QA work. You could use Automation for Jira to automatically create the issue for the QA work when the issue for the Dev work is transitioned to Waiting for QA.

Something else to look at related to that is can you instead set the development issue to "Done" (a green status that also set the Resolution field) rather than a "not-done" status? While the sprint will consider the issue Complete if it is in the last column, there are other built-in reports in Jira that rely on the issue status being in the Done status category, and the Resolution field being set.

If you are going to have two separate issues to track the work, can you simplify your workflow so that they use the same statuses?

Also you have to ask yourself why you need to track the dev and qa work separately? Is the work really "done" if only the development work is done?

[Nic Brough -Adaptavist-]

Are you doing anything with the old sprint's issues?  Archving, moving or deleting for example?