agile-planning
アジャイル開発におけるスプリント計画やロードマップを、固有のスプリントコードを用いて作成し、リリース計画を効率的に進めるSkill。
📜 元の英語説明(参考)
Generate agile release plans with sprints and roadmaps using unique sprint codes. Use when creating sprint schedules, product roadmaps, release planning, or when user mentions agile planning, sprints, roadmap, or release plans.
🇯🇵 日本人クリエイター向け解説
アジャイル開発におけるスプリント計画やロードマップを、固有のスプリントコードを用いて作成し、リリース計画を効率的に進めるSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o agile-planning.zip https://jpskill.com/download/19033.zip && unzip -o agile-planning.zip && rm agile-planning.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/19033.zip -OutFile "$d\agile-planning.zip"; Expand-Archive "$d\agile-planning.zip" -DestinationPath $d -Force; ri "$d\agile-planning.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
agile-planning.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
agile-planningフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 3
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
アジャイルプランニング
スプリントスケジュールとロードマップを含む、無駄のないアジャイルリリース計画を生成します。
概要
このスキルは、アジャイルプロジェクト向けの構造化されたリリース計画を作成します。生成されるものは以下の通りです。
- 固有のコード(SPRINT-001、SPRINT-002など)を持つスプリントスケジュール
- 詳細な追跡のためのチケットコード(T-001、T-002など)を持つタスク
- タイムラインとマイルストーンを示すロードマップ
- 依存関係とリリースチェックポイント
製品リリースを計画する際、作業をスプリントに整理する際、またはステークホルダーにタイムラインを伝える際にこれを使用してください。
手順
ステップ1:コンテキストを収集する
計画を生成する前に、以下を収集してください。
- プロジェクトスコープ: 何を構築するのか?
- タイムライン: 何週間/何か月か?
- チーム規模: 開発者の人数
- スプリント期間: 通常2週間
- 主要なマイルストーン: アルファ、ベータ、本番稼働日
- 優先順位: 必須機能とあれば良い機能
ステップ2:スプリントを構成する
以下の要素でスプリントを作成してください。
- 固有のコード: SPRINT-001、SPRINT-002、SPRINT-003(連番、ゼロ埋め)
- スプリントテーマ: 説明的な名前(例:「決済連携」、「UIの磨き込み」)
- 期間: 開始日と終了日
- 目標: 1文で表すスプリントの目的
- タスク: スプリントごとに3〜5個の具体的なタスク。それぞれに固有のチケットコード(T-001、T-002など)を付与します。
- 依存関係: このスプリントをブロックするもの、またはこのスプリントに依存するもの
タスクの番号付け:
- 形式を使用してください:T-001、T-002、T-003(ゼロ埋め、リリース全体で連番)
- 各タスクには、プロジェクト全体で永続する固有のコードが付与されます。
- タスクコードを再利用しないでください。
スプリント期間のガイドライン:
- 2週間(最も一般的)= 10営業日
- 80%のキャパシティで計画してください(会議、バグ、予期せぬ事態のために20%を確保します)
- スプリント間の作業負荷のバランスを取ってください。
スプリントテーマ: 明確で目標指向のテーマを使用してください。
- 基盤、セットアップ、インフラストラクチャ
- コア機能、MVP開発
- 統合、API開発
- テスト、バグ修正、最適化
- ベータ版リリース、本番リリース
ステップ3:ロードマップを構築する
スプリントをタイムラインビューにグループ化してください。
- 四半期別: Q1 2025、Q2 2025など
- 月別: 1月、2月、3月
- フェーズ別: 基盤 → 機能 → リリース
主要なマイルストーンを含めてください。
- アルファ版リリース日
- ベータ版リリース日
- 本番稼働
- 主要な機能の完了
ステップ4:出力のフォーマット
この構造を使用してください。
# リリース計画: [プロジェクト名] v[バージョン]
**リリース目標**: [1文]
**タイムライン**: [開始] - [終了] ([X]スプリント)
**チーム**: [人数]開発者
## スプリント
### SPRINT-001: [テーマ]
**期間**: [開始日] - [終了日]
**目標**: [このスプリントで達成すること]
**タスク**:
- T-001: [タスクの説明] [ ]
- T-002: [タスクの説明] [ ]
- T-003: [タスクの説明] [ ]
**依存関係**: [もしあれば]
### SPRINT-002: [テーマ]
**期間**: [開始日] - [終了日]
**目標**: [このスプリントで達成すること]
**タスク**:
- T-004: [タスクの説明] [ ]
- T-005: [タスクの説明] [ ]
## ロードマップ
### Q1 2025
- **SPRINT-001**: [主要な成果]
- **SPRINT-002**: [主要な成果]
### Q2 2025
- **SPRINT-003**: [主要な成果]
## マイルストーン
- **[日付]**: アルファ版リリース (SPRINT-00X)
- **[日付]**: ベータ版リリース (SPRINT-00X)
- **[日付]**: 本番稼働 (SPRINT-00X)
ステップ5:計画を検証する
以下を確認してください。
- ✓ スプリントコードは連番で一意であること(SPRINT-001、SPRINT-002など)
- ✓ タスクコードは連番で一意であること(T-001、T-002など)
- ✓ タスクは具体的で測定可能であること
- ✓ 依存関係が特定されていること
- ✓ タイムラインが現実的であること
- ✓ マイルストーンがスプリントスケジュールと一致していること
ベストプラクティス
スプリント計画:
- タスクを具体的に保つこと:「T-001: 決済に関する作業」ではなく「T-001: Stripe SDKの統合」
- 1スプリントあたり3〜5タスクに制限すること
- リスクの高い/複雑な作業を前倒しすること
- テスト用のバッファスプリントを含めること
タスクの番号付け:
- 常に3桁を使用すること:T-001、T-1ではない
- リリース全体で連番であること(T-001、T-002... T-050)
- タスクがキャンセルされた場合でも、コードを再利用しないこと
依存関係:
- 早期に特定すること:「SPRINT-001のAPIエンドポイントが必要」
- 依存するスプリントを順次スケジュールすること
- 外部依存関係(API、デザインアセット)を文書化すること
ロードマップ:
- タスクではなく成果に焦点を当てること
- 主要なマイルストーンを強調すること
- ステークホルダーにとって分かりやすいものにすること
- 各スプリント後に更新すること
コード規約:
- スプリント:常に3桁を使用すること(SPRINT-001、SPRINT-1ではない)
- タスク:常に3桁を使用すること(T-001、T-1ではない)
- 連番:タスクコードはすべてのスプリントで継続すること
- コード(スプリントまたはタスク)を再利用しないこと
例
例1:Eコマースプラットフォーム(6スプリント)
# リリース計画: Eコマースプラットフォーム v2.0
**リリース目標**: 複数の支払いオプションを備えた新しいチェックアウトシステムをローンチする
**タイムライン**: 2025年1月1日 - 3月15日(6スプリント)
**チーム**: 開発者3名
## スプリント
### SPRINT-001: 決済基盤
**期間**: 1月1日 - 1月14日
**目標**: 決済インフラストラクチャとAPI連携をセットアップする
**タスク**:
- T-001: Stripe SDKの統合 [ ]
- T-002: 決済データベーススキーマの設計 [ ]
- T-003: 決済APIエンドポイント [ ]
- T-004: 送料計算機 [ ]
**依存関係**: なし
---
### SPRINT-002: チェックアウトUI
**期間**: 1月15日 - 1月28日
**目標**: レスポンシブなチェックアウトフローを構築する
**タスク**:
- T-005: ゲストチェックアウトフォーム [ ]
- T-006: 住所自動保存機能 [ ]
- T-007: モバイルレスポンシブレイアウト [ ]
- T-008: フォーム検証ロジック [ ]
**依存関係**: SPRINT-001の決済API (T-003) が必要
---
### SPRINT-003: PayPal連携
**期間**: 1月29日 - 2月11日
**目標**: PayPalを支払いオプションとして追加する
**タスク**:
- T-009: PayPal SDKのセットアップ [ ]
- T-010: 支払い方法選択UI [ ]
- T-011: 注文確認メール [ ]
- T-012: 取引ログシステム [ ]
**依存関係**: SPRINT-001のインフラストラクチャ (T-002, T-003) が必要
---
### SPRINT-004: テストと磨き込み
**期間**: 2月12日 - 2月25日
**目標**: 本番稼働の準備が整っていることを確認する
**タスク**:
- T-013: エンドツーエンドテストスイート [ ]
- T-014: QAからのバグ修正 [ ]
- T-015: パフォーマンス最適化 [ ]
- T-016: セキュリティレビューと修正 [ ]
**依存関係**: すべての機能が完了していること (T-001からT-012まで)
---
### SPRINT-005: ベータ版リリース
**期間**: 2月 📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Agile Planning
Generate lean agile release plans with sprint schedules and roadmaps.
Overview
This skill creates structured release plans for agile projects. It generates:
- Sprint schedules with unique codes (SPRINT-001, SPRINT-002, etc.)
- Tasks with ticket codes (T-001, T-002, etc.) for granular tracking
- Roadmaps showing timeline and milestones
- Dependencies and release checkpoints
Use this when planning product releases, organizing work into sprints, or communicating timelines to stakeholders.
Instructions
Step 1: Gather Context
Before generating a plan, collect:
- Project scope: What are we building?
- Timeline: How many weeks/months?
- Team size: Number of developers
- Sprint duration: Typically 2 weeks
- Key milestones: Alpha, beta, production dates
- Priorities: Must-have vs nice-to-have features
Step 2: Structure Sprints
Create sprints with:
- Unique codes: SPRINT-001, SPRINT-002, SPRINT-003 (sequential, zero-padded)
- Sprint theme: Descriptive name (e.g., "Payment Integration", "UI Polish")
- Duration: Start and end dates
- Goal: One-sentence sprint objective
- Tasks: 3-5 concrete tasks per sprint, each with unique ticket code (T-001, T-002, etc.)
- Dependencies: What blocks this sprint or depends on it
Task Numbering:
- Use format: T-001, T-002, T-003 (zero-padded, sequential across entire release)
- Each task gets a unique code that persists throughout the project
- Never reuse task codes
Sprint Duration Guidelines:
- 2 weeks (most common) = 10 working days
- Plan for 80% capacity (reserve 20% for meetings, bugs, unexpected)
- Balance workload across sprints
Sprint Themes: Use clear, goal-oriented themes:
- Foundation, Setup, Infrastructure
- Core Features, MVP Development
- Integration, API Development
- Testing, Bug Fixes, Optimization
- Beta Launch, Production Release
Step 3: Build Roadmap
Group sprints into timeline view:
- By Quarter: Q1 2025, Q2 2025, etc.
- By Month: January, February, March
- By Phase: Foundation → Features → Launch
Include major milestones:
- Alpha release dates
- Beta release dates
- Production launch
- Key feature completions
Step 4: Format Output
Use this structure:
# Release Plan: [Project Name] v[Version]
**Release Goal**: [One sentence]
**Timeline**: [Start] - [End] ([X] sprints)
**Team**: [Number] developers
## Sprints
### SPRINT-001: [Theme]
**Duration**: [Start Date] - [End Date]
**Goal**: [What this sprint achieves]
**Tasks**:
- T-001: [Task description] [ ]
- T-002: [Task description] [ ]
- T-003: [Task description] [ ]
**Dependencies**: [If any]
### SPRINT-002: [Theme]
**Duration**: [Start Date] - [End Date]
**Goal**: [What this sprint achieves]
**Tasks**:
- T-004: [Task description] [ ]
- T-005: [Task description] [ ]
## Roadmap
### Q1 2025
- **SPRINT-001**: [Key achievement]
- **SPRINT-002**: [Key achievement]
### Q2 2025
- **SPRINT-003**: [Key achievement]
## Milestones
- **[Date]**: Alpha release (SPRINT-00X)
- **[Date]**: Beta release (SPRINT-00X)
- **[Date]**: Production launch (SPRINT-00X)
Step 5: Validate Plan
Check:
- ✓ Sprint codes are sequential and unique (SPRINT-001, SPRINT-002, etc.)
- ✓ Task codes are sequential and unique (T-001, T-002, etc.)
- ✓ Tasks are specific and measurable
- ✓ Dependencies are identified
- ✓ Timeline is realistic
- ✓ Milestones align with sprint schedule
Best Practices
Sprint Planning:
- Keep tasks specific: "T-001: Stripe SDK integration" not "T-001: work on payments"
- Limit to 3-5 tasks per sprint
- Front-load risky/complex work
- Include buffer sprint for testing
Task Numbering:
- Always use 3 digits: T-001, not T-1
- Sequential across entire release (T-001, T-002... T-050)
- Never reuse codes, even if task is cancelled
Dependencies:
- Identify early: "Requires SPRINT-001 API endpoints"
- Schedule dependent sprints sequentially
- Document external dependencies (APIs, design assets)
Roadmap:
- Focus on outcomes, not tasks
- Highlight major milestones
- Keep it stakeholder-friendly
- Update after each sprint
Code Conventions:
- Sprints: Always use 3 digits (SPRINT-001, not SPRINT-1)
- Tasks: Always use 3 digits (T-001, not T-1)
- Sequential numbering: Task codes continue across all sprints
- Never reuse codes (sprints or tasks)
Examples
Example 1: E-commerce Platform (6 sprints)
# Release Plan: E-commerce Platform v2.0
**Release Goal**: Launch new checkout system with multiple payment options
**Timeline**: Jan 1 - Mar 15, 2025 (6 sprints)
**Team**: 3 developers
## Sprints
### SPRINT-001: Payment Foundation
**Duration**: Jan 1 - Jan 14
**Goal**: Setup payment infrastructure and API integrations
**Tasks**:
- T-001: Stripe SDK integration [ ]
- T-002: Payment database schema design [ ]
- T-003: Payment API endpoints [ ]
- T-004: Shipping cost calculator [ ]
**Dependencies**: None
---
### SPRINT-002: Checkout UI
**Duration**: Jan 15 - Jan 28
**Goal**: Build responsive checkout flow
**Tasks**:
- T-005: Guest checkout form [ ]
- T-006: Address autosave feature [ ]
- T-007: Mobile responsive layout [ ]
- T-008: Form validation logic [ ]
**Dependencies**: Requires SPRINT-001 payment API (T-003)
---
### SPRINT-003: PayPal Integration
**Duration**: Jan 29 - Feb 11
**Goal**: Add PayPal as payment option
**Tasks**:
- T-009: PayPal SDK setup [ ]
- T-010: Payment method selector UI [ ]
- T-011: Order confirmation emails [ ]
- T-012: Transaction logging system [ ]
**Dependencies**: Requires SPRINT-001 infrastructure (T-002, T-003)
---
### SPRINT-004: Testing & Polish
**Duration**: Feb 12 - Feb 25
**Goal**: Ensure production readiness
**Tasks**:
- T-013: End-to-end testing suite [ ]
- T-014: Bug fixes from QA [ ]
- T-015: Performance optimization [ ]
- T-016: Security review and fixes [ ]
**Dependencies**: All features complete (T-001 through T-012)
---
### SPRINT-005: Beta Launch
**Duration**: Feb 26 - Mar 11
**Goal**: Soft launch to beta users
**Tasks**:
- T-017: Beta deployment to staging [ ]
- T-018: User feedback collection system [ ]
- T-019: Analytics and tracking setup [ ]
- T-020: Critical bug fixes [ ]
**Dependencies**: SPRINT-004 testing complete (T-013)
---
### SPRINT-006: Production Release
**Duration**: Mar 12 - Mar 15
**Goal**: Full production rollout
**Tasks**:
- T-021: Production deployment [ ]
- T-022: Monitoring and alerting setup [ ]
- T-023: User documentation [ ]
- T-024: Team handoff and training [ ]
**Dependencies**: Beta success metrics met (T-017, T-018)
## Roadmap
### Q1 2025
- **SPRINT-001**: Payment infrastructure complete
- **SPRINT-002**: Checkout UI launched
- **SPRINT-003**: PayPal support added
- **SPRINT-004**: Testing complete, production-ready
- **SPRINT-005**: Beta launch successful
- **SPRINT-006**: Full production release
## Milestones
- **Feb 25**: Alpha release (internal testing)
- **Feb 26**: Beta release (limited users)
- **Mar 12**: Production launch (all users)
Example 2: Mobile App MVP (4 sprints)
# Release Plan: Fitness Tracker App v1.0
**Release Goal**: Launch MVP with core tracking features
**Timeline**: 8 weeks (4 sprints)
**Team**: 2 developers
## Sprints
### SPRINT-001: User Foundation
**Duration**: Week 1-2
**Goal**: User accounts and authentication
**Tasks**:
- T-001: Firebase authentication setup [ ]
- T-002: User profile creation flow [ ]
- T-003: Profile editing functionality [ ]
- T-004: Avatar upload feature [ ]
### SPRINT-002: Activity Tracking
**Duration**: Week 3-4
**Goal**: Core fitness tracking features
**Tasks**:
- T-005: Step counter integration [ ]
- T-006: Manual activity logging interface [ ]
- T-007: Activity history view [ ]
- T-008: Basic statistics dashboard [ ]
### SPRINT-003: Data Visualization
**Duration**: Week 5-6
**Goal**: Charts and progress tracking
**Tasks**:
- T-009: Daily activity charts [ ]
- T-010: Weekly summary view [ ]
- T-011: Goal progress indicators [ ]
- T-012: Achievement badges system [ ]
### SPRINT-004: Launch Prep
**Duration**: Week 7-8
**Goal**: Polish and release
**Tasks**:
- T-013: App store assets creation [ ]
- T-014: Beta testing coordination [ ]
- T-015: Critical bug fixes [ ]
- T-016: Production deployment [ ]
## Roadmap
### Month 1
- SPRINT-001: User system live
- SPRINT-002: Activity tracking functional
### Month 2
- SPRINT-003: Data visualization complete
- SPRINT-004: MVP launched to app stores
## Milestones
- **Week 6**: Beta testing begins
- **Week 8**: App store submission
- **Week 9**: Public launch
Reference Files
For more detailed guidance:
- Sprint planning: See references/sprint-guide.md
- Template: See references/template.md
When to Use
Use this skill when:
- Starting a new product release
- Planning quarterly roadmaps
- Breaking down large projects into sprints
- Communicating timelines to stakeholders
- Organizing backlog into time-boxed iterations
- Creating sprint schedules for agile teams
同梱ファイル
※ ZIPに含まれるファイル一覧。`SKILL.md` 本体に加え、参考資料・サンプル・スクリプトが入っている場合があります。
- 📄 SKILL.md (9,382 bytes)
- 📎 references/sprint-guide.md (5,461 bytes)
- 📎 references/template.md (3,118 bytes)