Program Increment Cadence

Program Increment, PI – as it is popularly referred to, is a timeboxed cadence within which Agile Release Trains (ARTs) perform the work in order to deliver value. Duration of the PIs vary from Organization to Organization, Typically PI comprising of 10 calendar weeks is the common one; however we do see the variations in the PI cadence from 8 weeks to 12 weeks. 

In this article, we will discuss the merits / demerits of these variations, typically the one with prolonged duration.

The ideal case is where the PI cadence is set to 10 calendar weeks, comprising of 5 sprints as follows

·      Sprint 1 to 4 are the development sprints (8 calendar weeks)

·      Sprint 5 is the Innovation & Planning (IP) sprint (2 calendar weeks)

In PI Planning event, teams are usually comfortable planning the work for upcoming 8 calendar weeks, which are the 4 development sprints. Teams ensure to have sufficient backlog for the work to be planned. In this scenario, PI cadence of 10 weeks is ideal. 

Many Organizations feel that sprint 5 or the IP sprint, is a sprint, where there is no development work done, and hence is a non-value added period. Organizations hesitate to spend on these IP sprints, after every 8 weeks, that is 2 calendar months. Hence the senior management inclines to prolong or increase the Program Increment cadence to 12 – 14 calendar weeks.

In such cases, each Program Increment comprises of 5 or 6 development sprints, followed by one IP sprint. This way, number of IP sprints in a calendar year reduce. However, this creates multiple issues or unnecessary overheads. 

Insufficient Backlog: 

Most of the times, teams do not have sufficient backlog to take up the work for 5-6 sprints. In this case, the PI planning is not effective. Teams plan for the initial sprints and may end up having a mini-PI planning for later sprints, during the PI itself. This defeats the purpose of increasing the length of the Program Increment. 

Less buffer for leftover work: 

While working during the development sprints, there is a possibility of work getting spilled over to next sprint, resulting into having a leftover work during IP sprint. IP sprint, by design, considers for such leftover work and sizable buffer is planned in IP sprint. However, if we have IP sprint, only after 5-6 sprints, teams may not get sufficient buffer for leftover work and teams will not be able to complete the planned work during the Program Increment. 

Delayed Solution Demo: 

Solution demos are planned during IP sprint. If the IP sprint is planned only after 5-6 sprints, which amounts to 10-12 calendar weeks, business and other interested parties will need to wait that longer for the Solution Demo. Planning the Solution Demo in between the program increment will not work, as work would not have been completed by then. 

Less Innovation and learning Opportunities: 

IP sprint, allows teams to go for Innovation. Sessions like Inspect & Adapt and Hackathon events help the teams to identify innovations and channel them to funnel into program backlogs. These I&A sessions or Hackathon events can be fun as well for the teams and provide an opportunity for relaxation from the routine work.   

Considering all this, it’s always a good idea not to have a prolonged program increment of 12 calendar weeks and beyond. In order to balance the delivery and the IP sprints, PI cadence of 10 calendar weeks is ideal and Organizations should adhere to the same throughout.