Align Features - Do they have to only be completed within a PI?

[Rizwan Hasan]

This is more of a feature question of JA, are Feature Objects really only limited to be contained within a single PI?

Features may take longer to deliver, but it seems like there is a limitation in JA that it can not extend further past a single PI.

I understand the Agile "definition" that it should be planned in a way that it is completed within a PI...however that is too idealistic and not a reality.

How can JA be flexible to have Features that span across multiple PI's?

[Jesse Pearlman]

Howdy, Rizwan,

Jira Align does limit a Feature object to be scheduled to one PI. 

While I understand the desire to be flexible with how long a feature may actually last, this is just an extension of how teams are trying to right size their stories to be completed in a sprint.

So Jira Align gives you the option to Split the Feature when recognizing that it will not be completed in the PI.  This starts to illustrate where Features may be too large and help drive them to the right size for predictability at the Train/Program layer.

The key to scaling agile is to adhere to the practices of being predictable, you may not be great at it at the start but it can be improved.

Split the features that do not complete, retro on the PI, apply learnings, improve.

[Dhruv Doshi]

@Jesse Pearlman I understand this, but how does Jira Align account for Flow metrics such as Flow Time? If a feature was implementing and now is being carried over to the next PI. At this point splitting the feature would make it seem like it was completed in time when it wasn't. Any thoughts on this?

[Rich Sparks]

I agree with my friend Jesse's point about trying to get to a predictable cadence for delivery. If your teams can get into a regular cadence of planning and delivering what was planned, it can lead to great benefits for your customers and your company.

The other thing to remember is there's nothing magical about having a 3-month PI schedule. The idea behind that 3-month interval is to have a common, manageable cadence for your teams to

• Agree on the outcomes they want to achieve
• Plan how to reach those outcomes
• Do the work to deliver the outcomes
• Get feedback from the customers to make sure the right things were delivered and see if the outcomes were achieved
• Check the market context to make sure the outcomes are still the right ones
• Go back to the top and start again for the next cycle

If it's taking your teams 6 months to deliver features, there's a lot that can change between when you start work and when you can get feedback about whether it was the right thing to do.

Achieving predictability gives you the extra benefit that each time you go through that cycle, you have a good idea of what your team(s) can achieve and you're not alway overburdened with work or late with delivery.  

[reemyounan]

Logically, a feature corresponds to a deliverable. How is splitting a feature fitting into this delivery model, neither of the split features is a deliverable on its own?!   

[Peter Grebus]

Is there a way to keep in-progress or in QA in the current feature when you split a feature?  The default carries all stories to the part 2 feature.