SAFe POPM study materials
SAFe POPM study resources

Day 2, Two Fingers

SAFe POPM · Put your knowledge to work in context.

All case studies

Day 2, Two Fingers

It is Day 2 of PI Planning for a four-team ART. The confidence vote returns with three teams at 3 fingers and one at 2. During the break, a Business Owner learns a competitor has announced a real-time fraud alerts feature and asks the room to 'just fold in' three related features; two teams are already planned to capacity. Separately, you learn the VP of Engineering pre-assigned two features to specific teams last week so that planning would 'go faster'. The RTE looks at you to run the next 20 minutes.

1. As the PO/PM lead facilitating, what do you do with the Business Owner's request while the room is still together?

Read the worked answer

The Business Owner genuinely owns scope and priority - that is the role. What they do not own is the capacity to deliver it, and the room's job is to make that visible without a fight.

Make the move in one sentence: 'Yes, we can prioritize fraud alerts - the question is what comes out.' Then run it quickly:

  1. Have the PM state the relative value (WSJF) of the three features against the bottom of each team's current plan.
  2. Ask the two full teams to size the new work at a high level only - minutes, not a re-plan.
  3. Put the arithmetic on the board: X points of new scope against roughly zero points of free capacity.
  4. Offer three options and let the Business Owner choose: substitute (drop lower-value planned features of equivalent size now), defer (plan for the next PI, start discovery this PI), or stretch (plan as uncommitted objectives with an explicit risk, accepting the committed objectives may slip).
  5. Record the decision in the planning output so it is traceable at Inspect & Adapt.

Do not accept the addition without a subtraction, and do not say 'we will find a way'. Unfunded scope is precisely how you generate a 2-finger vote, and you already have one.

The trap is defending the plan against the Business Owner. Your job is to make the trade-off legible, not to win the argument.

2. What is wrong with the VP's pre-assignment of features to specific teams, and what do you do about it now rather than later?

Read the worked answer

Pre-assignment breaks two things at once. First, it removes the team's ownership of the plan: teams pull and self-organize the work, which is why the resulting plan earns a real confidence vote. A plan handed down gets a polite nod and no commitment. Second, it hides capacity and skill conflicts - the VP assigned from an org chart, not from who has the relevant domain experience or who is already loaded - and it typically arrives as a solution, foreclosing better options.

In the room, now: do not ambush the VP publicly. Restate the two features as ART-level priorities rather than team assignments, and ask each team to confirm or contest feasibility in the breakout. If a team genuinely cannot take one, that surfaces in the draft plan review with the RTE and Business Owners, and the work moves. Publicly airing it converts a fixable planning problem into a status problem.

After planning: agree a working agreement for the next PI - leadership sets business context and priorities; PMs bring the prioritized feature set; teams pull. Raise it at the retrospective/Inspect & Adapt with the evidence from this planning so it is a lesson rather than an accusation.

Two traps: silently complying, which leaves you owning a plan the team does not believe; and winning the point publicly, which costs you the VP's support on the next three things you need.

3. One team voted 2. What does the planning process require, and how do you resolve it without pressuring the team?

Read the worked answer

Three fingers and above signals reasonable confidence; a 2 must not be waved through. The process requires the team to state its concerns, the room to address them, and the team to re-vote.

Your job is to extract the reason in specifics: unclear feature, missing dependency, insufficient capacity, unfamiliar technology, or missing skills. Given the day you have just had, the likely root causes are exactly the two interventions above - scope added without subtraction, and work assigned rather than pulled.

Resolve by changing the plan, not the vote:

  • reduce scope on that team, or move a feature to a team with capacity;
  • plan a spike for the technical unknown;
  • move a contested item to uncommitted;
  • re-check the dependency assumptions that team is carrying.

Then re-vote. If it is still 2, take it to the management review with the risk statement attached. A known risk on the board is manageable; a suppressed vote is not.

The trap is asking the team to 'vote their confidence up' so the room can finish on time. The vote is an information channel. Closing it means the first signal you get about the problem is a missed PI objective in week 8, when there is no room left to trade.