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

[Jasen Barnes]

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?

[Walter Buggenhout]

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

[Jasen Barnes]

Thanks Walter.

[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.

[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.

[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.

[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...)

[Jasen Barnes]

Thanks Nic, appreciated.