PI inheritance rule for work items

In Jira Align, there is a strict parent-child PI inheritance rule. If an epic participates in PI1, PI2, and PI4, its child capabilities or features must participate in one of those three PIs and cannot participate in any other outside the scope of the epic. Stand-alone features are not restricted from participating in any PI.

As an example, let’s imagine an epic that spans PI1, PI2, and PI4. The epic has a child capability (or feature) which is scheduled in PI5, PI6, or PI7. This would be totally wrong, and so when creating the child capability or feature, PI5, PI6, and PI7 cannot be selected on the child item. 

This problem often arises when it comes to the Jira Align–Jira integration. Customers commonly define Jira epics (Jira Align features) for a specific PI with stories that actually start before the PI is started or the epic is planned to start, and/or the stories are completed long after the PI/sprint is closed.

All work must be accounted for and funded properly. If an epic or feature is not approved to move forward, nobody should be working on it. If the PI or sprint is closed, work should have concluded. If there is leftover work, the object should be split.

Generally, all work should have a parent which traces its reason for being back to the epic which funds that work, contains the business justification, and ties back to a Strategy (theme).

The exception to the rule is stand-alone features. This means that each stand-alone feature technically should have a mini-business case and funding because they were discovered in the context of the program and meet a specific program need that does not tie back to a strategy.