Tirsvad
b0a7414204
Business Case, Stakeholder Analysis, Project Plan and milestone MIL-001 with review records RC-001 to RC-003, then the Python project: PrettyTable Pokemon table, constants, pytest tests, pyproject.toml, Doxyfile, CI workflow and README. Task: MIL-001#1 Task: MIL-001#2 Task: MIL-001#3 Task: MIL-001#4 Task: MIL-001#5 Task: MIL-001#6 Task: MIL-001#7 Task: MIL-001#8
2.6 KiB
2.6 KiB
Milestone / Gateway (MIL)
Cite in CrossReference only if the instance exists (new-artifact.sh checks this for you):
- BC — The objective / constraint (e.g. project duration) the milestone traces to
- KPI — The KPI IDs evaluated at this gate
- US — Forward: the user stories (
US-<v>.<NN>) that deliver this gateway
Required sections (after Metadata / Version History)
- Purpose — what decision this gate supports.
- Deliverable — the concrete, tangible output evaluated (never just a date).
- Go / No-Go Criteria — objectively checkable, one per row.
- Dependencies — other milestones that must precede this one.
- Traceability — the Business Case objective and/or KPI ID(s) it maps to.
- Ownership — owner and approving reviewer as
SAstakeholder IDs. - Target Date — consistent with Business Case constraints.
- Tasks — the implementation-level breakdown for this phase, one row
per task:
# | Task | Summary | Needs its own Use Case/User Story? | Reference.Taskis a short title (becomes the Issue title on sync);Summaryis one to three sentences of real context — what the task actually involves and why, grounded in this project's own documents, not a restatement of the title — so someone reading the Issue on Gitea/GitHub understands it without opening this file (becomes the Issue body).
Breaking a phase into tasks
Not every task needs a use case — only model one when the task is something a user, or another system, actually does:
- Needs a use case/user story — "User resets password", "Admin exports
customer report", "Payment service processes refund". Set the column to
Yesand put theUS-…/UC-…ID in Reference. - Plain task, no use case — "Refactor authentication middleware", "Add
database index", "Upgrade React version", "Fix null-pointer bug", "Add
unit tests", "Configure CI pipeline", "Optimize SQL query". Set the column
to
Noand leave Reference blank, or point at the design artifact it implements (DCD-…,OC-…).
The hierarchy is: Business goal → Feature/requirement → Use case/user story → Tasks. The use case explains why a feature exists; tasks explain how the team implements it — most tasks stay at that level.
Syncing to Gitea/GitHub
Each MIL-* gateway becomes one Milestone on the git host; its ## Tasks
row become Issues assigned to that milestone. Use the project-planning
skill and framework/scripts/sync-project.sh — do not create these by hand.