By Darren Wilmshurst, SAFe Fellow, CPrime, Original post: May 30, 2024
The Framework Team is thrilled to introduce this blog on dealing with mid-PI feature changes in SAFe by Fellow Darren Wilmshurst. Darren, the European Director of Cprime, has a wealth of experience in Agile transformation and leadership. His deep understanding of SAFe is reflected in his role as a leading consultant and trainer, and through his authorship of influential works such as “Agile Foundations” and “SAFe Coaches Handbook.” Darren’s active engagement in the Agile community, including founding the London SAFe Meetup, showcases his dedication to advancing Agile practices.
Enjoy the blog!
— Joe Vallone and the Framework Team
Today I want to tackle a question that comes up all the time in my Implementing SAFe® class:
“What do I do if someone wants to change a Feature mid Planning Interval (PI)?”
This is a real-life scenario that we need to know how to handle effectively.
First things first, let’s remember that SAFe is a fractal model. What we do at the Team Level, we also do at the Agile Release Train (ART) Level, although the frequencies may differ. For instance, we have a Team Sync every day at the Team Level, but at the ART Level, we might have a Coaches Sync or an ART sync once or twice a week.
(SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile Inc.)
Handling Changes at the Team Level
Now, let’s consider a situation where someone outside the team wants to change a story within an Iteration, making the Iteration Goal obsolete. According to the Scrum Guide,
“The Sprint Goal is an objective set for the Sprint that can be met through the implementation of the Product (Scrum) [/ Team (SAFe)] Backlog.”
[In SAFe we refer to Sprints as Iterations]
Only the Product Owner has the authority to cancel the Iteration before the time-box ends, usually under the influence of Stakeholders, the Development (Scrum) / Agile (SAFe) Team, or the Scrum Master.
An Iteration cancellation should only happen if the Iteration Goal becomes obsolete, which might occur due to a change in company direction or market/technology conditions. However, given the short duration of Iterations, cancellation rarely makes sense. You’d hope that any directional change could be accommodated in the next Iteration, which is never more than 9 days away on a 2-week cycle. Plus, it gives the team time to consider and refine the new work for the next Iteration.
In my years of practicing Scrum, I’ve only canceled ONE Iteration, and that was to demonstrate the transaction cost of canceling an Iteration.
When an Iteration is canceled, the transaction cost includes:
- Reviewing completed and “Done” Backlog items, re-estimating and returning incomplete items to the Team Backlog.
- Holding a retrospective to learn what needs to be done differently so that future iterations don’t suffer the same fate.
- Finally, regrouping for another Iteration Planning to plan for the remaining days in the current Iteration.
People often ask me, “Can’t we just swap some stories out?”
But I believe this sets a dangerous precedent. There’s a two-way commitment: the team works together to deliver the Iteration Goal, and in return, everyone agrees to leave the team alone for the duration of the Iteration to meet that goal. We can’t maintain this commitment if there’s a constant moving feast.
If the team starts conceding to this level of change, it will become the norm, leading to increased uncertainty at Iteration Planning and variability within an Iteration.
However, it’s important to note that as the team works, they keep the Iteration Goal in mind. They can change the contents of the Iteration Backlog as long as they continue working towards the Iteration Goal.
This is fundamentally different from someone outside the team changing a story in the Iteration Backlog.
Handling Changes at the ART Level
Now, let’s apply the same principle at the ART Level, where Teams have made a commitment to their PI Objectives.
“Planning Interval (PI) Objectives are a summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming PI.”
Most PIs last 8 to 12 weeks, so variability within a PI is more common. However, canceling a PI because the PI objectives are obsolete has a much higher transaction cost, like re-convening a 2-day PI Planning event for 5 to 12 teams!
Therefore, our first line of defense is to ask, “Can this wait until the next PI?”
Depending on the PI length, we might only be a few weeks away from the next one, giving Product Management time to explore, refine, prioritize, and socialize the Feature(s) for the next PI. In most cases, this is a real option after reminding the company of the two-way commitment!
However, if the company changes direction or market/technology conditions change and continuing with the existing work doesn’t make sense, personally, I have swapped out a feature for a new one.
But be aware, this is fraught with danger!
We’ve just spent two days with the Teams PI Planning, collaboratively understanding dependencies and gaining alignment. We’ve created an ART Planning Board that visualizes these dependencies, so pulling out one feature and plugging in a new one is not that easy! It requires a significant level of impact analysis.
Dean Leffingwell, the creator of the SAFe Framework, advises that if you have too much variability in your work, you need a shorter batch size. Instead of a 12-week PI, consider a 10-week or even an 8-week PI. Yes, there’s a higher transaction cost for PI Planning, but as with all things, it’s a trade-off.
Alternatively, you can reserve more capacity within the PI and the teams for ‘unknown, unknown’ work – the things we don’t know we don’t know!
I hope this helps clarify how to handle mid-PI Feature changes. If you’re interested in learning more about SAFe, join one of our classes.
Happy SAFe journey, everyone!