What do I do if someone wants to change a Feature mid Program Increment?
This question gets asked all the time in my Implementing SAFe class because this will always happen in real life; this is not a theoretical question and as such we need to know how to deal with it.
The first thing I do is remind the class SAFe is a fractal model; whatever we do at the Team Level we do at the Agile Release Train (ART) Level, however, the frequencies may not be the same. For example, at the Team Level we do a Daily Scrum every day, at the ART we do a Scrum of Scrums or an ART sync but probably once or twice a week.
Team Level Change
In the first instance let’s consider if someone outside the team wants to change a story within a Sprint that makes the Sprint Goal obsolete.
“The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product (Scrum) [/ Team (SAFe)] Backlog” (Scrum Guide)
Only the Product Owner has the authority to cancel the Sprint before the time-box is over. This is normally under the influence of the Stakeholders, Development (Scrum) / Agile (SAFe) Team or the Scrum Master. A Sprint would only be cancelled if the Sprint Goal becomes obsolete.
This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances.
But, due to the short duration of Sprints, cancellation rarely makes sense; you would hope that the change of direction could be accommodated in the next Sprint which could never be more than 9 days away if working on a 2-week cycle. Plus it means that the team has time to consider and refine the new work for the next Sprint.
Over the years I have been practising Scrum I have only cancelled ONE sprint and that was to be ‘bloody minded’ to demonstrate the transaction cost of cancelling a sprint.
When a Sprint is cancelled the transaction cost includes:
- Any completed and "Done" Product Backlog items are reviewed. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.
- We should also hold a retrospective to learn what needs to be done differently so that future sprints don’t suffer the same fate.
- Finally everyone regroups in another Sprint Planning to plan for the remaining days that is left in the current Sprint.
Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon, People often say to me: “Can’t we just swap some stories out?”
For me this sets a dangerous precedent. There is a two-way commitment; we as the team will work together to deliver the Sprint Goal, in return you (not the team) agree to leave us alone for the duration of the Sprint to meet that Sprint Goal. We can’t do that if there is a constant moving feast.
If the Team starts to concede to this level of change then it will become the norm with increasing uncertainty at Sprint Planning and variability within a Sprint.
But let me be clear, as the team works it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If this work turns out to be different to what they planned in Sprint Planning, that is fine. The Team owns the Sprint Backlog and can change its contents as long as they continue to work towards the Sprint Goal.
This is fundamentally different to someone outside the team changing a story in the Sprint Backlog.
ART Level Change
So let’s apply the same principle at the ART Level. Here the Teams have made a commitment to their PI Objectives.
“Program Increment (PI) Objectives are a summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming Program Increment (PI).”
Most Program Increments are typically 8 to 12 weeks in duration therefore, it is more common for there to be variability within a PI. However, cancelling a PI because the Team and Program PI objectives are obsolete has a much higher transaction cost i.e. re-convene a 2-day PI Planning event for 5 to 12 teams!
Therefore, our first line of defence is: “Can this wait until the next PI?”
Again depending on the length of the PI we might only be a few weeks away from the next PI and in the meantime Product Management have time to explore, refine, prioritise and socialise the Feature(s) for the next PI. In most cases this is a real option after we have reminded the company of the two-way commitment!
If the company changes direction or if market or technology conditions change then there is no sense in continuing with the existing work.
Personally, have I swapped out a feature for a new feature? Yes!
But this is fraught with danger; we have just spent two days with the Teams PI Planning, collaboratively understanding the dependencies and gaining alignment. We have created a Program Board that visualises the dependencies - just pulling out one feature and plugging in a new feature is not that easy! It requires a significant level of impact analysis. So be aware.
However, the advice from Dean Leffingwell (creator of the SAFe Framework) is that if you have too much variability in your work then you need to have a shorter batch size; rather than a 12-week PI maybe a 10-week or even a 8-week PI. Yes, there is a higher transaction cost for PI Planning but as with all things it is a trade off.
Alternatively, the other option is to reserve more capacity within the PI and the teams for ‘unknown, unknown’ work; the things we don’t know we know!
Hope this helps.