Program Board writes the epic's Due Date during PI, but not the Sprint — expected behavior or a bug?

[Alexandre Paiva de Lacerda Costa]

What we did: On the PI Program Board, we placed the epic at the end of the chain of stories and tasks, respecting each sprint's capacity and the size of the items allocated to it. When closing the PI, we saved the plan with the confidence vote.

What we observed: Jira saved the epic's Due Date (the end date of the sprint where the epic was placed), but it did not save the epic's Sprint field. In other words, the epic ended up with a delivery date but without a reference sprint.

What we expected: That both pieces of information would be persisted — "the epic will be delivered in Sprint X, on that sprint's end date" — keeping traceability between the target sprint and the date.

We already understand that epics are not assigned to sprints by default (the sprint lives on the child stories/tasks). Our question is about the Program Board's intent:

1. Is saving only the Due Date and ignoring the epic's Sprint field the by-design behavior of the tool, or is it a limitation/bug?
2. Is there a recommended configuration to also persist the target sprint on the epic when saving the PI (e.g., adding the Sprint field to the Epic screen, date roll-up, or a native feature of the app)?
3. If the Due Date is the "official" way to represent the epic's delivery, what is the best practice to avoid losing the epic → target-sprint traceability?

Thanks in advance for any guidance, and screenshots of the configuration from anyone who has solved this in PI Planning would be much appreciated.

[Ajay _view26_]

Hi @Alexandre Paiva de Lacerda Costa 

I think this is actually by-design behavior because  Epics in Jira are intentionally kept above the sprint level in the hierarchy.

Sprints belong to stories and tasks - that's where the actual sprint commitment lives. When the Program Board calculates a target delivery date for an epic, it's looking at when the last child item is expected to finish, and it writes that back as the epic's Due Date.

But it deliberately doesn't assign the epic itself to a sprint because the epic spans across sprints - it wouldn't be accurate to say "this epic is in Sprint 5" when its children are scattered across Sprints 3, 4, and 5.

So the Due Date reflects the end of the epic's delivery window, but the sprint field stays empty because the epic isn't scoped to a single sprint.