How to exclude cancelled items from a sprint report?

[Greg Mueller]

Why would anyone consider them completed or want a report including them with issues actually worked and completed?

As a workaround, I tried changing the story points on cancelled issues to 0, but this still doesnt reflect in the sprint reports. 

[Trudy Claspill]

Hello @Greg Mueller 

In what way exactly, and for which specific report, is changing the story points to 0 not getting you the desired result?

[Greg Mueller]

Any report that shows story points shows the initial point assignment in the totals.  The sprint has already closed. 

[Trudy Claspill]

The initial story points total at the beginning of a sprint will not be changed by changing the story point values during the sprint.

If you want to excluded issues that end up being Cancelled and have that affect the historically recorded initial story points for a sprint, then you will need to change the filter for the board to excluded Cancelled issues from the board entirely.

[Greg Mueller]

It looks like there is a record of story points I have changed during the sprint.  Isn't that what those arrows are indicating?   The filter should meet my goal, thank you.  But what is best  practice for handling cancelled issues?  Is it that, or to leave them in the reports?

[Trudy Claspill]

Yes, there is a record in the sprint for changes of scope. Changes of scope include changes of story point values (or time, if you are using time for you estimation and tracking), adding issues, and removing issues.

But changing the scope during the sprint does not change the scope documented at the beginning of the sprint.

If you change the points on Cancelled issues to 0, that will be reported as a reduction in the burndown chart over time, but does not change the starting point of the chart, nor the Committed value in the Velocity chart.

If the only change in scope you had was to set a Cancelled issue from 5 points to 0 points, and if you completed all the other issues in your sprint without changing the scope, then your Completed points would be 5 less than your Committed points. 

I don't have a specific suggestion on the best way to handle Cancelled issues, or other scope changes. I think it depends on how your team/company interprets the Velocity, Burndown, and other available reports when scope change impacts them. I'm sure there is.a variety of information available on the internet on the topic of best practices related to Cancelled issues.

[Greg Mueller]

So, once a sprint has begun, the start date and number of points (commitment) are locked in stone forever?  Why isnt there a mechanism to correct for mistakes, like forgetting to hit the start button?  

[Trudy Claspill]

Yes, the Start Date and Committed points are locked to when you actually start the sprint.

I can't speak to why Atlassian didn't provide the mechanism you mention.

[Greg Mueller]

Thank you.  

Does deleting an issue altogether behave any differently than reducing the points?  I would assume that the original committed points wont change, but the new sprint scope (both completed and estimated) would decrease.  Changing the story points to 0 would have the same effect on sprint scope as deleting the ticket?  

[Trudy Claspill]

Do you mean truly deleting the issue, as in it ceases to exist entirely in Jira? I strongly advise against deleting issues as a rule, because they become unrecoverable. They don't go to a trash bin from which they can be recovered, unless you have a third party app that adds such functionality. They are gone forever once deleted.

An alternative to deleting them would be to change the board filter to exclude issues that end up in the Cancelled status.

If you do delete the issue, that would have the same effect on sprint data and setting it to a status/resolution that is not within the scope of the board's filter. From the perspective of the board the issue ceases to exist and never did exist. The board and board related reports will change so that data related to that issue is no longer included anywhere. Jira functionality updates the starting scope of the sprint so that it is as if the issue was never part of the sprint. It does not get added to the Scope Change information. In fact, any entries related to it that are already in the Scope Change information are also removed.

[Greg Mueller]

Great!  In the case of a duplicate or accidental ticket, that seems the best course of action. Everything else distorts the truth of the sprint. Isn't that the best way in that circumstance?

Also, when using the filter method... does this also treat them (in the report) as if they never existed in the sprint? 

[Trudy Claspill]

The Sprint related reports under the Reports menu appear to reflect that the issue was never part of the sprint at all. All traces of it are removed.

However I did observe that the Sprint field in the issue itself still retains the Sprint value. If you executed a search for all issues in the sprint then the "hidden" issue would be revealed. If you wanted to completely remove the association of the issue to the sprint you would have to modify the Sprint field in that issue. The issue could reappear in the sprint if the status was changed again and the Sprint field had not been updated. On the other hand, if the Sprint field was updated to remove the sprint, and the issue status changed, then the issue would return to the backlog rather than reappearing in the sprint.

Note that I am learning all this through experimentation. I am not a developer of the product and offer no guarantees that I have discovered all the nuances of the functionality.

[Greg Mueller]

To be clear you are referring to behavior when changing the filter?  THank you, that is very helpful and makes sense.   I think I will do that as it serves the purpose of accurate reports.  It's ok if people can still find it, probably a good thing. 

[Trudy Claspill]

Yes, in my last response I was referring specifically to the behaviour when changing the filter.

[Alexey Pavlenko _App Developer_]

Hi @Greg Mueller ,

I have read through this thread and have experienced the same problem in the past. This was one of the reasons why I developed the app - Multi-team Scrum Metrics & Retrospective. It addresses all your concerns. You don't need to change a board filter to exclude 'duplicates'; the app has an option to exclude them. The same applies to 'Cancelled' status. You can simply write any custom JQL, and the app will render sprint data as bars based on that.

Best regards,
Alexey