nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Should we use Epics for parts/sections of our app?

unknown

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:

1. Authentication

2. Scheduling

3. Flights

4. Maintenance

5. Pilot Documents

Would you recommend against this?

Accepted answers

All comments

Nic Brough -Adaptavist-

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

Epic links are single, so any issues in those five Epics won't be in others.
If you install something like Portfolio or one of the other "higher level" project management add-ons, they may expect these Epics to be Epics properly. (Although, with Portfolio, I'd probably move those five over to be themes...)

Walter Buggenhout

Hi @[deleted],

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 :-)

unknown

Thanks Walter.

unknown

Thanks Nic, appreciated.

larry_lowe

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.

Sébastien Maisonneuve

Hi,

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.

Steve Smiley

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

epic

label