I know an Epic should come to an eventual end, however, on the Backlog we can filter by Epic which is usefull for sprint planning. When trying to figure out what we should do next it helps to break things down by part/section. So I'm tempted to use 5 "special" epics to breakdown the parts of our app:
5. Pilot Documents
Would you recommend against this?
Hi @Jasen Barnes,
Who are we to advise against a guy with inside knowledge of the app he and his team are going to build ;-).
If the 5 epics you listed are the 5 main parts of your app, you are probably on the best possible track. You will be able to organise and track all work related to these areas in an easy, standardised way.
If these parts or areas are really really large, and 'reaching the end' sometime sooner or later, it might indeed make sense to create more epics. Consider whether it makes sense to break the areas down further into meaningful sub-areas or not, that also translate into tangible business requirements or value. If so, don't be afraid to add another epic or two. They easily scale.
Suppose you still want to group your epics along the areas you mention, you can use Epic Colors to visually align multiple epics that belong together.
And also what @Nic Brough [Adaptavist] is saying :-)
While I don't see a big issue with this other than if you pick too broad a category for your EPIC it's hard to asses DONEness. I like to use Epics for the following: 1) end-user visible features or 2) large non-user visible functionality (e.g. : back-end, app control logic, refactoring, etc...). The former gives you a nice mapping to your feature list and customers and helps you communicate with your sales, mktg and user community in terms of real status. The latter, I like for keeping track of technical debt and work that is in the critical path of user features. The biggest advice I'd have is to set yourself some guidelines on the sizing; for example: "... if I have 5 similar themed stories with size > 9, I'm going to put them into an EPIC..." doing this will help you (and your team) with future work (size) estimation.
Nope, it's fine. As long as your users understand never-ending epics (which your explanation above probably covers fine), it's not going to cause you many problems.
It is what components are for really, but if they're not doing the job, then Epics should be ok. It's not ideal, there are cases where you may run into quirks you'll need to think about, but they're not show-stoppers. For example
I see no problem with this. As Nic already stated, this is what a component is for, but Epics are far easier to select during sprint planning to keep things organized. I've implemented the same strategy in the past, and the never-ending epics weren't a problem.
We are using one Epic for each application or module in these applications. We have also some specific Epic for Infrastructure tasks and another for Design things. This works well and it help when you do your backlog review with several hundred issues.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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