The last hour of PI planning has a ritual inside the ritual. The plan is up, the risks have been ROAMed, and someone reads the team’s objectives out loud one more time before asking the question that actually matters: which of these are we committing to? The room sorts. Eight objectives go on the committed list. Two get marked stretch. Then comes the fist of five, and everyone gets to work.

That sorting moment is the confidence vote applied to scope, and like the vote itself it is expert engineering judgment — the team weighing what it knows about the work, the season, the dependencies, and each other. The judgment isn’t the problem. The problem is that the line gets drawn once, on day one, and then has to survive ten weeks of moving reality.

What the committed/stretch split actually is

SAFe is specific here. Committed PI objectives are the ones the team has high confidence in delivering, and they’re what counts in the program predictability measure. Stretch objectives — SAFe also calls them uncommitted — are in the plan and in the capacity. The team fully intends to deliver them. They’re just excluded from the promise. Stretch isn’t a euphemism for “nice to have,” and it isn’t sandbagging: it’s a deliberate reserve, the scope equivalent of declining to promise your best-case date.

What most rooms are missing isn’t the concept. It’s a way to check where the line sits against evidence — and a way to notice when it quietly stops being true.

The line is a confidence level

Sort objectives by how sure you are and you’re doing informally what a forecast band does with arithmetic. Release Management, Roadmaps, Portfolio PPM & Timeline forecasts a release as three dates at three confidence levels — P50, P85, P95 — by running Monte Carlo simulation over the team’s actual Jira throughput. Read your PI plan against that band and the committed/stretch line stops being a feeling. Scope that clears the P85 date is commit-grade: you’d deliver it roughly five times out of six. Scope that only fits if the P50 date holds is a coin flip — which is precisely what a stretch objective is. The gap between P50 and P85 is stretch territory with a number on it. (Which percentile to promise against is its own decision; here’s how to choose a commitment confidence level.)

None of this replaces the room. The team still owns every assumption that matters: which throughput window to trust, whose capacity is really in, what’s actually in scope. The band is the SAFe confidence vote run on evidence the team validates — the same judgment, held to the same standard, all increment long.

The line moves after the vote

The three things that erode a committed release date — scope creep, dependencies surfaced too late, and capacity changes — don’t just move the date. They move objectives across the line. A “small” addition lands inside a committed objective and quietly pushes a stretch objective out of reach. A hard dependency surfaces in week six, and a committed objective is suddenly carrying coin-flip odds nobody voted for. Two engineers get pulled onto an incident, and the stretch objective a sponsor has started treating as promised was never going to make it.

Tracked live against the committed date — in days, as they happen — each of those becomes a decision instead of a surprise. Renegotiate the scope. Resequence the dependency. Move an objective across the line on purpose: demote it to stretch out loud, or promote one because the band says there’s room. The alternative is discovering the demotion in the PI system demo, in front of everyone the date was promised to.

Draw the line on evidence

The committed/stretch split is one of the most honest ideas in SAFe: promise what you’re confident in, hold ambition in reserve, and say plainly which is which. It deserves better than day-one guesswork. See which objectives your committed date actually covers at 85% — and watch the line as reality moves. Try Release Management, Roadmaps & Portfolio, free for 30 days. It Runs on Atlassian, so your Jira data never leaves Atlassian. (See how the confidence band works in the docs.)

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio