| 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
- Read
knowledge/pm-context.md for team capacity and sprint cadence.
- Read
knowledge/team.md for roster and availability.
- Read
knowledge/okrs.md to ensure sprint delivers toward OKRs.
- Read
knowledge/roadmap/ for the current roadmap context.
- 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:
- "What's the sprint start and end date?"
- "Who's on the team this sprint and are there any vacations, OOOs, or reduced capacity?"
- "Do you have a backlog I should pull from, or will you paste the candidates?"
- "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.
