---
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

```markdown
# 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.