DWSD.md
v1.0

PI Commitment

type
agreement
agreement-type
work
for-domain
Charger ART
agreement-of
Charger ART Board › Feature › In PI
version
1.0
decision_date
2026-01-12
review_date
2027-01-11
created_at
2026-10-10

Driver and Requirement

A PI is a promise a whole train makes together. If features can enter mid-PI whenever someone asks, the dependency board from PI planning is fiction within a month and the platform teams are pulled in three directions. The train needs a rule for what may change inside the ten weeks, and who may change it.

Who is responsible for what?

  • Product Management — brings new features to PI planning, not into a running PI.
  • Business Owners — the only ones who may add or cut a feature mid-PI, and only against a stated business reason.
  • Release Train Engineer — makes every mid-PI change visible on the board and at the next ART Sync.
  • The teams — may re-sequence their own stories freely; may not take on a new feature without the above.

Description

Features enter the In PI group of the Charger ART Board at PI planning. During the PI, the group’s content changes only by a Business Owner decision, recorded on the card. Hotfixes are exempt: they travel the expedite lane under the Expedite Lane Policy, not this agreement.

Evaluation Criteria

  • PI predictability at or above 80% of committed objectives.
  • Mid-PI feature changes per PI: visible, with a named Business Owner each; fewer than three.

Concerns

Hardware does not always fit a ten-week box: a tooling slip is not a scope change anyone decided, yet it moves a feature out of the PI. The rule covers decisions, not lead times.

Like what you see? → Start — build your own org folder in ~2 min

PI Commitment.md
---
type: agreement
agreement-type: work
for-domain: "[[Charger ART]]"
agreement-of: "[[Charger ART Board]]#Charger ART/lane:Feature/group:In PI::in"
version: "1.0"
decision_date: 2026-01-12
review_date: 2027-01-11
created_at: 2026-10-10
---
## Driver and Requirement


A PI is a promise a whole train makes together. If features can enter mid-PI whenever someone
asks, the dependency board from PI planning is fiction within a month and the platform
teams are pulled in three directions. The train needs a rule for what may change inside
the ten weeks, and who may change it.


## Who is responsible for what?


- [[Product Management]] — brings new features to PI planning, not into a running PI.
- [[Business Owner]]s — the only ones who may add or cut a feature mid-PI, and only against
  a stated business reason.
- [[Release Train Engineer]] — makes every mid-PI change visible on the board and at the
  next [[ART Sync]].
- The teams — may re-sequence their own stories freely; may not take on a new feature
  without the above.


## Description


Features enter the `In PI` group of the [[Charger ART Board]] at PI planning. During the
PI, the group's content changes only by a [[Business Owner]] decision, recorded on the
card. Hotfixes are exempt: they travel the expedite lane under the
[[Expedite Lane Policy]], not this agreement.


## Evaluation Criteria


- PI predictability at or above 80% of committed objectives.
- Mid-PI feature changes per PI: visible, with a named Business Owner each; fewer than
  three.


## Concerns


Hardware does not always fit a ten-week box: a tooling slip is not a scope change anyone
decided, yet it moves a feature out of the PI. The rule covers decisions, not lead times.