Managing Product Epics and Engineering Epics

Question

We are trying to find teh right balance between Product Epics and the break down of those epics into a size that is meaningful to engineering while still meaningful to product.

What I am currently seeing is that an end user Epic from product is either being managed outside of jira, or in jira, and being linked to engineering epics.  Engineering broke the product epic down into epics that are meaningful to them, but linked to the product epics for traceability.  Some of these engineering epics are microservices that enable the product epics.

We could argue that product\engineering agree upon an epic, and link all stories to that epic.  We are finding those epics are more technical in nature and less product or end user friendly.  Others have offered that in our products you can manage product epics outside of jira, and just work with engineering.  In another tool you can create a product epic and link it to the engineering epics.

I believe this is mostly the case since we are building a set of microservices and capabilities technical in nature to enable end user features.

thoughts an opinions

Neil Wills_3vfe1i · Answer

I used the same definition, creating relationships between epics, linking the enablers to the product epic.

we are building a brand new micro service product, take a product requirement, think through the service, model, front-end, back-end changes necessary to be designed, developed to enable the experience that was asked for originally.

To build those enabling features resulted in creating engineering epics.  The product epic is done when those rlensbling epics and stories are done, and in most cases so far there are no stories on the product epics just links to enabling epics.

Carlos Garcia Navarro · Answer

Hi @Neil Wills ,

I think of Epics as work items that are completed within an agreed timebox, e.g. a calendar (or financial) quarter, or if you use SAFe, the corresponding program increment. I assume that the difference between product and engineering epic in your example is the definition of acceptance criteria or the description of the epic. I think that epics can be more product oriented while stories are more development/test/architecture oriented, and the link between stories and epics represents that the engineering work enables the product launch as defined by the epic. You can also have technical or engineering epics (I call them enablers) if they aren't related to a specific product.