project-mngt

project-mngt

MVP/MMP/MMR 手法によるプロジェクト実装計画

目的

このスキルでは、AI アシスタントがあらゆるプロジェクトの要件を分析し、MVP/MMP/MMR（Minimum Viable Product／Minimum Marketable Product／Minimum Marketable Release）手法を用いて実装計画を作成する方法を学びます。

これは、何を計画するかではなく、どのように計画するかを教える手法スキルです。

ユースケース

1. 初期プロジェクト計画：要件を分析し、構造化された実装計画を作成します
2. 計画の更新：完了済みの作業を維持しながら、要件の変更に応じて既存の計画を修正します
3. 進捗管理：現在の状況に合わせて計画を更新し、残作業を調整します
4. リリース戦略：段階的な提供に向けて、論理的な段階とアトミックなグループを定義します

適応性

以下に対応します：

• 要件ドキュメントの数を問わない（5件でも500件でも）
• さまざまな形式：BRD、PRD、ユーザーストーリー、エピック、機能
• 多様なドメイン：トレーディングシステム、ウェブアプリ、API、インフラストラクチャ、ML/AI
• 変化する要件：完了済みの作業をやり直さずに計画を更新します

ID 命名規則

参照：framework/governance/ID_NAMING_STANDARDS.md

一般的な ID 形式：

• 計画ドキュメント：PLAN-NNN（例：PLAN-01、PLAN-02）
• 要件：REQ-NN または REQ-NN-YY（例：REQ-01、REQ-01-01）
• タスク：TASK-NNN または TASK-NNN-YY（例：TASK-01、TASK-01-01）

形式のルール：

• 主要ドキュメントには TYPE-NN を使用します（先頭にゼロを付けた3桁）
• サブ項目には TYPE-NN-YY を使用します（先頭にゼロを付けた2桁）
• ID は成果物の種類ごとに一意です
• 連番は001から始めます

---

MVP/MMP/MMR フレームワーク

定義（2024～2025年のベストプラクティス）

MVP（Minimum Viable Product）

目的：アーリーアダプターを対象に中核となる仮説を検証するための学習手段です
重点：最もリスクの高い前提をテストし、フィードバックを集め、実現可能性を証明します
品質：バグや不完全な UX、手作業のプロセスがあってもかまいません
目標：「これを構築できるか？」と「ユーザーは使ってくれるか？」に答えます
収益化：不要です。収益を得るのではなく、学習が目的です
期間：通常4～12週間です

MVP の成功基準：

• 中核機能がエンドツーエンドで動作する
• 最もリスクの高い技術的な前提が検証されている
• ユーザーからのフィードバックが収集されている
• プロダクトマーケットフィットの兆候が見られる

MMP（Minimum Marketable Product）

目的：実際の顧客価値を提供する、初めてのリリース可能な製品です
重点：市場投入に耐える品質、必須機能、販売またはデプロイが可能であること
品質：洗練された UX、安定性、本番環境に対応した品質、最小限のバグ
目標：「顧客はこれにお金を払うか？」と「大規模にサポートできるか？」に答えます
収益化：必要です。有料顧客を受け入れる準備が整っています
期間：MVP の後、8～20週間です

MMP の成功基準：

• すべての必須機能が完成している
• コードと UX が本番品質である
• セキュリティ、パフォーマンス、信頼性が検証されている
• サポート体制が整っている
• マーケティングおよび営業資料の準備が整っている

MMR（Minimum Marketable Release）

目的：MMP 後に市場での魅力を高める、段階的な機能リリースです
重点：追加機能、最適化、統合、スケールの改善
品質：MMP と同等で、本番環境に対応した市場品質です
目標：「どのように利用を拡大するか？」と「何が継続利用を促すか？」に答えます
収益化：拡大による収益を促進し、解約を減らし、新たな顧客層を引き付けます
期間：リリースごとに2～8週間（継続的）

MMR の成功基準：

• 顧客に測定可能な価値をもたらす
• 製品の品質基準を維持する
• 製品ロードマップのビジョンに沿っている
• データに基づいて優先順位が決められている

進行経路

IDEA → MVP (validate) → MMP (launch) → MMR-1 → MMR-2 → MMR-n (grow)
         ↓                ↓              ↓        ↓        ↓
      Learn First     Earn First    Expand Value Stream

品質ゲート

段階	テスト	ドキュメント	UX	パフォーマンス	セキュリティ
MVP	手動で可	最小限	基本的	十分な水準	基本的
MMP	自動化	完全	洗練	本番環境の SLA	完全な監査
MMR	自動化	更新済み	洗練	本番環境の SLA	継続的

---

分析手法

あらゆる実装計画を作成するには、以下の6つのステップに従います：

ステップ 1：要件の把握

目的：すべての要件を一覧化し、プロジェクトの範囲を把握します

プロセス：

1. すべての要件ドキュメント（BRD、PRD、ユーザーストーリー）を読みます
2. 要件ごとに以下を抽出します：
   • ID、説明、複雑さ（1～5）、優先度の手掛かり、依存関係、機能領域
3. 要件一覧表を作成します

出力：すべての要件を網羅したカタログ

ステップ 2：依存関係のマッピング

目的：関係性と順序に関する制約を特定します

依存関係の種類：

• 技術的：インフラストラクチャ／ライブラリ／コンポーネントが必要
• ビジネス上：ワークフローに必要な前提機能
• データ：スキーマ／マイグレーション／データソースが必要
• インテグレーション：外部システム／API に依存

プロセス：

1. 要件ごとに依存関係を特定します
2. ブロッキングか非ブロッキングかを分類します
3. 依存関係グラフを作成します
4. クリティカルパスを特定します

出力：ブロッキング関係を示した依存関係マップ

ステップ 3：アトミックグループ化の原則

目的：個別にデプロイおよびテストできるグループを作成します

アトミックグループの特性：

• 一貫性：関連する機能をまとめます
• 独立性：個別に開発／テスト／デプロイできます
• テスト可能性：明確な受け入れ基準があります
• 価値：確認可能な成果を提供します
• 適切な規模：1～4 週間の作業量です

グループ化の手法：

1. 機能的一貫性：機能領域ごとにグループ化します
2. 技術レイヤー：アーキテクチャコンポーネントごとにグループ化します
3. ユーザージャーニー：エンドツーエンドのワークフローごとにグループ化します
4. 依存関係クラスター：密接に結合した要件をグループ化します

命名規則：「[コンポーネント] [アクション]」（例：「ブローカー連携」、「リスク検証フレームワーク」）

出力：明確な境界を持つアトミックグループの一覧

ステップ 4：ステージの割り当て（MVP/MMP/MMR）

判断基準：

MVP の割り当て基準（少なくとも 2 つを満たす必要があります）：

• 中核となる技術的実現可能性を検証する
• エンドツーエンドのワークフローに必要である
• 最もリスクの高い仮説を検証する
• 重要なユーザーフィードバックを得られる
• 実用的な回避策がない

MMP の割り当て基準：

• 最初の顧客／ユーザーに不可欠である
• 本番環境へのデプロイに必要である
• 規制／コンプライアンス上必要である
• セキュリティ／信頼性／データ整合性に不可欠である
• 競争上、最低限必要な機能である

MMR の割り当て基準：

• 既存機能を強化する
• 市場範囲やユースケースを広げる
• 最適化またはパフォーマンスを改善する
• オプションのシステムと連携する
• 導入／継続利用を促進する、あると便利な機能である

出力：各アトミックグループを MVP、MMP、MMR-1、MMR-2 などに割り当てます

ステップ 5：優先度の番号付け

優先度の番号付け方式：

• 順次優先度（1、2、3...）：順番に完了する必要があります
• 並行優先度（同じ番号）：同時に実施できます

優先順位付けのルール：

1. 依存関係に基づく：優先度が高いほど、依存関係が少ない
2. リスク優先：リスク／不確実性の高い項目に早期に対応する
3. 価値とのバランス：技術的な依存関係とビジネス価値のバランスを取る
4. リソースを考慮：チームの規模とスキルの分布を考慮する

並行化の確認：

• 技術的な依存関係がないか？
• 異なるコード領域か？
• 対応可能なチームメンバーが別にいるか？
• 共有インフラストラクチャがボトルネックにならないか？
• 連携ポイントが明確に定義されているか？

すべて「はい」の場合 → 同じ優先度番号を割り当てます

出力：優先度番号を付けたアトミックグループ

ステップ 6：スケジュールの見積もり

複雑さに基づく見積もり：

• 複雑さ 1：0.5～1 週間
• 複雑さ 2：1～2 週間
• 複雑さ 3：2～3 週間
• 複雑さ 4：3～4 週間
• 複雑さ 5：4～6 週間

バッファ管理：

• ステージレベル：+15% のバッファ
• プロジェクトレベル：+25% のバッファ

スケジュールの計算式：

Total Time = Σ(Group Duration) / Parallel Tracks + Stage Buffers

出力：開始日／終了日とマイルストーンを記載したガントチャート

---

進捗の追跡とステータス管理

実装ステータスのカテゴリ

ステータス	記号	意味	変更可能性
COMPLETED	✅	実装、テスト、デプロイがすべて完了	IMMUTABLE
IN_PROGRESS	🚧	現在作業中	影響を評価
BLOCKED	⏸️	依存関係や問題により進行不可	解決が必要
PLANNED	📅	未着手の今後の作業	自由に変更可能
MODIFIED	🔄	当初の計画から変更	変更内容を記録
CANCELLED	❌	対象範囲から削除	削除の理由を示す

ステータス追跡の要件

1. すべてのアトミックグループにステータスを付けること
2. 完了した作業は変更不可です — 計画の更新時に変更してはいけません
3. 進行中の作業については、影響を慎重に評価する必要があります
4. 自由に再編成できるのは計画済みの作業のみです
5. ステータスの変更はすべて変更ログに記録すること

---

変更管理プロトコル

シナリオ A：新規プロジェクト（初期計画の作成）

使用する場合：新しいプロジェクトを開始するとき。以前の計画がない場合

入力：

• 要件ドキュメント一式
• プロジェクトのコンテキスト（ドメイン、チーム規模、制約）
• スケジュール上の制約（ある場合）

プロセス：

1. ステップ 1〜6（要件の確認からスケジュールの見積もりまで）を実行します
2. すべてのアトミックグループに PLANNED のマークを付けます
3. スケジュールはプロジェクトのキックオフ（第 1 週）から開始します

出力：PLAN-XXX_[project_name].md バージョン 1.0

---

シナリオ B：既存の計画がある状態での BRD の変更（最重要）

使用する場合：要件が変更され、プロジェクトが進行中の場合

入力：

• 変更または追加された要件ドキュメント
• 既存の実装計画
• 現在の進捗ステータス（完了または進行中のグループ）
• 現在の日付（スケジュールの再開起点）

プロセス（重要 — 正確に従ってください）：

フェーズ 1：完了した作業を維持する（変更不可）

1. ステータスが COMPLETED のグループをすべて特定します
2. LOCKED としてマークし、変更してはいけません
3. ルール：完了した作業を削除、改名、またはスコープ変更してはいけません

フェーズ 2：進行中の作業を評価する

1. ステータスが IN_PROGRESS のグループを特定します
2. 評価します：BRD の変更はスコープに影響しますか？作業を続行すべきですか？
3. 評価結果を記録します
4. 判断します：現状のまま続行／スコープを調整／キャンセル

フェーズ 3：BRD の変更を分析する

1. 追加、変更、削除された要件を特定します
2. 変更をアトミックグループに対応付けます
3. 影響を受けるグループと新たに必要なグループを特定します

フェーズ 4：PLANNED の作業のみを再計画する

1. ステータスが PLANNED のグループのみを変更します
2. 選択肢：再グループ化、優先順位の変更、追加、キャンセル、スコープの変更
3. 依存関係の分析を再実行します
4. フェーズの割り当てを再実行します

フェーズ 5：スケジュールを更新する

1. 現在の日付から開始します。プロジェクトの開始日からではありません
2. 残作業を計算します
3. 残りのグループを再見積もりします
4. 終了予定日を更新します
5. スケジュールの差異を計算します

フェーズ 6：変更を記録する

1. 詳細な変更ログを作成します
2. BRD の変更とその根拠を記録します
3. 影響を受けるグループをすべて一覧表示します
4. スケジュールへの影響を説明します
5. 進捗の概要を更新します

出力：更新された PLAN-XXX_[project_name].md（バージョンを更新）

重要なルール：

• ✅ 完了した作業をすべて維持する
• ✅ 進行中の作業への影響を評価する
• ✅ 計画済みの作業のみを変更する
• ✅ スケジュールを今日から開始する
• ✅ すべての変更を記録する
• ❌ 完了したグループを変更してはいけません
• ❌ スケジュールを第 1 週から再開してはいけません

---

シナリオ C：進捗の更新（BRD の変更なし）

使用する場合：要件に変更がなく、進捗に合わせて計画を更新するとき

入力：

• 既存の計画
• 進捗の更新（ステータスの変更）
• 現在の日付

プロセス：

1. グループのステータスを更新します
2. 完了したグループに日付を記録します
3. 進捗指標を更新します
4. 作業ペースが異なる場合はスケジュールを調整します
5. ブロックされている項目を特定します

出力：更新された PLAN-XXX_[project_name].md

---

実行テンプレート

テンプレート：実装計画ドキュメントの構成

# Implementation Plan: [Project Name]

## Document Control

| Item | Details |
|------|---------|
| **Project Name** | [Name] |
| **Plan ID** | PLAN-01 |
| **Version** | X.0 |
| **Date** | YYYY-MM-DD |
| **Status** | [Active / Completed / On Hold] |
| **Owner** | [Name] |
| **Preparer** | [Name] |

### Document Revision History

| Version | Date | Author | Changes Made | Approver |
|---------|------|--------|--------------|----------|
| 1.0 | YYYY-MM-DD | [Name] | Initial plan creation | |
| | | | | |

---

## Executive Summary

**Project Goal**: [One-sentence description]
**Implementation Approach**: MVP → MMP → MMR staged releases
**Current Status**: [X% complete, Y of Z groups done]
**Timeline**: Start: YYYY-MM-DD, Projected End: YYYY-MM-DD, Duration: X weeks

**Key Milestones**:
- MVP: [Date] - [Status]
- MMP: [Date] - [Status]
- MMR-1: [Date] - [Status]

---

## Implementation Progress Summary
*(Include in updated plans)*

**Overall Status**: X% Complete (Y of Z groups completed)

**Completed Stages**:
- MVP (Completed: YYYY-MM-DD, Duration: X weeks)

**Current Stage**: MMP Phase 2 (Week 3 of 4)

**Completed Groups**: [List with dates]
**In Progress**: [List with status]
**Planned**: [List with start dates]
**Blocked**: [List with issues]
**Modified**: [List with reasons]
**Cancelled**: [List with justification]

**Timeline Adjustment**:
- Original End: YYYY-MM-DD
- Current Projected: YYYY-MM-DD
- Variance: +/- X weeks
- Reason: [Explain]

---

## Stage 1: MVP (Minimum Viable Product)

**Goal**: [What this stage validates]
**Status**: [NOT_STARTED / IN_PROGRESS / COMPLETED]
**Duration**: [Original X weeks] | Actual: [If complete]

**Success Criteria**:
- [ ] [Criterion 1]
- [ ] [Criterion 2]

**Exit Criteria**:
- [ ] Core functionality works end-to-end
- [ ] Riskiest assumptions validated

### Atomic Groups

#### Priority 1: [Group Name]
**Status**: [COMPLETED / IN_PROGRESS / BLOCKED / PLANNED / MODIFIED / CANCELLED]

**Requirements**:
- REQ-01: [Description]
- REQ-02: [Description]

**Dependencies**:
- [Dependency 1] (Status: Satisfied / Pending)

**Deliverable**: [Clear, testable output]

**Success Criteria**:
- [ ] [Criterion]

**Duration**: X weeks
**Completion Date**: [If COMPLETED]
**Notes**: [If MODIFIED/BLOCKED/CANCELLED]

---

## Timeline Visualization

```mermaid
gantt
    title Implementation Timeline
    dateFormat YYYY-MM-DD
    section MVP
    Group 1 (✅)  :done, mvp1, 2024-01-01, 2w
    Group 2 (🚧)  :active, mvp2, 2024-01-15, 2w
    Group 3 (📅)  :mvp3, 2024-01-29, 1w

---

変更ログ

（更新された計画に必須）

バージョン 2.0 - YYYY-MM-DD

更新理由：[BRD の変更／進捗の更新]

BRD の変更：

• BRD-004：新しい要件を 5 件追加（REQ-041～REQ-045）

影響分析：

• 完了済みの作業：そのまま維持
• 進行中の作業：[評価]
• 計画済みの作業：[変更内容]

具体的な変更：

1. グループ X：変更 - REQ-041、REQ-042 を追加
2. グループ Y：新規 - REQ-043、REQ-044、REQ-045 向けに作成
3. グループ Z：キャンセル - 要件を削除

スケジュールへの影響：新しいグループ Y により +2 週間

---

トレーサビリティマトリクス

アトミックグループ	要件	ADR	BDD シナリオ	ステータス
MVP グループ 1	REQ-01、REQ-02	ADR-006	broker.feature	✅
MMP グループ 5	REQ-041、REQ-042	ADR-008	risk.feature	🚧

---

## AI Assistant Usage Instructions

### How to Invoke This Skill

#### Scenario 1: Create Initial Implementation Plan

**Command Pattern**:

「project-mgnt スキルを使用して、[プロジェクト名] の実装計画を作成してください。

入力：

• 要件ドキュメント：[ファイルパスの一覧]
• プロジェクトのコンテキスト：[ドメイン、チーム規模、制約]
• スケジュール上の制約：[該当する場合]

MVP／MMP／MMR の手法に従って、PLAN-XXX_[project_name].md を作成してください。」

**Example**:

「project-mgnt スキルを使用して、在庫システムの実装計画を作成してください。

入力：

• 要件：{project_root}/docs/BRD/BRD-*.md（11 ファイル）
• コンテキスト：E コマースのドメイン、FTE 5 人のチーム、最初にステージング環境へデプロイ
• 制約：MVP を 3 か月未満で実現

docs/08_IPLAN/ に PLAN-01_inventory_system.md を作成してください。」

---

#### Scenario 2: Update Existing Plan (Requirements Changed)

**Command Pattern**:

「project-mgnt スキルを使用して、[path] にある実装計画を更新してください。

入力：

• 変更した BRD：[変更したファイルの一覧]
• 既存の計画：[path]
• 現在の進捗：[完了／進行中のグループ]
• 現在の日付：[今日]

重要：完了済みの作業は維持し、計画済みの作業のみを変更してください。」

**Example**:

「project-mgnt スキルを使用して、PLAN-01_inventory_system.md を更新してください。

入力：

• 変更内容：BRD-004 にセキュリティ要件を 5 件追加
• 計画：docs/08_IPLAN/PLAN-01_inventory_system.md v1.0
• 進捗：MVP 完了（グループ 1～4）、グループ 5 は進行中（4 週間中 2 週目）
• 日付：2024-02-01

変更履歴を含む v2.0 を作成してください。」

---

### Expected Outputs

Every invocation MUST produce:

1. **Implementation Plan Document**
   - Filename: `PLAN-XXX_[project_name].md`
   - Location: User-specified or docs/08_IPLAN/
   - Format: Markdown following template
   - Versioning: v1.0, v2.0, v3.0...

2. **Required Sections**
   - Document Control section with project metadata and revision history
   - Executive Summary
   - Progress Summary (if update)
   - Stage breakdown (MVP, MMP, MMR)
   - Atomic groups with priorities, status, dependencies
   - Timeline visualization (Gantt chart)
   - Success metrics and exit criteria
   - Change log (if update)
   - Traceability matrix

3. **Change Log** (updates only)
   - BRD changes documented
   - Impact analysis
   - Specific group changes
   - Timeline impact

---

## Decision Frameworks

### Framework 1: MVP Scope Decisions

**Question**: Should this feature be in MVP?

**Key Questions**:
1. Does it test the core hypothesis?
2. Can we validate without it?
3. Is there a simpler alternative for MVP?
4. Does it validate high-risk assumption?
5. Is there a viable workaround?

**MVP Inclusion Criteria** (meet at least 2):
- [ ] Validates core technical feasibility
- [ ] Required for end-to-end workflow
- [ ] Tests riskiest assumption
- [ ] Generates critical user feedback
- [ ] No viable workaround exists

---

### Framework 2: Parallel vs Sequential

**Decision Checklist**:

グループ A とグループ B を並行して進められる条件：

• コード上の依存関係がない
• 異なるファイル／モジュールである
• データベーススキーマの変更を共有しない
• インフラストラクチャを共有しない
• 別々のチームメンバーを確保できる
• 特定スキルがボトルネックにならない
• 統合ポイントが明確に定義されている
• 手戻りのリスクが低い

チェックが 8～10 個の場合 = ✅ 並行可能（同じ優先度） チェックが 5～7 個の場合 = ⚠️ 注意して並行 チェックが 5 個未満の場合 = ❌ 順次実施

---

### Framework 3: Stage Gate Criteria

**MVP → MMP Gate**:

Exit Criteria (must meet ALL):
- [ ] Core functionality works end-to-end
- [ ] Riskiest assumptions validated
- [ ] User feedback collected
- [ ] Critical bugs logged
- [ ] Team consensus: hypothesis validated
- [ ] Product Owner sign-off

Proceed if:
- ✅ Hypothesis confirmed
- ✅ Technical feasibility proven
- ✅ Team confident

STOP if:
- ❌ Hypothesis rejected
- ❌ Technical infeasibility
- ❌ Cost exceeds value

---

### Framework 4: Update Impact Assessment

**Process**:

**Step 1: Categorize Change**
- Type: New / Modified / Removed / External dependency
- Size: Small (<5 req) / Medium (5-15) / Large (>15)
- Timing: Early (planned) / Mid (in-progress) / Late (completed)

**Step 2: Map to Groups**
- Completed groups: [Impact: None / Re-validation needed]
- In-progress groups: [Impact: Continue / Adjust / Stop]
- Planned groups: [Impact: Modify / Cancel / Reprioritize]

**Step 3: Impact Level**
- NONE: No action
- LOW: <1 week, adjust in place
- MEDIUM: 1-2 weeks, consider new group
- HIGH: >2 weeks, create new group
- CRITICAL: Invalidates group, cancel/redistribute

**Step 4: Decision Matrix**
- COMPLETED: No change (immutable) unless re-validation needed
- IN_PROGRESS: Continue / Adjust / Stop and replan
- PLANNED: Adjust / Modify / Cancel / Create new


---

## Adaptation Guidelines

### For Different Project Types

#### Infrastructure Projects
- **MVP**: Single environment (dev) with core infrastructure, automation scripts
- **MMP**: Production with full DR/HA, all IaC automated
- **Grouping**: By layer (network, compute, storage, security)
- **Critical Path**: IAM/Security → Network → Compute

#### API Development
- **MVP**: Core endpoints, happy-path only, simplified auth
- **MMP**: All endpoints, full error handling, OAuth, rate limiting
- **Grouping**: By resource/domain (Users API, Orders API)
- **Parallel**: Independent resources can develop simultaneously

#### ML/AI Systems
- **MVP**: Single model, manual training, sample data
- **MMP**: Automated pipeline, versioning, A/B testing, production serving
- **Grouping**: By ML pipeline stage (data prep, training, serving)
- **Critical Path**: Data quality → Model training → Serving

#### Web Applications
- **MVP**: Single-page prototype, core flow, desktop-only
- **MMP**: Responsive, cross-browser, all flows, production hosting
- **Grouping**: By user journey (registration, onboarding, core workflow)
- **Parallel**: Frontend + Backend (clear API contract)

---

### For Changing Requirements

#### New Features Added Mid-Project
1. Is it MVP validation? → Add to MVP (rare)
2. Essential for launch? → Add to MMP
3. Incremental value? → Add to MMR
4. Can wait? → Backlog

**Process**: Create requirement IDs, assess dependencies, fit in existing or create new group, assign stage/priority, update timeline, document in change log.

#### Features Removed/Descoped
1. In COMPLETED group? → Note descoping (already built)
2. In IN_PROGRESS? → Assess if should continue or stop
3. In PLANNED? → Cancel group or reduce scope

**Process**: Identify affected groups, remove requirements, cancel empty groups or adjust deliverables, update timeline, document rationale.

#### Priority Changes (Urgent Feature)
1. Verify dependencies allow earlier execution
2. Reprioritize to earlier priority number
3. Shift other groups later
4. Assess resource impact
5. Update timeline
6. Communicate trade-offs in change log

---

### For Different Team Sizes

#### Small Team (2-3 FTE)
- Limited parallelization (max 2 tracks)
- Focus on sequence over parallel
- Longer MVP/MMP stages
- Add 30-50% buffer for context switching

#### Medium Team (4-8 FTE)
- Good balance (2-3 parallel tracks)
- Specialization possible
- Maximize stage parallelization
- Clear ownership

#### Large Team (9+ FTE)
- High parallelization (4+ tracks)
- Specialized roles
- Risk: Communication overhead, integration complexity
- Strategy: Strict API contracts, daily syncs, strong PM


---

## Best Practices Compendium

### Common Pitfalls and Solutions

**Pitfall 1: MVP Scope Creep**
- Problem: MVP grows with "nice-to-have" features
- Solution: Ruthlessly apply MVP criteria, time-box MVP, create "MMP Backlog"

**Pitfall 2: Ignoring Dependencies**
- Problem: Parallelizing groups with hidden dependencies causes rework
- Solution: Thorough dependency mapping, define APIs before parallel work, daily syncs

**Pitfall 3: Modifying Completed Work**
- Problem: Updates change completed groups, causing confusion
- Solution: Mark completed as IMMUTABLE, create NEW groups for modifications

**Pitfall 4: Underestimating MMP Polish**
- Problem: Thinking MMP is "MVP + features" vs "production quality"
- Solution: Budget 50-100% more time for MMP, use strict "Definition of Done"

**Pitfall 5: No Clear Stage Gates**
- Problem: Moving MVP → MMP without validating success
- Solution: Explicit gate meetings, written exit criteria, PO sign-off required

---

### When to Deviate

**Acceptable Deviations**:
- Regulatory deadline: Compress stages, parallelize aggressively
- Market window: Skip some MMR features, focus on differentiators
- Technical debt crisis: Insert "Stabilization Sprint" between stages

**Never Deviate**:
- ❌ Skip MVP validation
- ❌ Launch MMP with known high-severity bugs
- ❌ Ignore completed work in updates
- ❌ Parallelize hard dependencies

---

### Lessons Learned

1. **MVP Always Takes Longer**: Add 25% buffer (50% for first-time team)
2. **MMP Needs More Testing**: Budget 30% of MMP for testing/QA
3. **Documentation Never "Done"**: Start in MVP, update continuously
4. **Velocity Improves**: First groups slower (learning), later groups faster (momentum)

---

## Validation Checklist

### For New Plans

**Completeness**:
- [ ] All requirements accounted for
- [ ] Dependencies identified and documented
- [ ] No circular dependencies

**Atomic Groups**:
- [ ] Groups independently testable
- [ ] Groups cohesive (related functionality)
- [ ] Size reasonable (1-4 weeks each)
- [ ] Descriptive names

**Stage Assignment**:
- [ ] MVP scope minimal (validation only)
- [ ] MMP includes launch essentials
- [ ] MMR is incremental (not launch-critical)

**Timeline**:
- [ ] Estimates based on complexity
- [ ] Buffers included at stage level
- [ ] Timeline realistic for team size

---

### For Updated Plans (CRITICAL)

**Immutability**:
- [ ] **All completed work preserved unchanged**
- [ ] Completion dates/deliverables unchanged
- [ ] No deletions/scope changes to completed groups

**Impact Assessment**:
- [ ] In-progress work assessed
- [ ] Only planned work modified
- [ ] New requirements mapped to groups

**Change Log**:
- [ ] BRD changes documented
- [ ] Impact analysis complete
- [ ] Specific changes listed with reasons
- [ ] Timeline impact calculated

**Timeline Continuity**:
- [ ] Timeline starts from current date
- [ ] Remaining work calculated accurately
- [ ] Variance explained

**Progress Tracking**:
- [ ] Progress summary accurate
- [ ] Status categories correct
- [ ] Completion percentage calculated

---

## Appendix

### Complexity Rating Scale

| Rating | Definition | Duration |
|--------|------------|----------|
| 1 | Trivial: Config change, minimal code | 0.5-1 week |
| 2 | Simple: Single component, clear requirements | 1-2 weeks |
| 3 | Moderate: Multiple components, some integration | 2-3 weeks |
| 4 | Complex: Cross-system integration, unknowns | 3-4 weeks |
| 5 | Very Complex: Architectural change, high uncertainty | 4-6 weeks |

### Glossary

**MVP**: Learning-focused first version to validate hypothesis. Functional but imperfect.

**MMP**: Market-ready first release with essential features and production quality. Can be sold.

**MMR**: Incremental feature releases after MMP. Production-quality, adds value.

**Atomic Group**: Independently deployable set of related requirements. 1-4 weeks, cohesive, testable.

**Critical Path**: Longest dependency chain determining minimum timeline.

**Dependency**: Prerequisite relationship between requirements or groups.

**Stage Gate**: Decision point between stages to validate completion.

**Priority Number**: Sequencing indicator. Same number = parallel execution.

**Status**: Current state (COMPLETED, IN_PROGRESS, BLOCKED, PLANNED, MODIFIED, CANCELLED).

**Change Log**: Document section tracking all modifications from previous version.

**Immutable**: Cannot be changed. Completed work is immutable in updates.

---

## Worked Example Reference

See examples directory for complete worked examples:

**Trading System v1.0**: Initial plan from 11 BRDs
- 13 atomic groups across MVP/MMP/MMR
- All groups PLANNED
- Timeline: 27 weeks from start

**Trading System v2.0**: Updated after BRD-004 changes
- MVP completed (Groups 1-4)
- Group 5 in progress
- New requirements added
- Timeline adjusted, change log included

*(Full examples in `../project-mngt/examples/`)*

---

## Skill Version History

**Version 1.0** (2025-01-03):
- Initial release
- Complete MVP/MMP/MMR framework
- Change management protocols
- Templates and decision frameworks
- Validation checklists
- Adaptation guidelines

---

## Support and Feedback

For issues or enhancements:
1. Document issue or suggestion
2. Provide scenario where skill didn't work
3. Suggest improvement with rationale

This skill evolves based on real-world usage and feedback.