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)
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)
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.
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"?
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 :(
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:
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)
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.
I think you're missing my point. If another team takes over and moves stuff into their sprints, then the sprint reports are accurate. The reports and burndowns SHOULD shrink, because the sprint IS shrinking.
Again, your reports can only work on filters that include your issues, and you are deliberately moving them out of the list.
Either you need to change your behaviour (why are things changing sprints?) or think through historical reporting more carefully.
No, I totally get your point and it is valid. The sprint of the prior team should shrink UNLESS it was already completed. There is work that has been done (logged) during a former active sprint.
All it needs is a small change to the code that is used for generating the reports to include all issues that have been in the closed sprint even though they are no longer in the sprint scope (BUT THEY WERE!).
This is quite similar to the historic view of the status and the estimates.
This issue has been brought up my many people in our company and we are one of the top 500 fastest growing companies in the world - should mean we have some bright people sitting here...
Problem is, that would confuse the heck out of most users - why is a sprint report suddenly showing a load of work that is not in the sprint? I work with around 120 Agile teams, and not one of them have ever asked for anything like this. They *have* asked for historical reporting. But not hacking the current reports, because that would mean they don't know where they are any more.
I really think historical and current reporting are separate things. Most people need to see current reporting, and that's what Jira and GH do here.
From what you describe, I am really not sure if you understand me right: I do not want to show something is not in the sprint scope anymore. I just want to track it as a scope change, because it was part of the sprint, then later on, removed.
why is a sprint report suddenly showing a load of work that is not in the sprint?
This would not be the case. I am talking about that the issue has been in the sprint (and it still is! -> the Sprint field stores all the closed sprints!).
If I am looking at any report of a past sprint, it should not change over time. These reports need to be persistent. After all: it is a historic view of data (what happened during "Team 1 - Sprint 15"?). If this report shows something different next week even thought the sprint has already been completed, it is useless!
I'm completely lost now. A sprint reports the sprint, as it is. You remove stuff, yet expect it to remain in the sprint. Now you're claiming you don't remove them, but you still are?
If an issue WAS in a sprint, and you remove it, then the "current" report cannot report on it because it's not there any more. There is no "historical" report (yet) and that's what you need, as you say "if I am looking at any report of a past sprint, it should not change" - that should be done with a historical report, OR by you NOT editing the sprint after it's finished.
I still think you are conflating current and historical reporting. They are separate things.
Fabian, regarding #2 - I think I know what you mean - do you mean that you had an issue in a sprint, and work was done on it, but it was later removed from the sprint? If so, have you thought about leaving it in the sprint as partial work (and closing it), and creating a new issue in another sprint that covers the rest of the work (or re-do of the work)? That way the old work will still be logged against the sprint it was completed in, and the new issue will cover the logs on all the work done in its current sprint.
No, I am not even talking about removing it from the sprint.
Let's say "Team A - Sprint 3" worked on the issue, but could not finish it. When the issue was added to the sprint and the amount of time worked on it as well as the estimates will appear in the reports for "Team A - Sprint 3".
Now, they were not able to finish it, and another team puts the issue in their sprint ("Team B - Sprint 4"). Since each team has their own backlog, the issue will now COMPLETELY disappear from all previous sprint reports!
This means, it will look like Team A never worked on it and their burndowns / sprint committment will still continue to shrink long after the corresponding sprints have been completed. This is altering historical data if you ask me and a complete no-go for reporting purposes...
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.
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.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Can a new-to-agile team survive and thrive in a non-agile culture? If so, what advice would you give to those trying to be agile in a non-agile culture? What's the key(s) to success? Share your thoug...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs