Innovation & Planning Sprint in Jira Align

[Mit]

Hi Team,

One of the clients have got a  unique way of managing their PI cadence. Through out the year, they have 6 delivery sprints (that map to 6 standard sprints being created as anchor sprints). At the end of the calendar year i.e. from December 2nd, they have got 1 innovation sprint (for 2 weeks) and then have got a period between mid-December and Jan first week, named as Planning & also uses this to take care of the Christmas shut down etc.

I had a question around the best way to configure this in Jira Align in a way that does not impact their PI velocity. Have got the following options

1. Create a PI with end date of the PI being the last day of the standard sprint i.e. end of 21.4.6 for e.g. & have a gap between end of 21.4 & start of 22.1 (commencing from January, next year)

2. Extend the dates of the last PI (21.4), create 6 standard sprints and 2 Innovation & Planning sprints (manually add 2 additional sprints with relevant dates and type = innovation & planning) to cover the period of 4-6 weeks

For option 2, I wanted to know

what are the implications I need to be aware of? i.e. if I were to create 2 sprints with the type as Innovations & Planning does that impact the historical PI velocity calculations?, - - does that mean that the teams in Jira will have to create those additional sprints or else the sync process would break?

[Philipp Barry]

@Mit To make sure we understand your case correctly: Your client has currently configured 1 PI per calendar year which includes 6 sprints + 1 or 2 (up for debate) IP sprints? If so, how long are the 6 normal sprints?

I am happy to already give you an answer concerning the general question "Should there be breaks between sprint & pi timeboxes?"

The good practice from my point of view is to connect timeboxes without breaks. This means PI X ends and PI x+1 starts on the next day. That would also mean that the last sprint in PI X ends on the last day of the PI and the first sprint in PI X+1 starts the next day with the new PI.

I personally suggest to not divert from this pattern, even if there is a so called “shutdown”. The reason for this is that “making all work visible” is a key practice of working in an agile way and even during a shutdown, usually at least a limited amount of IT work is done. Additionally, the work usually normalizes over the course of a PI and across PIs since there are times in other PIs (if you follow the practice of having something about 4 PIs a year) where the velocity dips as well (summer holidays, around thanksgiving, around holidays,....).

[Mit]

Hi @Philipp Barry - thanks for your response & I 100% agree with you and concur that having a gap in the PIs is not ideal.

• The client have configured 1 PI (21.4) having 6 standard sprints of 2 weeks (10 work days) that ends on 1st December, 2021.
• The next PI - 22.1 kicks in on 13th January, 2022
• Essentially there is this 6 weeks period - ideally 3 sprints

As you rightly said, though the rigour would be less during the "shutdown" period, work does happen - however the work is something that the teams have not planned for during their PI planning i.e. the PI plan will consist of features scheduled to be completed by end of sprint 6 of PI 21.4 - though the teams use this time to complete any spillovers, tech debt reduction work etc.

In this case, is it recommended to extend 21.4 to end on 12th January 2022 and create 3 IP sprints - so that the historical program velocity calculations do not get impacted?

If we do create 3 IP sprints as anchors in Jira Align, can the sprints in Jira still be mapped to the IP sprint or one would need to create a standard sprint?

Alternatively, we can still go ahead and create 3 additional standard sprints and manually override the velocity in Align for those sprints to not impact the historical PI velocity

[Philipp Barry]

Thank you for your clarification. If the client would be somewhat open to reevaluate the current approach, I would have that discussion. I think that cadence is one of the most crucial principles in an agile way of working, even more so in a scaled agile way of working and changing PI length is just generally problematic in my point of view.

If there is really no chance for this discussion for this year anymore which I could understand considering enterprise planning timelines, based on the limited perspective I have, I suggest the following approach:

- extend the PI and create 3 normal sprints
- make sure that the special character of the sprint is reflected in the system (naming convention, description....) for historical visibility
- all teams should capture their work in Jira accordingly in respective sprints
- after the sprints have been conducted, understand how much work of what kind has really been done
- override the velocity accordingly

If you decide that it would be better to work with IP sprints, please be aware of the current behaviour of IP sprints, which only work if team iterations are created in Jira Align (https://jira.atlassian.com/browse/JIRAALIGN-1282). The Jira sprints will then sync accordingly as IP sprints.