All Epic Progress Report

[alteraki]

Hi, I'm looking to create a report of Epic Progress based upon the number of issues that have been completed within the Epic. 

E.g. I have 20 epics, each Epic is linked to (via the "Epic Link" field) various stories and bugs. 

I want a progress report (% Complete) based upon the number of issues complete. 

The solution has to be out of the box, so no Add-on's or Scripts. 

Any ideas?

Thanks in advance

[Somesh Sahoo]

Calculating Epic Progress Percentage in Jira
https://youtu.be/C6vZR0M1ScQ

[Alex Christensen]

There is the Epic Report that's a default report, but it won't give you a % Complete based on the number of issues completed within that Epic. Even so, you could easily figure out % Complete using the information on this report.

EDIT: link to Epic Report docs

Other than that, you could export the Epic's issues to Excel/CSV from the Issue Navigator and use Excel or something similar to create a % Complete report.

[forwardkeys]

I could try to add the % myself to the Epic Report, but I don't want to write the Report from scratch. Do you know by chance if the code is available? It would be much easier to take what is done right one and add some extras

[Alex Christensen]

@Nacho Martinez - you might have better luck answering your question in the Atlassian Developer community, which is separate from this site.

[forwardkeys]

Sure, thanks

[Dmitry Pashkevich]

don't see the Epic Report option in my Jira Software Cloud instance:

[Bryan Musgrave]

Hi @Dmitry Pashkevich, it looks like you're looking at a Kanban board and not a scrum board. Depending on the type of board you are looking at, it will show you different reports. 

[Dmitry Pashkevich]

That's what it was! It doesn't make any sense though. I should be able to report on epic progress regardless of the type of board I have set up for a project, because either way you put story point and/or hour estimates on stories so Jira should be able to generate a burndown chart for the epic.

[Lilian Tao]

burndown chart is for scrum to compare the expected and actual burndown during a sprint period of story points. It's not valid to the kanban board concept. 

[Dmitry Pashkevich]

Kanban does not have sprints, but it has story points. That means you have an epic with, say, 60 points worth of stories. If you knock out, say, 2 stories per day on average (and it's a running average that adjusts every day), how many more days do you need to finish the entire epic? That's what I want answered in the report. Hence even if you don't have sprints, epic burndown is meaninful for Kanban.

[Lilian Tao]

I use Kanban for other purpose so maybe there is a concept mismatch in this conversation. 

When I use Kanban, I focus more on the process being followed and issues handled in correct orders. 

There is a Control Chart to help me checking whether the team has been performing at an expected stable speed. If the answered is yes, I'd leave them work. 

[Dmitry Pashkevich]

> There is a Control Chart to help me checking whether the team has been performing at an expected stable speed. If the answered is yes, I'd leave them work. 

That makes sense, but PMs/Team leads/other stakeholders still need to be able to do strategic planning and answer the question of when a large epic is goind to be in the hands of users and make adjustments along the way.

[Joseph Terranella]

"That makes sense, but PMs/Team leads/other stakeholders still need to be able to do strategic planning and answer the question of when a large epic is goind to be in the hands of users and make adjustments along the way." - this is something that I am consistently asked for by leadership and JIRA resolutely does not make simple or straightforward.

[Tiago Palhoto]

Epics use the concept of velocity to make forecast. You don't have velocity in a kanban board. The Epic Report is similar in concept to the Release report which is based, once again, in velocity. Without velocity, no Epic report, Burdown chart, version report, etc.

[Dmitry Pashkevich]

You may not have velocity in Kanban, as defined by Scrum, but you can still come up with an alternative way to measure velocity, which in plain language is: "how fast does a unit of work get done on average".

[Dmitry Pashkevich]

Back to my original point - whatever the terminology and the process is, a team should be able to answer a question of "Based on how fast we've been moving in the past, when are going to complete this project?"

[Tiago Palhoto]

That you don't measure with points. That is cycle and/or lead time. For that, in the context of Kanban, you have the Control chart available. 

[Dmitry Pashkevich]

The control chart doesn't offer predictions the way an Epic Burndown chart does

[Carlos Palminha]

Independently of whatever methodology you are using (Scrum or Kanban), JIRA allows both of them to have EPICS.

If you use EPICS it is very usefull to know how which EPIC is progressing, meaning that we need to know for each EPIC how much issues are completed or not.

For Product Managers we need a simple report that is valid for KANBAN or SCRUM... track progress by EPIC (even if it is the number of stories completed vs to do)

If JIRA doesn't allow it, I'm thinking in using a different tool to do this!

[Joseph Terranella]

Agreed @Carlos Palminha

As product managers we need a simple way to see how many stories within an Epic have been completed. Basically we need a high level gauge of progress, I understand that stories vary in complexity and time/effort to complete. A high level indicator that 2 of 10 stories in an epic are complete is useful signal.

[Carlos Palminha]

@Joseph Terranella  currently the only way available to do it is using a paid plugin or trying to extract data from JIRA and work in EXCEL

[Tiago Palhoto]

@Joseph Terranella Using a Scrum board, in the backlog section (where you configure your sprints), you have a vertical component that will allow you to see the progress of both your EPICS and/or Versions, precisely in the way you mentioned.

Since a few months ago, the Kanban board started to include this possibility also (as long as you configure the board to have a backlog). NOTE: This progress refers only to the number of items that are part of the Epic vs the number of items that have been completed. This also applies to Versions.

[Tiago Palhoto]

@Dmitry Pashkevich velocity is used to measure the performance of a team within each sprint. That's it. When using kanban boards in JIRA (not the one available as active sprint inside the Scrum board), there's not such thing as measure velocity because it just doesn't make sense.

The Kanban board includes now the concept of backlog, which allows you to see the progress of your epics focused on the number of items completed vs the number of items inside the Epic...but no velocity.

[Derek Thrasher]

@Tiago Palhotothe EPICS / Versions progress on the scrum board that you mentioned are definitely helpful. Although, it would be awesome if this information could be easily shown in either Jira Dashboards or Confluence. The flexibility that would make it more useful for larger teams to be able to understand what is being worked on (similar to a product manager trying to understand high level progress @Joseph Terranella) is to filter out the epics that are not currently in progress or are not prioritized for the next phase of the project.

Are you familiar with any add-ons or other built in functionality that would allow for this view in Jira Dashboards or Confluence?

[Joris Vleminckx]

We have recently started to use the plugin "Agile Docs View", which shows a high-level overview of all epics and their stories (and subtasks), visualizing total points to do and done up to project level. We are using this in a Scrum project, but I guess as long as epics are set up, the same should work for a Kanban project.

[christopher.fry@faa.gov]

https://confluence.atlassian.com/jirasoftwareserver/reporting-939938675.html

Good page to start with for types of reports available by project type and for analysis.  I'm looking at the Single Level Group Report to ID open epics and how many issues are open/closed.