· Blog · 5 min read
The dangers of blindly following (or ignoring) the Program Increment Timebox
The SAFe rule that features must fit within a PI timebox is a proxy for deeper lean-agile principles. A practical take on when to respect it, when to flex it, and how to think about feature sizing across your Program Increment.
NOTE: Scrum teams have had this issue for more than a decade now. But since SAFe(tm) is all the rage these days let’s use the Program Increment Timebox here and leave it as an exercise for the reader to apply the thinking to the Sprint/Iteration timebox.
Here’s the context — You are an RTE facilitating a SAFe(tm) Program Increment (PI) Planning (I’m actually using SAFe 4.0 terms here. You know this as Release Planning) . When kicking off the day you remind remind the teams that Features needs to fit into one PI. The Product Manager presents the top priority Features. They can all fit into the PI. You guys did a good job to prepare the Features backlog together with the Product Owners and some representatives of the teams.
Teams start to break down the Features into stories and fit them into their iterations. One thing you notice is most teams seem to spread their Feature all over the PI. In some cases you see the load is very close to capacity throughout the PI. In other cases you see a pattern of diminishing load towards the later sprints. You are actually happy to see it as you are familiar with the pattern of surprises during PI execution that end up taking that space.
In the Draft Plan Review you point your observations out. You remind everybody to take on some Stretch Objectives in case Murphy takes a break this PI.
Then a Scrum Master from one of the teams comments:
My team actually looked at the next feature on the backlog. There’s no chance we will be able to finish that feature within the PI even if Murphy takes a sabbatical. At the best case scenario we will be finished with our first feature during iteration 4. And it seems like the next one will take 2–3 sprints most likely, meaning it will cross into sprint 1 or even 2 of the next PI.
Being a programmer he complains about compilation error on your guidance from the morning:
“Features must fit into the Program Increment timebox”
As you prepare to answer, the Product Manager jumps in (with a recognizable faint of sarcasm):
This is a moot point. When’s the last time that teams actually pulled in a stretch feature? Somehow once we start execution the features always fit the timebox eventually. I’m not saying we are slacking off. What I AM seeing is that the scope of the feature gets padded if there’s time. Like people are trying to avoid starting a new feature towards the end of the increment/release.
I wonder what would happen if we go from 5 sprint increments to 3 sprint increments. Would we end up with smaller features each increment but a tighter feedback loop and more features throughput overall?
You think about it for a few moments, trying to consider what to do at the practical level based on the underlying lean/agile principles you recall from your Leading SAFe class. Why does SAFe have this rule that Features must fit the Program Increment timebox? You recall the Agile Manifesto — Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. And Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This is probably the reason why we try to fit the timebox. You realize that “Respecting the timebox” is a simplified proxy for the deeper meaning here which is to aim for working software you can integrate and deliver as soon after you start working on it. This is useful but has its limitations.
You are ready with a suggestion:
What if we look at the timebox in a different way? What if we agree that the timebox for each feature is ideally not more than half the PI length so that we have enough space afterwards? And with that rule even if we pull a feature late in the PI and we are not able to finish it with the PI we know that it will be finished pretty soon afterwards.
You draw a histogram on the big flipchart next to you:
This is a histogram showing the realistic spread of feature sizes we should aim for. X axis is feature size and Y axis is number of instances. Can we agree that 80% of the features will not take more than 75% of the PI timeline and around 50% of them not more than half the PI timeline? And yes, despite our best intentions to slice things down and find smaller meaningful chunks that are marketable/viable, around 20% of the features WILL take almost a whole PI and a small percentage of them maybe even more than that even if you start them in the beginning of the PI. Those go to your Risk board by design and will require ongoing management to look out for further inflation and look for emerging opportunities to find marketable/viable milestones along the way that can help break to smaller features.
Bottom line — Don’t be dogmatic. Recall the principles to find the REALLY SAFer approach for your context. Features SHOULD fit into PIs. But good features won’t ALWAYs will.
Happy Holidays! See you in 2016 everyone!
Shameless Plug — I’m opening 2016 with a Leading SAFe workshop in Boston on January 5–6th based on the latest and greatest content from the SAFe world. Would love to see you there.
Scaling Agile with SAFe requires more than certification — it takes context-sensitive implementation. Explore SAFe advisory or let’s talk.
About Yuval Yeret
Yuval is a rare practitioner who has shaped the agility path of dozens of organizations and influenced the frameworks used across the industry. He helps product and technology leaders move from agile theater to evidence-informed, outcome-oriented delivery that creates better value sooner, safer, and happier.
