EAP+CWM: Unnable to start a PI after a child Sprint is already current

[Leonel Sandroni]

Hi everyone,

I'm trying to determine whether this is expected behavior or a product defect in Enterprise Agile Planning(EAP) with the standard CWM integration.

Enviroment:

• ServiceNow Xanadu
• Enterprise Agile Planning (latest version)
• Standard CWM integration

Scenario

1. A Program Increment(PI) is still planning.
2. A child Sprint is started (this happens through the standard CWM integration)
3. Later, a user attempts to start the parent PI (from EAP)

The update is aborted with the following error:

which simply checks whether any child iteration has: state=current, and abort the transaction.

After reviewing the OOB code, I also found another business rule that prevents multiple Current iterations for the same team by calling:

IterationMetadataImpl.hasCurrentIteration(current.eap_team).

However, I could not find any OOB validation that prevents a Sprint from becoming current while its parent PI is not started yet. This seems to creathe the following error:

• Sprint=current
• PI=planning

and then the PI can no longer be started becaue the business rule blocks the transition.

QUESTIONS:

1. Is this the expexted behavior of EAP?
2. Is there an OOB process that should prevent a Sprint from becoming Current before its parent PI?
3. Has anuone encountered this with the standard CWM integration?
4. Is there an official workaround or known PRB for this scenario?

Any guidance would be greatly appreciated. Thank you!

[adam04miller]

+1 - Seeing the same issue here.  Common issue as likely one of the Agile Teams starts their sprint before the full PI starts, then the PI can no longer be started.

Seems like either sprint start should be blocked until PI is started - or once a child sprint is started, start the parent PI if not already started.

[NagendrabaM]

Hi @adam04miller Please find the above reply for this article

[NagendrabaM]

Hi @Leonel Sandroni & @adam04miller 

Thanks for the detailed write-up 

This is expected behavior in EAP,  EAP does have an OOB safeguard that normally prevents a child Sprint from becoming current before its parent PI does. However, when a Sprint is started through the standard CWM integration, the sync back to the EAP iteration record runs with workflow/business rules disabled (so the sync doesn't trigger unrelated automation). That side effect unintentionally also bypasses the "child can't start before parent" guard — so a CWM-integrated Sprint can become current while its PI is still Planning.

Once that happens, the other OOB safeguard you found (blocking any PI state change while a child iteration is current in EAP) then blocks the PI itself from starting — because from that rule's perspective, the PI already has an active child. That's the deadlock: Sprint=current, PI=planning, and the PI can never move to current.

This is CWM-integration-specific — for native EAP teams (no CWM), the child-start guard runs normally, so the ordering is always enforced and this scenario can't arise.

Status: We found root cause for this behavior, and validated a targeted fix in Strategy Planning September release — allowing the PI to start even if a CWM-linked child is already current & for non CWM agile teams as well. We are tracking with this PRB2068636.

Workaround in the meantime: if you're currently stuck, Please use the attached update set which has fix for these OOB BRs to allow start of PI  after sprint started. Please test this fix in your lower environments before applying fix in PROD.