Hello:
1. Does anyone know of or does Atlassian have a point of view paper on how and when to create an epic?
What I'm running into here is someone on the team insists on making every piece of work an epic. So one project in Jira presently has 50 epics.
2. They do this because they claim in the Active sprints view it's easier to view the tickets because they are "sorted" by the epic title. For example:
epic 1
ticket 1
ticket 2
ticket 3
epic 2
ticket 5
ticket 6
and so forth...
I'm new, so may not know all the features/capabilities, but is there a better way to manage this than all these epics?
For all intents and purposes, all these epics are just created so that one person's own tickets appear in their nice little section of the Active sprint view and not polluted with other people's tickets.
Hi @Chris -- Welcome to the Atlassian Community!
First thing: I am unclear there are any specific "best practices" around Epics. Each team is different how they manage work, and something that works for my team may not for yours. In general, Epics are larger work items, helping to contain smaller work items. If it helps to use them, do so.
And...the issue your team member is raising doesn't seem related to Epics; it appears to be a visibility issue. If they want to just see their currently assigned work, there is a filter on the backlog and the board to select their avatar icon. Have they tried that yet?
Best regards,
Bill
> Epics are larger work items, helping to contain
> smaller work items. If it helps to use them,
> do so.
Yeah... this has been my philosophy too.
I'd rather not stifle enthusiasm or creativity but I'm also getting to the point where I'm going to tell someone I'm not going to manage 50 epics just because they personally they like the way it looks in the backlog view.
> And...the issue your team member is raising
> doesn't seem related to Epics;
It's not.
I've tried to get them to use filters and labels but they'd rather make their own epic for everything. I was hoping to find some documents which I could forward since they don't seem to want to listen to the rest of the team.
Thanks for your response.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, Chris. One other suggestion: take it to the team.
Scrum teams working together may have alternative ideas, and may be negatively impacted by the one person wanting epics in order to raise visibility. Perhaps there is a root cause to uncover and solve. That seems likely given you describing the team member sees other work as "pollution". Suggestions from the team could be offered as an experiment to try, learning what improves (or not).
Best regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey Bill:
> take it to the team.
Absolutely!
That's the plan...
We're a big Design Thinking company and we're in the ideate stage right now on future use.
Separately, I'm on the side collecting facts and best practices to map to the ideas when we start developing a roadmap and a process for usage, adoption, and sophistication.
But one thing I will not support is someone going rogue and making the rest of the team conform to them. Hence why I posted here for additional feedback from people who have no skin in the game otherwise.
Thanks for the feedback!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Often someone disagreeing or "going rogue" knows or believes something the rest of the team does not. And, occasionally a person is just argumentative for other reasons.
The team discussion will uncover that hidden knowledge so all can benefit from their shared contribution. For the other path, that sounds like a staff management issue for leadership to help resolve.
Best wishes!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Chris ! Glad to have you here in our community!
In addition to the answers that's already given so far, we have a best practices guide for epics and stories here: https://www.atlassian.com/software/jira/guides/getting-started/best-practices#best-practices-for-epics-and-stories-in-jira
I'm a product manager in the JSW onboarding team, where we aim to make the experience better for our new users. If you have any feedback on the experience, or on the guide above, feel free to email me at echan@atlassian.com :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Chris ,
welcome!!
You might find this article interesting to read.
Bill is correct in saying that what works for 1 team, might not work for another, but using epics as containers for users does seem a bit odd.
You could use a board with filter "only my issues", or even use assignee to base your swimlanes on, if you want to separate them clearly.
Hope this helps!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
+1... thanks for the link!
> You could use a board with filter "only my issues",
> or even use assignee to base your swimlanes on,
> if you want to separate them clearly.
Indeed. Tried already to communicate that. Was hoping to find documents to pass along since this is a discussion that breaks down between me and the person creating all the epics. Thanks for the link!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.