It seems to me that we have a lot of epics created in our instance. Related to the issues I can see, I count almost 900 issues of issuetype Epic and the rest are other issuetypes (almost 10000). In total we have almost 10900 issues.
So every 1 out of every 12 issue is an epic. Is this a "normal" ratio?
We use Jira for Software Development and Project Management. Most of the epics (over 70%) are created in projects for Project Management.
Marcel Plomp there's no such thing as normal
That's why I put it between quotes....
It seems logical to use Epics in the way you described, but not when it leads in to epics with only 1 or two issues related to it which is now more or less the case in some of our projects.
I would prefer to use a FixVersion to keep everything related to a project (within a JIRA project) together. Epics can then be used to break down the total project/FixVersion in a few steps/milestones using stories/tasks and subtasks.
Thank you for your reaction.
This is really more about usability. If you've already created this crazy hierarchy system with the epics, then the scrum leader can't use Epics to theme the backlog themself.
I implore you to consider Epic's JUST for theming the backlog. Possibly use New Feature + Issue Linking to achieve the hierarchy, and leave Epics for scrum master's to organize a backlog. Most agile teams only work on one epic at a time, and only plan two or three epics out further than that.
Thank you for your reaction.
I did not know that. In our test environment I encounter a " ...long running script error...." and after some time the scrum board shows up. Just two projects and over 200 epics....
I implore you to consider Epic's JUST for theming the backlog. Possibly use New Feature + Issue Linking to achieve the hierarchy, and leave Epics for scrum master's to organize a backlog.
I agree with you. What I see in general on several levels in JIRA projects, that functionality is not used, not used correctly or people do not know it exists.
We have some work to do...
Epics are not intended for steps or milestones breakdown of a version but the opposite - a theme or initiative or investment or value streams that spans multiple versions/releases. It is another orthogonal to the projects and version way to categorize the stories/issues.
There is no limit how you use it but in the context of Agile/Scrum/SAFe this is the intent.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
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