Or how can we communicate level of certainty for Sprint Goals, Business Objectives, Roadmaps, etc.?

There is often confusion about how a Team decides whether a PI Objective is Committed or Uncommitted. These notes clarify the purpose of Uncommitted PI Objectives and provide guidance for how a Team can think through this decision.

Any time we make delivery forecasts, it’s worth asking: What’s our confidence? What’s our risk?

The purpose of Uncommitted Objectives is expectation management. They enable honest conversations about uncertainty and high-value, high-risk efforts. This helps avoid the trap of a fixed-scope mentality and builds trust — what’s marked as Committed is genuinely expected to be delivered; what’s Uncommitted carries recognized risk.

Clearly labeling an objective as Uncommitted allows stakeholders to:

• Understand where technical or business uncertainties lie
• Join conversations aimed at addressing those uncertainties
• Improve the odds of success during planning and execution
• Align expectations between Teams and business leaders

Like the confidence vote, the distinction encourages meaningful dialogue during PI Planning.

The Team decides whether a PI Objective is Committed or Uncommitted. Others can discuss, influence, and question - but the decision lies with those who do the work. The Team must believe in its ability to deliver.

• It’s about risk, not leftover capacity. An item is Uncommitted because it involves uncertainty, not because it might be done if time allows. All PI Objectives - Committed or Uncommitted - are planned based on the Team’s available capacity and current understanding.
• At least one Uncommitted Objective is normal. Teams are encouraged to challenge themselves. A general guideline is to include at least one Uncommitted Objective per Team per PI. Risk is part of the game.
• Dependencies increase risk. Dependencies don’t automatically make an objective Uncommitted, but they’re a strong indicator. Ask: How reliable is the dependent Team or vendor? What’s the history? What confidence do we have in this dependency?
• Uncommitted Objectives often (but not always) have a recorded risk. If an item is Uncommitted due to risk, capture that risk explicitly. Even ROAMed risks might still warrant an Uncommitted status if uncertainty remains high.
• Don’t be overly risk-averse. There’s always some uncertainty about the future. But not everything is “high risk.” The question to ask: Given what we know today, is there significant risk to delivering this outcome?

One way to improve the evaluation of risk is by assessing uncertainty across a scale:

• Very Low: Everyone’s done this before.
• Low: Many Teams (including ours) have done this.
• Medium: We haven’t, but someone in our company has.
• High: Done outside the company, but not internally.
• Very High: Nobody (that we know of) has done this before.

Teams can use this continuum to calibrate what they consider “significant risk” for marking an item as Uncommitted.

While every product is different, here are example categories of risk (adapted from SVPG):

• Product Risk – Is the solution valuable, usable, viable, and feasible?
• Delivery Risk – Can it perform, scale, and meet security/privacy needs?
• Project Risk – Will it fit within the schedule, budget, or scope? Is there alignment?

Teams may not need to formally assess every risk, but having a shared language and mindset about risk tolerance is crucial.

• How Do We Write Great PI Objectives
• How can we put an estimate on complexity? - for a slightly different use of the risk scale