ServiceNow SPM- Enterprise Agile Planning(EAP) Query

[rohtomar]

Hi everyone,

I’m currently working on a Jira ↔ ServiceNow SPM (Strategic Planning Workspace) integration and facing a real-world challenge that I’d love to get some insights on from the community — especially from anyone who has implemented Enterprise Agile Planning (EAP) before.

The scenario:
Jira is the source of truth for stories, tasks,defect & sprints.
PI intervals are predefined in ServiceNow as per the business calendar

The Challenges :
Different teams in Jira follow non-standard sprint cadences (e.g., 14 days, 21 days) and their sprint start/end dates vary. When we sync these sprints into ServiceNow, we hit a major roadblock — EAP doesn’t allow overlapping sprints under the same PI.
This leads to:
• Integration failures due to overlapping sprints.
• Sprint dates not aligning correctly with predefined PI intervals.

Has anyone here dealt with sprint alignment and overlap issues in an EAP setup? How did you approach the solution — did you standardize sprints, customize the iteration model, or handle it differently?

Would love to hear your thoughts, experiences, or best practices! 🙌

#SPM #EAP # SPW #Sprint #EnterpriseAgileIteration #PI

[phil_bool_unifi]

This is a known challenge.  The EAP (I'm only experienced with the Yokohama version) has its own sprint calendar that it expects your work to align to.  The flexibility to define your own sprint start and end dates, as is present in SN's Agile Development 2.0, isn't replicated in the SPW's EAP.  There's some benefit to this:  You can plan across teams by giving them the same sprint calendar, and you can keep a clear picture of when dependencies will be hit that way. 

If the actual consumption of activities is happening exclusively in Jira, you could align the SN sprints uniformly (eg fortnightly) then not have the sprint value in the Jira record captured when stories are created/integrated into ServiceNow.  That would mean the date would determine the sprint in ServiceNow, which would otherwise be ignored.  So long as you have other information to group the work by (assignment group, for example) you will still have all the details.  

If you still needed to report on data by Jira sprint from ServiceNow, you could capture a string value (sprint ID or something) that you can use to filter/group by in EAP.

The EAP tool is only a few releases old, and it's a huge step forward in aligning planning exercises in one interface, as well as being able to represent work happening in waterfall, hybrid and agile methodologies in the one workspace.  I've no doubt it'll mature fantastically over the coming releases.  I'd also like more flexibility on sprint dates.

[rohtomar]

Hi @phil_bool_unifi, 

Thank you for sharing the information.

I wanted to highlight a challenge I’m facing: our client has teams working on both 2-week and 3-week sprint cycles, and this is causing some complexities in planning. If we choose to align at the enterprise level, we’d have to select either a 2-week or 3-week sprint for everyone.
To address this, I’ve set up different planning intervals that share the same dates as we currently use, and created 2-week sprints as child sprints within these intervals for the relevant teams. Could you let me know if this approach is feasible, or if you see any issues with it?
Alternatively, we could consider standardizing sprint planning across all teams to simplify things.

[phil_bool_unifi]

It depends on what you're hoping to achieve in the EAP.  If you want to plan and manage sprints in EAP that are then going to be delivered using Jira, and have the option of standardising the sprint framework company-wide, there are benefits to doing this as I've mentioned. 

Otherwise, the sprints in the EAP will not align to your sprints in Jira.  If that isn't an issue, and you're happy to see each two- or three-week "interval" to highlight dependencies and make planning decisions, you can do that in EAP.  The 'sprint' value to be captured from Jira would then become a string to group data by if required.