If I have an Epic planned for the current PI and can't close all of its subtasks until the end of the Program increment, can I set the fixVersion for the following PI, or should I close it and open a new one for the next PI?
I am using JIRA and hours estimations instead of story points. Thanks! Also, I am not working in sprints; the unit used is one Program Increment.
It's not quite clear to me how you are using the concept of "Epic". I've seen a few different ways of treating Epics, two in particular. How I would suggest handling this case depends on your view of exactly what an Epic is.
In one case, the Epic is a container for work that can belong to multiple releases (where each release is identified by a fixVersion). Each Story, Bug, or other issue under the Epic is assigned to the release where it was incorporated. The Epic itself wouldn't have a fixVersion set at all, but it would have a workflow (often a simple one, like To Do -> In Progress -> Done) where it would transition to In Progress when the first piece of work under the Epic was started and then transition to Done when the last piece of work entered its final state.
In another case, the Epic is a bundle of highly related work for a given release. The Epic represents something of value to the stakeholder, while the work under the Epic represents thin slices of work that can be designed, developed, integrated, and tested by the team. However, all of the work for the Epic would be integrated into the product, tested, and released as a single bundle. In this case, the Epic could have a fixVersion assigned to it.
I would strongly recommend choosing some definition of Epic and using that to guide when you close it. Then, be consistent across all Epics.
I am struggling with the idea of the Epic as a timebox, though, that would get closed just because your Program Increment ends. In both cases that I've seen, the Epic is a container for work and represents the state of that work. It doesn't get closed and work moved around just because the calendar says so. However, I could be missing some context that could make this make sense, so I won't say that you absolutely shouldn't do this. I'll just say that it's not something I've seen and I don't see the value in it.
Should I carry unfinished working for the next increment or shall I close it and open again?
There's no canonical answer for this question. The very same debate happens with regards to unfinished User Stories at the end of a Sprint (but in your situation, at a different level).
Both options (carry forward / close and reopen) have pros and cons. My recommendation was to carry forward (for most cases) the work (in your case, tag it to the next fixVersion). The benefits of closing / open are marginal in comparison to the negative impacts it'll have.
One of the biggest drawbacks of closing / open is that your historical information will go nuts. Instead of having a sound historical info that your average time to deliver an Epic is x units of time, you'll have two different epics where one has x units of time and other has y units of time and none delivered full business value.
Some people argue that all items from old iterations should be closed by now. Exactly, that's what teams should strive for. However, when that doesn't happen, we shouldn't sweep it under the carpet and hide these evidences. We should tackle it head on and use as input to avoid recurrence in the future.
Why most cases? The cases where the value delivered was deemed good enough, were closed (and the remaining parts of work closed as well). This is important as we want to strive for outcomes (delivering enough business value) over outputs (completing a checklist).
The epics in Agile are a collection of multiple tasks or user stories. They are usually responsible for producing a major deliverable, which may include various Agile features, for example.
The project, on the other hand, is a very tensile term. If its size and scope are big, then it might include several project epics. However, people often use "project" and "epic" interchangeably. In general, you can think of them as the building blocks of Agile's initiatives and themes. In Agile project management, epics are larger bodies of work, which can be the building blocks of the upper mentioned initiatives/themes. They should be more specific and measurable so that you can see their contribution to the primary goal.
