plan-sprint
À propos
Cette compétence Claude aide les développeurs à planifier les sprints Agile en affinant les backlogs, en définissant les objectifs, en calculant la capacité de l'équipe et en décomposant les éléments sélectionnés en tâches. Elle génère automatiquement un fichier structuré `SPRINT-PLAN.md` contenant l'objectif, les éléments sélectionnés, la répartition des tâches et l'allocation des capacités. Utilisez-la pour lancer un nouveau sprint, replanifier après des changements de périmètre, ou établir un rythme de sprint après le grooming du backlog.
Installation rapide
Claude Code
Recommandénpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/plan-sprintCopiez et collez cette commande dans Claude Code pour installer cette compétence
Documentation
Plan a Sprint
Plan time-boxed sprint: pick refined backlog items up to capacity, define clear goal, decompose into actionable tasks. Output: complete plan guiding team for sprint duration.
Use When
- New sprint in Scrum/agile project
- Re-plan after major scope change
- Ad-hoc → structured sprint cadence
- Post-backlog-grooming when items ready
- First sprint after charter approval
In
- Required: Product backlog (prioritized, w/ estimates)
- Required: Sprint duration (typically 1-2 wks)
- Required: Team members + availability
- Optional: Prior sprint velocity (story points or items completed)
- Optional: Sprint number + date range
- Optional: Carry-over from prev sprint
Do
Step 1: Review + Refine Backlog Items
Read current BACKLOG.md. For each candidate near top, verify:
- Clear title + desc
- Acceptance criteria (testable)
- Estimate (story points or T-shirt)
- No unresolved blockers
Refine missing. Split items > half sprint capacity → smaller pieces.
→ Top 10-15 items "sprint-ready" w/ acceptance criteria + estimates.
If err: items lack acceptance → write now. Can't estimate → schedule refinement, only pick ready.
Step 2: Define Sprint Goal
One sentence stating sprint outcome. Goal should:
- Achievable in sprint duration
- Valuable to stakeholders
- Testable (verifiable at sprint end)
**Sprint Goal**: [One sentence describing the objective]
Example: "Enable users to reset their password through email verification with two-factor authentication."
→ Sprint goal = one clear testable sentence.
If err: no coherent goal → backlog priorities scattered, consult product owner → focus on single valuable outcome.
Step 3: Calc Team Capacity
Available person-days per member:
## Team Capacity
| Team Member | Available Days | Overhead (%) | Net Capacity |
|-------------|---------------|-------------|--------------|
| [Name] | [Sprint days - PTO] | 20% | [Available × 0.8] |
| [Name] | [Sprint days - PTO] | 20% | [Available × 0.8] |
| **Total** | | | **[Sum] person-days** |
Overhead = meetings, reviews, ad-hoc (typically 15-25%).
Story points → use prior velocity. First sprint → 60-70% theoretical max.
→ Capacity calc'd in person-days or story points w/ doc'd assumptions.
If err: no historical velocity → conservative: 60%, adjust after. Better under-commit + deliver than over-commit + fail.
Step 4: Select Items + Compose Sprint Backlog
Pick from top of product backlog until capacity. Decompose each → tasks (2-8 hrs):
# Sprint Plan: Sprint [N]
## Document ID: SP-[PROJECT]-S[NNN]
### Sprint Details
- **Sprint Goal**: [From Step 2]
- **Duration**: [Start date] to [End date]
- **Capacity**: [From Step 3] person-days / [N] story points
- **Team**: [List team members]
### Sprint Backlog
| ID | Item | Points | Tasks | Assignee | Status |
|----|------|--------|-------|----------|--------|
| B-001 | [Item title] | 5 | 4 | [Name] | To Do |
| B-002 | [Item title] | 3 | 3 | [Name] | To Do |
| B-003 | [Item title] | 8 | 6 | [Name] | To Do |
| **Total** | | **16** | **13** | | |
### Task Breakdown
#### B-001: [Item title]
**Acceptance Criteria**: [From backlog item]
- [ ] Task 1: [Description] (4h, [Assignee])
- [ ] Task 2: [Description] (2h, [Assignee])
- [ ] Task 3: [Description] (4h, [Assignee])
- [ ] Task 4: [Description] (2h, [Assignee])
#### B-002: [Item title]
**Acceptance Criteria**: [From backlog item]
- [ ] Task 1: [Description] (3h, [Assignee])
- [ ] Task 2: [Description] (4h, [Assignee])
- [ ] Task 3: [Description] (2h, [Assignee])
#### B-003: [Item title]
**Acceptance Criteria**: [From backlog item]
- [ ] Task 1: [Description] (3h, [Assignee])
- [ ] Task 2: [Description] (4h, [Assignee])
- [ ] Task 3: [Description] (2h, [Assignee])
- [ ] Task 4: [Description] (3h, [Assignee])
- [ ] Task 5: [Description] (4h, [Assignee])
- [ ] Task 6: [Description] (2h, [Assignee])
### Risks and Dependencies
| Risk | Impact | Mitigation |
|------|--------|-----------|
| [Risk 1] | [Impact] | [Mitigation] |
| [Risk 2] | [Impact] | [Mitigation] |
### Carry-Over from Previous Sprint
| ID | Item | Reason | Remaining Effort |
|----|------|--------|-----------------|
| B-XXX | [Item] | [Reason] | [Hours/points] |
→ Sprint backlog w/ items up to capacity, each decomposed into tasks w/ time estimates.
If err: total points > capacity → drop lowest-pri item. Never exceed capacity by >10%. Deps block sequencing → reorder or defer.
Step 5: Document Commitments + Save
Write plan → SPRINT-PLAN.md (or SPRINT-PLAN-S[NNN].md for archive). Confirm:
- Sprint goal achievable w/ selected items
- No member overallocated (>100% capacity)
- Deps sequenced correctly
- Carry-over in capacity
- All acceptance criteria copied from backlog
Final validation:
# Check that total task hours align with capacity
grep -A 100 "Task Breakdown" SPRINT-PLAN.md | grep -o '([0-9]*h' | sed 's/[^0-9]//g' | awk '{sum+=$1} END {print "Total hours:", sum}'
→ SPRINT-PLAN.md created w/ complete backlog + task breakdown. Total hours ≤80% of available person-days × 8 hrs.
If err: commitments don't align w/ goal → revisit Step 4. Task hours > capacity → drop last item or decompose more granular.
Check
- Sprint goal = one clear testable sentence
- Capacity calc'd w/ doc'd assumptions (overhead %, PTO)
- Selected items don't exceed capacity (points or person-days)
- Every item has acceptance criteria in task breakdown
- Every item decomposed → tasks (2-8 hrs each)
- No member overallocated >100% capacity
- Carry-over doc'd w/ remaining effort
- Deps sequenced correctly
- Risks + mitigations doc'd
- SPRINT-PLAN.md created + saved
Traps
- No sprint goal: No goal → just bag of tasks. Goal = focus + basis for mid-sprint scope decisions.
- Over-commit: 100% capacity ignores interrupts, bugs, overhead. Plan 70-80% → buffer for unexpected.
- Tasks too large: >8 hrs hides complexity, hard tracking. Decompose to 2-8 hrs.
- Ignore carry-over: Unfinished items consume current sprint capacity. Account explicitly.
- Goal as item list: "Complete B-001, B-002, B-003" ≠ goal. Goal = outcome: "Users can reset password via email verification."
- No task ownership: Every task → assignee at planning → surface capacity conflicts early.
- Skip acceptance criteria: Tasks w/o criteria = untestable. Copy criteria from backlog into task breakdown.
→
manage-backlog— maintain + prioritize backlog feeding planningdraft-project-charter— project context + initial scope for first sprintgenerate-status-report— report progress + velocity to stakeholdersconduct-retrospective— review sprint, improve planningcreate-work-breakdown-structure— WBS work packages feed backlog in hybrid agile-waterfall
Dépôt GitHub
Compétences associées
llamaguard
AutreLlamaGuard est le modèle de Meta, doté de 7 à 8 milliards de paramètres, conçu pour modérer les entrées et sorties des LLM selon six catégories de sécurité comme la violence et les discours haineux. Il offre une précision de 94 à 95 % et peut être déployé avec vLLM, Hugging Face ou Amazon SageMaker. Utilisez cette compétence pour intégrer facilement le filtrage de contenu et des garde-fous de sécurité dans vos applications d'IA.
cost-optimization
AutreCette compétence de Claude aide les développeurs à optimiser les coûts du cloud grâce au redimensionnement des ressources, aux stratégies d'étiquetage et à l'analyse des dépenses. Elle fournit un cadre pour réduire les dépenses cloud et mettre en œuvre une gouvernance des coûts sur AWS, Azure et GCP. Utilisez-la lorsque vous devez analyser les coûts d'infrastructure, redimensionner les ressources ou respecter des contraintes budgétaires.
quantizing-models-bitsandbytes
AutreCette compétence quantifie les LLMs en précision 8 bits ou 4 bits à l'aide de bitsandbytes, permettant une réduction de 50 à 75 % de la mémoire utilisée avec une perte de précision minime. Elle est idéale pour exécuter des modèles plus volumineux sur une mémoire GPU limitée ou pour accélérer l'inférence, prenant en charge des formats comme INT8, NF4 et FP4. La compétence s'intègre à HuggingFace Transformers et permet l'entraînement QLoRA ainsi que l'utilisation d'optimiseurs en 8 bits.
dispatching-parallel-agents
AutreCette compétence Claude déploie plusieurs agents pour enquêter et résoudre simultanément 3 problèmes indépendants ou plus. Elle est conçue pour des scénarios impliquant des défaillances non liées qui peuvent être résolues sans état partagé ni dépendances. La capacité fondamentale est la résolution de problèmes en parallèle, en assignant un agent par domaine problématique indépendant afin de maximiser l'efficacité.
