Paths to PSPI

In scaling environment, it is common that PSPI is not yet achievable in every sprint. Even though the ultimate goal would be the team producing PSPI at the end of every short (say, 2-week) sprint, we begin with imperfect Done, i.e. there is undone work between current Done and PSPI.

Let's explore different strategies to deal with undone work. We examine two factors, who does undone work; and how often it is done.

Release Sprint

This is common approach - we do undone work at the end of release, in a period called with different names such as release sprint, stabilization sprint, hardening sprint, etc. In essence, this is the period we clean undone work to achieve PSPI.

Teams may do all this work. They are dedicated in achieving PSPI before working on the next release.

Separate Undone unit may do this work. Regular Scrum teams hand over the undone work to Undone unit. They may immediately move to next release, most likely with some reservation. When there is big gap towards PSPI, they may even reserve all their effort until reaching PSPI. Possibly after some period, they move to next release with some reservation.

See more details from "Practices for Scaling Lean & Agile Development", Chapter 5, Planning.

It is common to have some extent of staggering. The reason to stagger is for efficiency, while it creates problems such as multi-tasking, less collaboration, less visibility, less flexibility, etc. Kane Mar already blogged about this anti-pattern 10 years ago.

Hardening in every PI

PI (Program Increment) is a concept from SAFe. PI consists of a few normal sprint plus a sprint of HIP (Hardening, Innovation and Planning). Since v3.0, SAFe changed HIP to IP by removing Hardening. This is good in encouraging teams to complete undone work earlier, but in practice, Hardening largely still exists in IP sprint. It is good strategy to achieve PSPI every few sprints, when we can not yet achieve it every sprint, while it is too risky to only do once at the end of release.

In SAFe, teams and Undone unit may co-exist to raise Done to PSPI. As teams work throughout PI, it indicates that teams do not move forward until PSPI is reached. Staggering exists between hardening this PI and planning next PI, but it is somehow limited.

Another possible scenario is that teams hand over undone work to Undone unit, and move forward to next PI immediately with some reservation. They may create staggering between PIs. As IP sprint usually doesn't last long, it is less tempted to do so between PIs.

PSPI in every sprint

If team cleans undone work every sprint, it is natural to just expand Done.

Recently, I encounter a couple of cases when separate Undone unit does undone work every sprint, which creates staggering shown in the below.

Why do they want to stagger by leaving undone work to Undone unit in the following sprint, rather than expand Done to reach PSPI in the same sprint?

There are two main reasons.

1. Team lacks skill for undone work, this can be solved simply by moving people in Undone unit to team.

2. It is more efficient to stagger. Let me elaborate.

Suppose that we have 1-week manual regression test as undone work, and we have 2-week sprint.

• If we exclude manual regression test in Done by team, while this is done by undone unit in the following sprint. We have 1-week undone work for 2-week development.
• If we include manual regression test in Done by team, we can only do 1-week development, as 1-week is for manual regression test.

Of course, this line of thought assumes that staggering has no extra cost, and undone work takes fixed time (1-week). Neither is really true. On the other hand, we can acknowledge that the efficiency is indeed low with current capability of doing undone work. So, it may make sense to first improve the efficiency of doing undone work by e.g. test automation.

Actually, there is another alternative. Instead of staggering, we do 3-week sprint by moving people from Undone unit to team and expanding Done to include manual regression test. How does that compare to 2-week staggering?

At first look, it seems still more efficient with staggering. In 9-week period leading to PSPI in the end, with staggering to PSPI, 8-week of development work is done; with whole-team to PSPI, 6-week of development work is done.

With closer look, staggering affects the next sprint development, so, instead of 2-week, it may only be 1.8-week (assume 20% loss from staggered week, which could still be underestimated), then, it only gets 7.2-week rather than 8-week.

Moreover, we assume that 1-week undone work is fixed cost, which is not true. It doesn't consider the positive effect by having the whole team work, and improve, on manual regression test. Chances are, the team speeds up the automation soon it does not take 1-week any more. If it takes 0.5 week to do undone work, it gets 7.5-week instead of 6-week of development. Gradually, slow may become fast.

To be fair, with staggering, it is also possible to improve the efficiency of doing undone work. Eventually it would take undone work into the sprint, i.e. expand done, in 2-week sprint. Same with whole-team PSPI in 3-week sprint, as the cost of getting PSPI decreases, it would shorten 3-week sprint to 2-week sprint.

Therefore, there are two paths.

1. from "2-week sprint, staggering by Undone unit" to "2-week sprint, PSPI by whole team"

• Perceived efficiency, less waste as development continues. In the short term, this may contain some truth.
• It delivers PSPI every 2 weeks, while the other only delivers PSPI every 3 weeks. This may be important depending on the context - how frequent it has to deliver.

2. from "3-week sprint, PSPI by whole team" to "2-week sprint, PSPI by whole team"

• Avoid all those problems with staggering
• Faster improvement to decrease undone cost
• More learning, leading to long-term efficiency

If we think of both as intermediate steps, which would drive the improvement faster - imperfect done or long sprint?

Conclusion

We may have to live with undone work while we improve towards PSPI every sprint. For each piece of undone work, gradual improvement is possible. The below summarizes possible evolving paths.