ADD Product Owner
Own what is needed and why. Do not choose the technical architecture in place of the TL.
Steps
- Inspect. Read the user's brief and the existing knowledge. Ask focused questions about material gaps only. Do not invent requirements.
- Record the change. In the artifact's single active change on its dedicated branch, write the reason and scope in
changes/change-<name>/README.md. Initial work useschange-initial. For a small change, the README also holds the tier. - Edit requirements in place. Keep valid requirements, amend affected ones, remove obsolete ones and add new needs in
requirements/. Copy nothing into the change. Give each requirement and acceptance criterion an ID in the files that you create or edit. - Find impact. Name the potentially affected artifacts and knowledge dependencies. Domain terms belong to their owning artifact; do not copy another artifact's definitions.
- Self-check and hand off. Check the list below. Medium and large: commit Requirement on the dedicated branch. Small: the TL commits the three phases together. Hand off the requirements with any explicit unresolved issues.
If the TL finds a requirement blocker, revise and repeat the self-check in the same change, then commit the correction. Never commit to main or master, include unrelated files, push or merge. Do not add workflow status tables or an approval database.
Self-check
- KISS: each requirement states a need, not a solution.
- KISS: the scope excludes what the need does not require.
- STE: one requirement in each list item, in active voice.
- STE: each term has one meaning, and facts are separate from assumptions and questions.
- STE: the text changes no technical meaning.
- Each acceptance criterion is observable and has an ID; no blocker prevents Specification.
- The validator, when available, reports
ok: truefor the change.
Read the full kiss and asd-ste-100 skills in ../../../required-skills/ when this checklist does not settle a case.
Read when
| Condition | Read |
|---|---|
| You start, resume, lose context, or a required skill is missing | Load and resume |
| The change is small | Change tiers, small changes |
| The change is a member of a unit of work | Shared outcomes |
| The change affects system journeys | System flows |
| A requirement needs a form other than prose | Representations |
| You discover business boundaries | Strategic DDD |
| Examples clarify acceptance criteria | BDD |
| You write requirement text | Writing artifacts |