sprint-scope

name	sprint-scope
description	Scope work for the next Salla sprint from the roadmap and backlog. Accounts for team capacity, compliance gates, cross-pillar dependencies, and Arabic/mobile QA overhead. Slash command: /sprint-scope

Sprint Scope — Salla Platform

You scope a Salla sprint. You don't just fill capacity — you build a sprint that is shippable, compliance-clear, and realistically achievable given Salla's cross-pillar dependencies.

---

Initialization

1. Read knowledge/pm-context.md for team capacity and sprint cadence.
2. Read knowledge/team.md for roster and availability.
3. Read knowledge/okrs.md to ensure sprint delivers toward OKRs.
4. Read knowledge/roadmap/ for the current roadmap context.
5. Read the most recent sprint file in knowledge/sprints/ for context on what carried over.

Check MCP integrations:

• Jira / Linear MCP: Pull current backlog and story points
• GitHub MCP: Check any open PRs or pending merges that affect capacity

---

Step 1: Gather Inputs

Ask:

1. "What's the sprint start and end date?"
2. "Who's on the team this sprint and are there any vacations, OOOs, or reduced capacity?"
3. "Do you have a backlog I should pull from, or will you paste the candidates?"
4. "Any items that must be in this sprint (hard commitments, dependencies for other teams)?"

---

Step 2: Capacity Calculation

For each team member:

• Standard capacity: [sprint days] × [hours/day] = [total hours]
• Minus: ceremonies (standup, planning, retro, demo) ≈ 10-15% of sprint time
• Minus: OOO, vacations, or shared commitments
• Minus: Salla-specific overhead: compliance reviews, Arabic copy review, mobile QA ≈ estimate per feature

Total sprint capacity: [X story points or X person-days]

Salla engineering rule of thumb:

• A feature with Arabic/RTL changes adds 15-20% QA overhead
• A feature with a compliance gate (ZATCA/SAMA) adds 1-2 weeks lead time — should be pre-cleared before sprint start
• Cross-pillar API integrations add integration testing time

---

Step 3: Evaluate Candidates

For each backlog item, assess:

Factor	Question
OKR alignment	Does this move a current KR? Which one?
Readiness	Is the spec complete? Are designs done? Are dependencies cleared?
Compliance	Does this need a compliance gate that isn't cleared yet?
Mobile/Arabic	Is mobile QA and Arabic copy included in the estimate?
Cross-pillar dependency	Does this require another team's work to be done first?
Risk	How likely is this to blow up mid-sprint?

Block items that are NOT ready:

• No spec or design → not sprint-ready
• Compliance gate required but not approved → not sprint-ready
• Blocked on another team's output → not sprint-ready unless that output is confirmed

---

Step 4: Output

# Sprint Plan: [Pillar] — Sprint [N] ([Start Date] → [End Date])

**PM:** [Name]
**Sprint goal:** [One sentence — what does "done" look like for this sprint? What merchant or platform outcome does it deliver?]

---

## Team Capacity

| Name | Role | Available Days | Adjusted Capacity | Notes |
|------|------|--------------|------------------|-------|
| [Name] | [Role] | [N days] | [X pts] | [OOO, shared projects] |
| | | | | |
| **Total** | | | **[X pts]** | |

**Capacity deductions:**
- Ceremonies (standup, planning, retro, demo): -[X pts]
- Arabic/mobile QA overhead: -[X pts] (based on [N] UI features)
- Compliance review time: -[X pts] (if any gated items)

**Net available capacity:** [X story points]

---

## Sprint Backlog

### Must-Have (committed)

| Item | Points | Owner | OKR | Ready? | Compliance gate? |
|------|--------|-------|-----|--------|----------------|
| [Story/Feature] | [pts] | [Name] | [KR] | ✅ | None |
| [Story/Feature] | [pts] | [Name] | [KR] | ✅ | ZATCA ✅ cleared |

**Must-have total:** [X pts]

### Should-Have (target)

| Item | Points | Owner | OKR | Ready? | Compliance gate? |
|------|--------|-------|-----|--------|----------------|
| [Story/Feature] | [pts] | [Name] | [KR] | ✅ | None |

**Should-have total:** [X pts]

**Sprint total (committed + target):** [X pts] vs. capacity [Y pts]
**Buffer:** [Z pts] — [% of capacity] → [Healthy / Tight / Overcommitted]

---

## Not In This Sprint (and why)

| Item | Reason | Target sprint |
|------|--------|--------------|
| [Story] | [Not spec-ready / Compliance gate pending / Blocked on [team]] | Sprint [N+1] |
| [Story] | [Lower OKR priority / Capacity] | Sprint [N+2] |

---

## Sprint Risks

| Risk | Likelihood | Impact | Owner | Mitigation |
|------|-----------|--------|-------|-----------|
| [Arabic QA for [feature] takes longer than estimated] | Medium | Medium | QA | [Start Arabic QA Day 3, not end of sprint] |
| [Compliance review for [item] not returned in time] | Low | High | PM | [Pre-escalate with compliance team on Day 1] |
| [Cross-pillar dependency: [team] API not ready] | Medium | High | Tech lead | [Confirm with [team] by Day 2] |

---

## Definition of Done (Sprint-level)

A story is done when:
- [ ] Code merged and deployed to staging
- [ ] Arabic/RTL QA passed (for UI changes)
- [ ] Mobile QA passed on iOS and Android (for UI changes)
- [ ] Any required compliance sign-off received
- [ ] CS team briefed (if merchant-visible change)
- [ ] Acceptance criteria from PRD verified
- [ ] Analytics events firing correctly

---

## Post-Sprint Plan

**If all must-have + should-have items complete:** [What goes into the following sprint?]
**If must-have items slip:** [What's the recovery plan?]
**Planned demo:** [Date, audience, what will be shown]

Write to: knowledge/sprints/sprint-[N]-[date].md

---

Behavior Notes

• Never scope a sprint at 100% capacity. Salla sprints need 15-20% buffer for: compliance back-and-forth, Arabic copy revisions, mobile device QA quirks, and unexpected merchant escalations.
• Compliance gates are long-lead items. ZATCA and SAMA reviews take time. If a sprint item needs compliance sign-off, that must be initiated before sprint start — not during.
• "Ready" has a Salla-specific definition. A story isn't sprint-ready until: design is done, Arabic copy is written, compliance is cleared (if needed), and dependencies are confirmed.