スパイク、バグ、技術的負債の見積もり方法
従来のユーザーストーリー形式に適合しない作業（リサーチスパイク、バグ修正、技術的負債アイテム）の見積もり戦略を学びます。
Techniques
詳細な説明
非標準的な作業アイテムの見積もり
バックログのすべてのアイテムが明確な受け入れ基準を持つユーザーストーリーではありません。スパイク、バグ、技術的負債には異なる見積もり戦略が必要です。
リサーチスパイク
スパイクは、質問に答えるか不確実性を減らすための時間制限付き調査です。
戦略: スパイクをストーリーポイントで見積もらない。代わりにタイムボックスにする（例：「支払いゲートウェイオプションの調査に2日」）。スパイクの成果物は知識であり、出荷可能なコードではない。
スパイク: 「商品カタログの3つのキャッシュ戦略を評価」
タイムボックス: 1日
成果物: 長所/短所を含む書面での推奨事項
→ ストーリーポイントを割り当てない
バグ修正
バグの複雑さは大きく異なります。タイプミスの修正と分散システムのレースコンディションは同じではありません。
戦略: バグを他のストーリーと同様に見積もるが、より広い不確実性を受け入れる。根本原因が不明な場合は、まずスパイクを検討。
バグ: 「Safariで断続的にログインが失敗」
根本原因不明 → まずスパイク（再現と診断に0.5日）
→ 発見に基づいて修正を見積もる
技術的負債
技術的負債アイテムは、ユーザーに見える動作を変えずにコード品質を改善します。
戦略: 通常通り見積もる。リファクタリング、テストの追加、ライブラリのアップグレードの工数は、実際の複雑さを持つ実際の作業。
技術的負債: 「ユーザーサービスをRESTからGraphQLに移行」
複数のエンドポイントが影響、スキーマ設計が必要、テストの書き換え
→ 13ポイント（大規模、横断的）
まとめ表
| 作業タイプ | 見積もる？ | 方法 |
|---|---|---|
| ユーザーストーリー | はい（ポイント） | プランニングポーカー |
| スパイク | いいえ | タイムボックス |
| バグ（原因既知） | はい（ポイント） | 通常の見積もり |
| バグ（原因不明） | まずスパイク | タイムボックス、次に見積もり |
| 技術的負債 | はい（ポイント） | 通常の見積もり |
ユースケース
スプリント計画中にチームがスパイクとバグの扱い方に苦労している場合、または見積もりがないために技術的負債アイテムが常に優先度を下げられている場合にこのガイドを使用してください。