MCP HubMCP Hub
Retour aux compétences

plan-sprint

pjt222
Mis à jour 2 days ago
3 vues
17
2
17
Voir sur GitHub
Autregeneral

À 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é
Principal
npx skills add pjt222/agent-almanac -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternatif
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/plan-sprint

Copiez 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 planning
  • draft-project-charter — project context + initial scope for first sprint
  • generate-status-report — report progress + velocity to stakeholders
  • conduct-retrospective — review sprint, improve planning
  • create-work-breakdown-structure — WBS work packages feed backlog in hybrid agile-waterfall

Dépôt GitHub

pjt222/agent-almanac
Chemin: i18n/caveman-ultra/skills/plan-sprint
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Compétences associées

llamaguard

Autre

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

Voir la compétence

cost-optimization

Autre

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

Voir la compétence

quantizing-models-bitsandbytes

Autre

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

Voir la compétence

dispatching-parallel-agents

Autre

Cette 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é.

Voir la compétence