Do you make scope changes to a PBI visible?

When the scope of a PBI changes, everyone affected must be able to see what changed, why it changed, and who agreed to it.

It’s common to discover extra work once implementation starts. That’s fine… silent scope changes are not.

Why this matters

• PBIs drive expectations, estimates, and priorities. Uncommunicated scope changes create risk and confusion
• People may just watch the recording (when the PBI was created by YakShaver) so the new requirements might not be noticed in the original context unless you explicitly surface the change

What to do when scope changes

If you realize an additional task should be part of an existing PBI:

1. Confirm alignment first - Ideally, a scope change should be agreed with someone beforehand (e.g. “as discussed with Dave in today’s stand-up”)
2. **Document by updating the Acceptance Criteria **- Make the scope change explicit by editing the Issue description
3. **Leave a clear comment explaining the change **- Explain what was added or changed, the reason for the change, and who was involved in agreeing to it. The updated scope is clear, traceable, and visible to everyone
4. **CC the right people **- Notify anyone impacted, including PBI creator, assignees, the Product Owner, reviewers, and stakeholders

✅ Figure: Good example - New requirement has been added to the existing Acceptance Criteria

✅ Figure: Good example - Comment left to inform about the change