How to handle epics in agile program increment



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



  • 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 https://pm.stackexchange.com/q/3990/430 (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).


Log in to reply
 


Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2