Eleven Days to PI Planning

Order by lead time and by what blocks planning itself.

• Days 1-4: backlog readiness with the PM. Triage the 14 unready features into (a) ready enough - write the acceptance criteria and benefit hypothesis now, and (b) not ready - pull them from this PI and leave them in the funnel. Planning unready features produces confident-looking estimates and false commitments. Also agree the top 10-12 by WSJF so teams plan from a prioritized subset rather than all 23.
• Days 1-5: capacity and dependency pre-work. Confirm the 96 points and be able to explain why (holiday, leave) with the arithmetic, because you will defend it in the room. Run a dependency identification session across the six POs.
• Days 5-8: external dependency. Invite the data-science team to Day 1 or a 45-minute dependency slot; prepare a fallback (named liaison engineer, agreed interface, mock data).
• Days 9-11: your draft PI objectives - but as inputs to the team, not published commitments. The PM's draft is a useful starting hypothesis, not a decree.

What can wait: detailed estimation and task breakdown, which is what planning Day 1 is for, and any solution design that the team should own.

The trap is spending the 11 days writing stories yourself and arriving at planning with a polished backlog nobody has discussed. Readiness is a conversation, not a document.

Bring 96, not 120. The historical average is a velocity observation, not a capacity plan, and planning to 120 would be planning to work that nobody is there to do.

Mechanics:

1. Plan to roughly 85-90% of 96 (about 82-86 points) to leave room for unplanned work, dependencies, and the usual friction. Show the gap and its reason on the capacity slide.
2. Negotiate with the PM before planning, using priority rather than optimism. Make the statement concrete: at 96 points this PI covers the top N features; features X and Y do not fit. That conversation is far cheaper on Day -5 than in the System Demo.
3. Use uncommitted/stretch objectives for anything beyond the committed load, with an explicit risk statement, so committed PI objectives stay honest.
4. Let the confidence vote do its job. A 2-finger vote on Day 2 is the signal you over-planned; treat it as information, not as defiance.

Avoid three tempting moves: inflating estimates to protect the team (it corrupts the baseline for the next PI), quietly absorbing the gap as overtime, and letting the Business Owners discover the shortfall at the System Demo. The first two feel like advocacy; they are actually deferred conflict.

You cannot plan a dependency with someone who is not in the room, so the first move is to get a person, not a promise.

1. Request attendance: a named engineer from the data-science team for Day 1 plus the dependency breakout. If they decline, ask for a 30-minute pre-planning call and a written interface agreement.
2. Model it as a dependency, not an assumption. Define the interface contract - inputs, outputs, format, latency, refresh cadence, mock data - so your team can build against a stub instead of idling.
3. Put it on the dependency board with an owner, a needed-by date, and a risk statement. The RTE carries it to ART sync; you don't own cross-org escalation alone.
4. Plan a fallback: for example, rules-based scoring behind a toggle for the first release, so the feature is demonstrable without the model.
5. Reflect it in the PI objective as a stated assumption ('assuming fraud model v1 by Iteration 3.2'), so Business Owners see the risk rather than discovering it.

The trap is planning as though the dependency will resolve itself, or hiding it in a 'stretch' bucket. Unowned cross-organizational dependencies are one of the most common causes of missed PI objectives, and they are invisible in the plan right up until they fail.