How to handle feature carryover across PIs?

[Tim Young]

Since only one PI can be selected for a feature, what is the proper way to handle work that carries over from one PI to another PI? Currently we are asked to change the PI once it carries over. Will this cause bad data?

• How will the work done during sprints in the previous quarters show?
• Are the misaligned stories in the Program Room accounted for in reporting?
• Is the percentage complete calculation my Roadmap accurate?
• Will velocity calculations be accurate? 
• I'm sure they are other areas impacted also.

[Sam Tsubota]

@Tim Young Splitting features that don't complete within a PI is a good option for handling carryover work. When you split a feature in Jira Align the feature will be split into a part 1 and part 2. The part 1 of the feature will have all the accepted stories linked to it and the part 2 of the feature will have all the stories not accepted within the PI. During the splitting process you can target the PI to assign to part 2.  After splitting the feature, a link between split part 1 and part 2 in the feature details panel will appear.

Targeting split part 2 for a future PI

Link to split part 2

The advantages of splitting features are vs. carrying over features:

• The stories won't appear as misaligned in the Program Room
• Velocity calculations will reflect the work completed in a PI
• When carrying over a feature to the next PI the Program Board will show a planning issue for the feature that stories are in a past sprint. This is due to accepted stories in the prior PI linked to the carryover feature. By splitting features this will be avoided and the Program Board will reflect actual planning issues.

[Richard Wilson _Jarow Digital_]

Thanks @Sam Tsubota great article and highlights why splitting features is important.  Coupling this with prioritisation and with the focus of getting stuff done it can highlight where teams need to focus. 

[David Spiller]

@Sam Tsubota Why are you not able to split a feature multiple times?

[Sam Tsubota]

@David Spiller This is by design. The intent of features is to represent an increment of value that is completed with a quarter or program increment. If you have a feature that takes more than one quarter or program increment to complete, it either should be a portfolio epic or broken down into small increments. If your feature is to roll up ongoing work like KTLO or production support, I suggest creating a feature each quarter or program increment to link related stories to and then accepting them at the end of each quarter.

[Shaurya Jain]

Hi @Sam Tsubota When we split a feature does Feature Part 1 in PI 1 count as Completed and thereby reflects as an Accepted feature and thereby affects the Lean Metrics in a not so correct way ?