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; } } }

[Greenhopper] Scope changes are inconsistent - is this expected?

Fabian Meier1

Usecase #1

If you use Convert to Issue on a sub-task, the issue is removed from the current sprint and completely disappears from all reports (e.g. sprint report, burndown report)

Usecase #2

If you change an issue's metadata so that it no longer matches the rapidboard's filter query, it completely disappears from all reports (e.g. sprint report, burndown report)

(I have filed a GH Bug: https://jira.atlassian.com/browse/GHS-8457)

Accepted answers

All comments

Nic Brough -Adaptavist-

Case 1:

I suspect it might be valid - if you're converting sub-tasks to issues, they probably need to go back to planning for another sprint. I think that's mildly arguable - in some cases, it's appropriate to leave it in the same sprint.

Case 2:

Absolutely correct. A filter says "show me issues that match these criteria". If you move something outside a filter's criteria by changing it's data, then it MUST be removed from the filter. Otherwise it's utter nonesense. How would you imagine telling Jira "find me stuff that's green plus those seven random ones I repainted but didn't tell you about"?

Fabian Meier1

Sorry, but I do not agree with your explanations:

Re: Case 1

I agree that the issue could just be placed in the currently sprint of the parent. However, since this is not happening, the sprint scope is changed but this change is not reflected in the reports (e.g. sprint / burndown). This confuses our SCRUM managers.

Re: Case 2

While it of course makes sense that the issue disappears from the search result, the fact that it was planned and added to the sprint scope, then removed later on, needs to be reflected in the sprint report! Imagine Team A worked on the issue, after their sprint Team B takes over and the issues disappears from all sprint reports of Team A. Even the burndowns of Team A shrink!

You cannot have reports that change over time. That's insane

Nic Brough -Adaptavist-

Case 1 - as I said, it's arguable whether an issue should keep or lose it's sprint field. Most places I've worked would re-plan issues that are moved out from under another, so it's correct there. I think the second half of your question here is about case 2.

Case 2 - I'm really sorry, but I have to say that's nonesense. The point here is:

A filter should return the issues you are searching for
A filter should NOT return issues you are NOT searching for
You are asking for a filter to SHOW you issues you are NOT searching for. Which is a) undefineable because Jira can't know what you aren't looking for or how to pick the ones that you want to include despite having told it not to include them and b) makes filters a nonsense.

However, I do see the problem. You are asking the sprint reports to report on historical states. That's a bit rubbish really - a sprint report should show you the current status of the sprint, not what it was in the past. But when you add "historical" to the defition, it makes more sense. It sounds like you need a sprint report that, instead of "sprint = X", it says "sprint = X or sprint was X at some point since the beginning of sprint X". I think that's going to need a bit of code, and a lot of explaining to your users as to why the report is showing stuff that's not currently in the sprint (I'd definitely keep them very separate from the current sprint reports - even if it's just the title of them)

Fabian Meier1

Ehm and sprint reports do no show you a view of the historical states of the issues already? How about their status, or their estimates?

I understand where you are coming from, but most of our users describe the current reports as rubbish due to this single reason:

Imagine Team A worked on the issue, after their sprint Team B takes over and the issues disappears from all sprint reports of Team A. Even the burndowns of Team A shrink!

If you want to argue that a report can change over time after the sprint was completed and that work that has actually been done during a particular sprint should not appear in the report of that particular sprint, then I have to say: I, and most of our managers as well as our QM department, disagree.

Mark DeMichele

Fabian,

I think the problem is that at the end of the day, the reports are controlled by the filter assigned to the board and even though that doesn't fit our use case, I think you may be stuck with it. At least that's my take on it as an innocent bystander (programmer).

I could be wrong, but it seems to me that the "historical" aspect of these reports are first driven by a list of issues assigned to the sprint that also fit in the current filter. I wonder if the reports should not consider the filter and just consider the fact that these issues have once been assigned to the sprint. It seems that greenhopper keeps track of this since I noticed that user stories that move from sprint to sprint because the don't get completed seem to have all those sprints associated with it after the fact.

Fabian Meier1

That's the most accurate description of my problem

I do not understand why the fitler is being considered for the reports rather than the "Sprint" customfield that stores all the past sprints of an issue.

I am a programmer as well, and I know it is possible without a lot of code changes since you can write a JQL statement today, that returns the list of issues that were in a particular sprint.