Jira Epic-Based Sprint Ruleset — Ghasi Melmastoon
Companion: Roadmap Index · jira-sprint-distribution-rules.md · team-capacity-model.md · service-readiness-gates.md · docs/standards/JIRA_PROJECT_SETUP.md · docs/07-epics-and-user-stories.md
This document defines how epics decompose into sprints for Ghasi Melmastoon. It is the rulebook used by the sprint planner — human or commands/jira-sprint-plan.md agent — to take the Refined backlog and assemble the next sprint without violating wave boundaries, service ownership, or readiness gates.
It works in concert with:
jira-sprint-distribution-rules.md— how much each component gets per sprint.team-capacity-model.md— who has capacity for what.service-readiness-gates.md— what cross-service prerequisites must already be Done.
If this document and the live sprint disagree, fix the sprint.
1. Sprint cadence and naming
| Setting | Value |
|---|---|
| Sprint length | 2 weeks, Sun–Thu primary calendar (Afghanistan), Mon–Fri reference (international). |
| Sprint name | R<N>-S<NN> — wave + zero-padded sprint ordinal. Example: R1-S03. |
| Sprint goal | One sentence; references the wave outcome + the dominant epic(s). Posted in Jira sprint goal field. |
| Sprint review | Last Wednesday of the sprint, 60 min, all components present. |
| Sprint retro | Thursday after review, 45 min, focus on flow + DoR/DoD violations. |
| Sprint planning | Sunday before sprint starts, 60 min, capacity-driven. |
| Refinement | Tuesday + Thursday, 30 min each, no exceptions. |
No mid-sprint extensions. Slipped scope rolls to the next sprint with a comment on the ticket.
2. Epic-to-sprint decomposition principles
Each of the 20 EP-MEL-NN epics is too large to ship in a single sprint. The decomposition rules:
2.1 Vertical slicing (preferred)
Slice an epic into end-to-end vertical slices: each slice spans every layer (DB → service → BFF → frontend) and delivers one user-observable outcome.
Example for EP-MEL-04 (Reservation Lifecycle):
| Sprint | Slice | Stories |
|---|---|---|
R1-S02 | Quote | US-MEL-0030 (generate price quote with TTL) |
R1-S03 | Hold | US-MEL-0031 (place inventory hold for quote) |
R1-S04 | Confirm | US-MEL-0032 (confirm reservation with payment outcome) |
R1-S05 | Modify + Cancel | US-MEL-0033, US-MEL-0034 |
R1-S06 | Stay (check-in / mid-stay / checkout) | US-MEL-0036, US-MEL-0037, US-MEL-0038 |
R1-S07 | Edge cases (walk-in / no-show / group) | US-MEL-0039, US-MEL-0040, US-MEL-0041 |
Each sprint produces a demo-able outcome.
2.2 Horizontal slicing (only when forced)
Horizontal slicing — landing the DB and service layer first, then the API, then the UI — is allowed only when:
- The data model alone delivers measurable value (e.g., enabling a backfill or analytics signal).
- A vertical slice would exceed the sprint capacity even at the smallest meaningful outcome.
- A cross-service prerequisite blocks the vertical slice (then the horizontal pieces become Tasks under the parent Story).
When horizontal, every horizontal story carries an Out of scope bullet stating which layer it does not ship, with a link to the follow-up story.
2.3 Cross-service stories
A story listed against multiple services either:
- Stays as a single Story with the primary owner driving and the participating services adding sub-tasks. Used when the change is small per service and parallel work is feasible.
- Decomposes into per-service Stories linked back to the parent Epic + a parent "umbrella" Task labeled
umbrella. Used when each per-service slice is itself ≥ M complexity.
The decision is made at refinement and recorded as a comment on the parent.
3. Sprint composition rules
A sprint is valid if:
- Single wave — every story has the same
Wavelabel as the sprint (R1-S03⇒wave:r1). - Refined-only — every pulled ticket is in state
Refined(DoR met). Tickets inBacklogare forbidden in sprint plans. - Capacity respected — total story points ≤ sprint capacity (per
team-capacity-model.md). - Distribution respected — per-component distribution ≤ caps in
jira-sprint-distribution-rules.md. - Readiness respected — every story whose service has a readiness prerequisite (per
service-readiness-gates.md) must wait until the prerequisite is Done. - Cohesive — at least 60 % of the story points roll up to the dominant epic for the sprint. The dominant epic is named in the sprint goal.
- At most 1 spike per service per sprint. Spikes do not exceed 20 % of a service's sprint capacity.
- Bug budget — at least 10 % of capacity reserved for bugs. Unused budget can be spent at sprint mid-point on a Task or descope to capacity-trim.
- No XL — XL complexity is forbidden anywhere in the system; if one slipped in, it must be split before sprint pull.
- Workflow-bridging stories closed first — if a sprint includes a story whose
Linked Workflow IDmatches an in-flight workflow E2E gate, it is sequenced ahead of stories that depend on it.
4. Sprint goal pattern
"Ship the
of end-to-end so that can in the live R environment."
Examples:
R1-S04: "Ship the confirm slice of EP-MEL-04 (Reservation Lifecycle) end-to-end so that a Guest can confirm a tenant booking with payment in the live R1 environment."R1-S05: "Ship the modify and cancel slices of EP-MEL-04 so a Guest can change or cancel within policy in the live R1 environment, while introducing the refund path for EP-MEL-05 (Payment Gateway)."
A goal that names two epics is fine if and only if the secondary epic's contribution is ≤ 30 % of capacity. Three-epic goals are forbidden.
5. Story sizing reference (for sprint math)
| Complexity | Story points | Time estimate (one engineer) | Notes |
|---|---|---|---|
| S | 2 | ≤ 2 dev-days | Single-file change scope; one AC scenario; unit tests only or unit + one integration. |
| M | 5 | ≤ 5 dev-days | Multi-file change; 2–3 AC scenarios; unit + integration + at least one contract test. |
| L | 8 | ≤ 12 dev-days | Multi-service or full vertical slice; 3–5 AC scenarios; full test pyramid including E2E. |
A sprint usually contains 4–8 stories per engineer at a 60–70 % focus factor (see team-capacity-model.md for the live model).
6. Decomposition templates per epic (R1-relevant)
Each epic gets a recommended decomposition into ≤ 4 sprint slices. These are templates — the Refinement crew can deviate with a recorded reason.
EP-MEL-01 — Tenant Onboarding & Configuration
| Slice | Stories (excerpt) | Sprints |
|---|---|---|
| Owner sign-up + email/SMS verify | US-MEL-0001, US-MEL-0002 | 1 |
| Property + rooms + staff invite | US-MEL-0003, US-MEL-0004, US-MEL-0005 | 1 |
| Theme + content + booking-flow config | US-MEL-0006…0008 | 1 |
| Preview + publish + onboarding tracker | US-MEL-0009…0012 | 1 |
EP-MEL-02 — Consumer Meta Search
| Slice | Stories | Sprints |
|---|---|---|
| Search + filter + map | US-MEL-0013…0015 | 1 |
| Compare + summary cards | US-MEL-0016, US-MEL-0017 | 1 |
| Handoff + RTL + favorites | US-MEL-0018…0020 | 1 |
EP-MEL-03 — Tenant Booking Experience
| Slice | Stories | Sprints |
|---|---|---|
| Browse rooms + adjust qty/dates | US-MEL-0021, US-MEL-0022 | 1 |
| Special requests + payment selection | US-MEL-0023, US-MEL-0024 | 1 |
| Multi-currency + multi-language | US-MEL-0025, US-MEL-0026 | 1 |
| Confirmation + resend + telemetry | US-MEL-0027…0029 | 1 |
EP-MEL-04 — Reservation Lifecycle
| Slice | Stories | Sprints |
|---|---|---|
| Quote + Hold + Confirm | US-MEL-0030…0032 | 2 |
| Modify + Cancel + Upsell | US-MEL-0033…0035 | 1 |
| Check-in + Mid-stay + Checkout | US-MEL-0036…0038 | 2 |
| Walk-in + No-show + Group | US-MEL-0039…0041 | 1 |
EP-MEL-05 — Payment Gateway
| Slice | Stories | Sprints |
|---|---|---|
| Card + 3DS | US-MEL-0042 | 1 |
| Cash-on-arrival + EOD reconciliation | US-MEL-0044, US-MEL-0049 | 1 |
| MFS + Idempotent webhooks | US-MEL-0045, US-MEL-0048 | 1 |
| Refund + Chargeback | US-MEL-0046, US-MEL-0047 | 1 |
(Continue similarly for EP-MEL-06 … EP-MEL-20; templates living in this file are updated as we learn.)
7. Cross-epic ordering (the "first 12 sprints of R1" plan)
This is the recommended order in which slices land for R1. The actual sprint plan deviates as risks emerge but the order is the default.
| Sprint | Dominant epic / slice | Secondary work |
|---|---|---|
R1-S01 | EP-MEL-17 IAM (auth + RBAC + device-bind) | EP-MEL-20 Observability (telemetry baseline) |
R1-S02 | EP-MEL-01 Tenant onboarding (owner + property) | EP-MEL-12 Theme primitives (tokens) |
R1-S03 | EP-MEL-01 (theme + booking-flow config) | EP-MEL-12 Theming preview |
R1-S04 | EP-MEL-04 Reservation (quote + hold) | EP-MEL-04 Inventory allocation |
R1-S05 | EP-MEL-04 Reservation (confirm) | EP-MEL-05 Card payment |
R1-S06 | EP-MEL-04 Reservation (modify + cancel) | EP-MEL-05 Refund |
R1-S07 | EP-MEL-04 Reservation (check-in + checkout) | EP-MEL-09 Lock issuance (TTLock) |
R1-S08 | EP-MEL-06 Front-desk desktop (arrivals + walk-in) | EP-MEL-09 Lock revoke |
R1-S09 | EP-MEL-06 Front-desk desktop (folio + cash drawer) | EP-MEL-13 Reporting baseline |
R1-S10 | EP-MEL-10 Offline sync engine | EP-MEL-15 Notifications |
R1-S11 | EP-MEL-10 Offline sync (conflict + telemetry) | EP-MEL-07 Housekeeping basics |
R1-S12 | EP-MEL-13 Reports (financial + reg) + R1 hardening | EP-MEL-19 Compliance KYC |
(R2 and R3 plans live as appendices to 02-release-2-scale-and-ai.md and 03-release-3-and-beyond.md respectively.)
8. The 60/30/10 split (rule of thumb per sprint)
When in doubt, allocate per-engineer capacity inside a sprint as:
- 60 % dominant epic / dominant slice (where the wave goal is being earned).
- 30 % participating epic (the other epic the sprint touches, or platform work that unblocks the next sprint).
- 10 % bugs + unplanned + a thin slice of tech debt.
This is the planning ratio; actuals are tracked in retro. A team that systematically misses the dominant-epic ratio is signaling that the wave is under-resourced or the slice was oversized.
9. Multi-service slice handling
When a sprint pulls a story whose participating services span more than the dominant component:
- The primary owner writes the spec-aligned acceptance and seeds the test scaffolding.
- Each participating component lifts a sub-task (or a per-service Story under the umbrella Task) into the same sprint.
- The integration scenario (the cross-service AC) is owned by the primary; participating services own per-service unit + integration coverage.
- All sub-tasks must close in the same sprint as the parent. A parent that drags into the next sprint signals an oversized slice — split.
10. Definition of "Sprint Done"
A sprint is "done" if and only if:
- Sprint goal is satisfied (the dominant slice is shipped to the live R
environment). - Every committed Story is
Doneor, ifDeferred, has a comment explaining why and a follow-up ticket linked. - Every committed Bug is
Doneor escalated to S1. - Sprint-bug budget was not blown by > 50 % (else trigger a quality retro).
- No
dor:incompleteticket sneaked into the active sprint at any point. - No
dod:waivedticket merged without an ADR. - Per-component caps in
jira-sprint-distribution-rules.mdwere not exceeded. - Sprint health metrics (carry-over %, scope-add %, cycle time, PR cycle time, CI red %) recorded in retro.
11. Wave boundaries
- A sprint never mixes wave labels.
R1-S12cannot pullwave:r2work even if the engineer is idle. - The first sprint of a new wave (
R2-S01) cannot start until the previous wave's exit gate (perservice-readiness-gates.md+ the wave file's "Definition of done" §12) is binary green. - A wave that overruns slips into a "stabilization sprint" (
R1-S99-style) where the only allowed work is closing wave-exit gates. Stabilization sprints do not count toward velocity.
12. Anti-patterns (auto-flagged in retro)
- A sprint with > 5 epics represented (planning incoherence).
- A sprint with no E2E story but a frontend-heavy slice (likely missing acceptance).
- A sprint where the dominant epic accounts for < 40 % of capacity (goal mismatch).
- A sprint where bugs > 30 % of capacity (signal of recent quality regression).
- A sprint with > 25 % carry-over (signals oversize stories or capacity miscount).
- A story that bounced ≥ 3 times between
RefinedandBacklog(spec gap; escalate at refinement). - A sprint whose slice required a service whose readiness gate is not green (planning broke
service-readiness-gates.md).
13. Cross-references
- jira-sprint-distribution-rules.md — capacity allocation per component.
- team-capacity-model.md — squads, focus factor, headcount.
- service-readiness-gates.md — cross-service prerequisites.
- docs/standards/JIRA_PROJECT_SETUP.md — workflow + custom fields.
- docs/standards/REQUIREMENTS_GUARD_RAILS.md — DoR rules.
- docs/07-epics-and-user-stories.md — spec stories.
commands/jira-sprint-plan.md(Wave 2) — agent that applies these rules.
14. Versioning
Same governance as docs/standards/CODING_STANDARDS.md §19. Changes to caps, ratios, or the order in §7 require sign-off from each affected component lead.