How does Issues Resolved Measure work for more than one Resolution?

Hello EazyBI support team,

How does the “Issues Resolved” Measure work when there are more than one Resolution and Resolution date set in a workflow ?
For e.g. See the below workflow.

To do -> In Progress -> Ready to Merge (Resolution updated as “Ready to Merge”) -> Resolved (Resolution updated as either Resolved or Deployed)

Will it provide all the Resolved issues that have resolution and resolution date set in the last “Resolved” status instead of the “Ready to Merge” status ? And On the Time dimension will it be grouped by latest issue resolution dates ?

Thank you.

Hi @Karthiga_Sethuraj

eazyBI would import the resolution date which is being returned by Jira for particular issue. And that is just one resolution date per issue.
And then Issues resolved measure is tied to this resolution date.

In your case, we would recommend creating a new calculated measure to count issues that were transitioned to a specific status.
But first, you should ensure that Issue change history is selected for import.
Try this formula to find issues that were transitioned to “Ready to Merge” status:

[Measures].[Transitions to status issues count],
[Transition Status].[Ready to Merge]

And similar you can create to find issues that were sent to “Resolved” status:

Martins / eazyBI support

1 Like

Thank you for the reply. Can we query by the Resolved date (JIRA’s system field).

For the custom fields I am able to use the Custom field measure like “Issues with Ready to Merge date” . I store the resolution dates when transition to “Ready to merge” in a custom field “Ready to Merge date”.


In that case, you should be able to create a report by selecting the measure “Issues with ready to merge data” together with “Time” dimension.

Martins / eazyBI team

1 Like

Thank you Martins for the quick response!

@martins.vanags hope you are doing well.
I had a follow up question in this thread.
Consider the below workflow:
To do → In Progress → Resolved (Resolution updated as “Resolved") → Merged → Done (Resolution updated as “Done”)

  • Say ticket A got resolved with a resolution in last week of a biweekly sprint (say Sprint 1). So it will accounted for the velocity of Sprint 1.
  • The same ticket A is updated as “Done” along with a resolution on the first week of next Sprint 2.
    Now ticket A would be accounted for Sprint 2’s velocity as well.
    So this would result in duplicate reporting of the same ticket in two sprint’s velocity. Correct me if I’m wrong.
    Does this mean we should have only one end status with one Resolution set in a workflow to avoid dups in Sprint velocity calculation.
    Thanks in advance for your inputs.


You are right with your assumption.
In your described case, the velocity chart for both sprints would include such a ticket with two resolutions in two different sprints.
I would recommend using just one end status with a resolution.
Actually, the measure “Story points resolved” would appear only for the last sprint where the issue was resolved. But “Sprint story points completed” would show values for both sprints.

Martins / eazyBI support


Hello Martin,
Where do I get the explanation of fields like Story points resolved and sprint story points resolved. I like your explanation, I also want to see the data dictionary.

Try finding our documentation page about story point predefined measures:

Martins / eazyBI