Hello,
I set a sprint rows / board pages report with last 10 sprints in a board, and using the [issues created] measure I sometimes have a blank result I frankly don’t understand.
What are the condition which change the value of that measure? I obviously have issues created for the sprints I’m looking to, but some projects show, some don’t.
May it be a workflow issue?
kind regards.
Hi @Mauro_Bennici!
The Issues created shows how many issues are currently assigned to the sprint. If the sprint has been completed, then only issues resolved during that sprint would still be counted to the sprint. And vice versa: if the issue was not resolved during the sprint, even if it was in that sprint, it won’t be counted.
You can read more about the measures used with Sprints.
If you find that there are still problems, please try re-index in Jira and full data re-import in eazyBI. If that does not help, could you please share the exact issues and which sprints they should be part of. Probably it is best to share these details through the support@eazybi.com.
Lauma / support@eazybi.com
I got the problem, the “issues created” measure is also affected by the resolution status, which is - frankly - a little weird, seen that “Issues created” should tell me how many issues were created, not how many were created and resolved in the same sprint.
In the current scenario, I can’t see issues created in closed sprints for projects that have no resolution set.
Re-indexing won’t do, as you probably know there’s no manual indexing in Jira cloud anymore, it’s deprecated.
Thanks anyway.
In addition, sorry, but what’s the point in having an “issue resolved” and an “issue closed” measure, if the “issue closed” shows nothing unless the issues are resolved?
I find really hard to find a sense in it.
There are many Sprint scope measures to track Sprint issue adding and changing, please read about them here https://docs.eazybi.com/eazybijira/data-import/data-from-jira-and-apps/jira-software-custom-fields#JiraSoftwarecustomfields-Sprintscopemeasures.
The ‘Issues closed’ is not related to resolution and are showing also if the issue is not resolved. The default Sprint measures are based on the resolved measures though, and these need to be re-defined with custom calculated measures if used for Sprint scope measuring.
As noted, please contact me directly at support@eazybi.com if you find that some issues or measures are not being imported as expected so we can find if there is a technical issue (even if Jira cannot be re-indexed, sorry for suggesting this for Cloud!).
Lauma / support@eazybi.com
@lauma.cirule,
as you stated before, and as visible in the documentation you linked,
“ If the sprint has been completed, then only issues resolved during that sprint would still be counted to the sprint.”
So “issues closed” for closed sprints is actually linked to resolution, which means that if I use the same measure for two consecutive sprints, one open and one closed, the same measure gives results based on different scenarios.
It’s clear now, and I should have read more docs before, so thanks for the support I don’t think I’ll need to reach support via email.
regards
Hi,
I just wanted to add two things that, probably, would summarise questions discussed in the thread.
1. Resolved vs Closed issues
There are two measures - “Issues resolved” and “Issues closed” - that are calculated differently, but, in some circumstances, could return the same results (depends on how status workflow is defined in Jira).
"Issues resolved” counts all issues in any state that have resolution date and any resolution.
“Issues closed” counts all issues that have entered any of closing statuses (defined in import options), no matter with or without resolution date/resolution.
So, one measure looks explicitly for resolution markers (date/resolution), another - only for status.
If the workflow is configured that issue always has resolution date and resolution when entering in closing status, the measures return the same result.
Though, measure “Issues resolved” is quite important: as in typical use case resolution and resolution date marks completed issues, a lot of standard calculations (also calculations in demo account) assume that issues that should be treated as resolved/completed, all have resolution date and resolution, therefore, measure "Issues resolved” (not “Issues closed”) is used widely to distinct open / resolved issues (for instance, in default "Open issues” measure or calculating remaining estimate in sprint in demo burndown chart).
2. Issues in sprint
Calculating Sprint measures are quite tricky.
In general, in eazyBI, we distinct two kind of metrics: actual (counting issues by their actual values; those measures ends with “… created”, “…resolved”, “…closed") and historical (counting issues by their values at some moment in past based on issue changelog; usually ending with “… history” and “… change”). In case of sprint, there are more: additionally, there are measures that are counted by the values on sprint start and completion moments to fetch sprint scope changes (those are metrics with “… committed” and “…completed”).
Why? Because there is no general answer on a general question “Which issues are in the sprint” because of all sprint scope changes. Therefore, one always has to know, at what moment of sprint one wants to count issues, and then choose the correct measure.
All measures ending with “…. created” always capture values by the current situation (status, resolution, etc). If the issues is in a sprint currently, it would be counted to this measure, if not - won’t be. As soon as the sprint is completed, this measure is not suitable for the sprint issue analysis, as, currently, the issue, unless resolved (see pt.1) during the sprint, is removed from the sprint and either is added to another sprint (and then is counted to that by the measure Issues created) or in the backlog.
Usually, we suggest using some of sprint scope measures to analyse data in completed sprints: for example, “Sprint issues at closing” to get all issues that were in the sprint at the sprint completion moment, or “Sprint issues committed” to get the list of sprint issues when sprint was started; using Sprint issues added or removed to see sprint scope changes during the sprint. “Sprint issues completed” counts issues at closing that had been in any of Done statuses at the sprint completion moment.
Summary
As known, there are different Jira setups, workflows and processes how data are treated in sprints. Not always you can get where you need with default calculations: then they might be modified or used another approach how to get results.
If you would describe the business case what do you want to achieve and the way how you treat completed issues, we could suggest which measures would be most appropriate for your case. You may choose to continue in this thread or, as you would get more specific, contact support@eazybi.com.
Best,
Ilze / support@eazybi.com
@ilze.leite thanks for the explanation, I just wrote an email to support@eazybi.com to detail the case.
kind regards.