Jira Sprint Distribution Rules — Ghasi Melmastoon
Companion: Roadmap Index · jira-epic-based-sprint-ruleset.md · team-capacity-model.md · service-readiness-gates.md · docs/standards/JIRA_PROJECT_SETUP.md
This document is the per-component capacity allocator for sprint planning. Where jira-epic-based-sprint-ruleset.md decides which slices ship in which sprint, this document decides how much of each component's capacity can be committed to those slices, and what to do when demand exceeds capacity.
It is enforced by the sprint planner — human or commands/jira-sprint-plan.md — and verified during sprint review.
1. Capacity inputs
The planner reads three inputs at the start of each sprint:
- Per-engineer availability for the sprint (PTO, on-call, hiring loops) from
team-capacity-model.md. - Per-component headcount map (which engineers own which components) from
team-capacity-model.md. - Refined backlog filtered by
wave:r<N>and grouped by primary component.
It then runs the rules in §2 to produce the candidate sprint.
2. Distribution rules (top-down)
Rule A — Component focus per engineer
- Every engineer has at most 2 components of focus per sprint.
- An engineer assigned to ≥ 3 components signals a hiring or component-merge problem; flagged in retro.
Rule B — Service-line caps (per sprint)
| Component bucket | Max % of total sprint capacity | Rationale |
|---|---|---|
Any single microservice (e.g., reservation-service) | 25 % | Prevents single-service work crowding out platform / frontend / cross-cutting. |
All BFFs combined (bff-consumer, bff-tenant-booking, bff-backoffice) | 30 % | BFFs follow the surface stories; they should never lead. |
All frontend apps combined (app-web-meta, app-web-tenant-booking, app-mobile, app-desktop-backoffice) | 35 % | Frontend lands behind BFF + service primitives; bursts only when a wave's slice is UI-heavy. |
| Any single frontend app | 20 % | Same reasoning as Rule B for services. |
All shared packages (pkg-*) | 20 % | Prevents library work from displacing user-facing slices. |
All infra components (infra-*) | 20 % | Infra is enabler work; should be small slices that compound. |
cross-cutting | 10 % | Standards, ADRs, doc-debt — important but should be steady, not spiky. |
A planning cycle that exceeds any cap forces a rebalance: re-pull stories until the cap is satisfied, or document an explicit waiver in the sprint goal (e.g., "this sprint is a frontend-heavy push for the booking UX freeze; app-web-tenant-booking is at 30 %").
Rule C — Wave focus
- 100 % of pulled stories carry the same
Wavelabel as the sprint. (Hard-enforced; no exceptions.) - Cross-wave platform investments (e.g., a new ESLint rule needed by R2 but worked on during R1) are pulled as
Taskitems undercross-cutting, not as wave-tagged stories.
Rule D — Slice continuity
If a sprint pulls a slice from epic E1, the next sprint must pull the next slice of E1 (or close E1) unless:
- The next slice is blocked by a service-readiness gate, or
- The wave plan explicitly re-prioritizes E2.
Stalled epics (no progress for 3 consecutive sprints) are escalated at refinement and either resourced or descoped.
Rule E — Dependency direction
A story's services must be in a state that allows the story to land:
- All upstream services (those producing events the new story consumes) must be at
service-readiness:phase-N≥ what this story requires. - A story that requires an upstream not-yet-ready is deferred to the sprint after the upstream's readiness ticket lands.
- Cross-team prerequisites are documented in
service-readiness-gates.md.
Rule F — Risk-weighted pulls
Stories with risk score ≥ 7 consume 1.5× their story points against capacity (security/payment/lock work has hidden review cost). The planner explicitly accounts for the surcharge.
Rule G — Bug budget reservation
- 10 % of total sprint capacity reserved for bugs (S1–S3).
- S1 bugs always preempt scope; pull a story out to make room.
- Unused budget at sprint mid-point can be redirected to
cross-cuttingTasks (tech debt, doc cleanup).
Rule H — Spike budget cap
- ≤ 20 % of any single component's sprint capacity on spikes.
- ≤ 1 spike per component per sprint (combine related questions in refinement).
Rule I — On-call carve-out
- The on-call engineer's week 1 capacity is 50 % of nominal; week 2 is full.
- Plan with this carve-out built in.
Rule J — Sprint cadence smoothing
The planner aims for velocity stability: the difference between consecutive sprints' committed points should not exceed 20 %. Large jumps signal capacity miscount, scope inflation, or team change.
3. Distribution per wave (illustrative defaults)
These are defaults applied when the planner has no overriding signal. They reflect the wave's character.
R1 — Foundations (months 1–6)
| Bucket | Default share of sprint capacity | Notes |
|---|---|---|
| Platform services (R1 set of 15 services) | 35 % | Building the backbone. |
| BFFs (3) | 15 % | Following the service primitives. |
| Frontend apps (4) | 30 % | Landing real surfaces; tenant-booking + desktop are the two heaviest. |
| Shared packages | 10 % | Design system, contracts, primitives. |
| Infra | 7 % | Cloud Run, Cloud SQL, Pub/Sub, Secret Manager, observability baseline. |
cross-cutting | 3 % | Standards, ADRs, runbooks. |
R2 — Scale and AI (months 7–12)
| Bucket | Default share of sprint capacity | Notes |
|---|---|---|
| Platform services (full 22) | 30 % | Including analytics-service, ai-orchestrator-service ramp-up, maintenance-service. |
| BFFs | 15 % | Adding chain-switcher, multi-property, analytics surfaces. |
| Frontend apps | 25 % | Mobile maturation; desktop kiosk; tenant booking polish. |
| Shared packages | 12 % | UI maturation, API surface freeze for v1. |
| Infra | 12 % | Multi-region, secondary GCP, Cloud Armor, KMS rotation, FinOps. |
cross-cutting | 6 % | ADRs for AI gateway, multi-tenant observability, governance. |
R3 and beyond — White-label, kiosk, voice (Year 1.5+)
| Bucket | Default share of sprint capacity | Notes |
|---|---|---|
| Platform services | 25 % | New surfaces (reseller, kiosk, owner portal). |
| BFFs | 12 % | New BFFs as new surfaces emerge (1–2 net-new). |
| Frontend apps | 30 % | React-Native staff sub-app; kiosk; voice surfaces. |
| Shared packages | 15 % | Design tokens v2, motion library, voice primitives. |
| Infra | 12 % | GCC + Europe regions, FinOps maturation, edge LLM packaging. |
cross-cutting | 6 % | White-label governance, partner program docs. |
4. Worked example — sprint R1-S05
Wave: R1.
Capacity (squad of 7 engineers, 2-week sprint): ~140 dev-days at 60 % focus factor → 84 effective dev-days.
Goal: Ship the confirm slice of EP-MEL-04 end-to-end + introduce card payments for EP-MEL-05.
| Component | Pulled stories (excerpt) | Points | % of capacity |
|---|---|---|---|
reservation-service | US-MEL-0032 confirm; US-MEL-0030/0031 carryover finalization | 18 | 21 % |
payment-gateway-service | US-MEL-0042 Stripe card + 3DS | 13 | 15 % |
bff-tenant-booking-service | confirm route + payment selection | 10 | 12 % |
bff-backoffice-service | front-desk confirm view | 7 | 8 % |
app-web-tenant-booking | confirm screen + 3DS challenge | 13 | 15 % |
app-desktop-backoffice | front-desk confirm screen | 8 | 10 % |
pkg-ui-melmastoon | new <PaymentMethodCard />, <3DSChallenge /> primitives | 5 | 6 % |
notification-service | confirmation email template (en/ps/dr/ar) | 5 | 6 % |
| Bugs reserved | — | 5 | 6 % |
cross-cutting (ADR-0011 dummy ADR for confirm-saga) | — | 1 | 1 % |
| Total | 85 | ~100 % |
Rule checks: ✅ single-wave; ✅ no component > 25 %; ✅ BFFs combined = 20 % ≤ 30 %; ✅ all apps combined = 25 % ≤ 35 %; ✅ shared pkg = 6 % ≤ 20 %; ✅ bug reserve at 6 %; ✅ no spike. Sprint passes.
5. Demand-vs-capacity escalations
When refined demand for a component exceeds its sprint cap for two consecutive sprints:
- First sprint — planner caps demand at the rule cap; surplus rolls to next sprint with a comment.
- Second sprint — escalation triggers at refinement: either (a) re-resource the component (assign or hire), (b) reduce the wave's scope for that component (descope a story to a follow-up wave), or (c) loosen the cap with a written ADR-grade justification (rare; requires sign-off from two component leads).
The planner emits an explicit warning when triggering escalation. AI-driven planning (commands/jira-sprint-plan.md) refuses to commit a sprint that would violate a cap without a recorded waiver.
6. Per-component cap-tightenings (live)
The defaults in §3 apply unless a tightening is in force. Tightenings live below and are reviewed at every wave checkpoint.
| Component | Tightened cap | Reason | Review at |
|---|---|---|---|
lock-integration-service | ≤ 18 % | High vendor-coupled risk; surge requires security-reviewer carve-out. | R1 wave checkpoint |
payment-gateway-service | ≤ 18 % | Same as lock; PCI scope concentration. | R1 wave checkpoint |
ai-orchestrator-service (R1) | ≤ 5 % | R1 ships only edge anomaly detection; full orchestrator is R2 work. | Start of R2 |
cross-cutting | ≤ 10 % | Already capped; tightening reaffirms during refinement debt accumulation. | Every retro |
7. Carry-over and scope-add accounting
| Metric | Target | Trigger if exceeded |
|---|---|---|
| Carry-over % (committed points not Done at sprint end) | < 10 % | Retro signal; review story sizing and DoR rigor. |
| Scope-add % (points added mid-sprint) | < 5 % | Retro signal; review DoR + sprint goal coherence. |
| Bug burn % (sprint capacity actually spent on bugs) | < 15 % | Quality retro; root-cause the most expensive bug class. |
| Capacity overrun (effective points / planned) | 95–110 % | Calibration adjustment to focus factor. |
Metrics are written into the sprint retro template and tracked over time in docs/observability/sprint-flow-dashboard.md (planned).
8. Cross-references
- jira-epic-based-sprint-ruleset.md — slice composition.
- team-capacity-model.md — squads and headcount.
- service-readiness-gates.md — cross-service prerequisites.
- docs/standards/JIRA_PROJECT_SETUP.md — Jira project + JQL filters.
commands/jira-sprint-plan.md(Wave 2) — agent that applies these rules.
9. Versioning
Same governance as docs/standards/CODING_STANDARDS.md §19. Cap changes require sign-off from every affected component lead.