この記事は 
オープンストリーム Advent Calendar 2018 の20日目の記事です。
アジャイルな開発（スクラムをベース）で「NOT NO PLAN」と「NOT BAD QUALITY」目指し開発を行っております。その柱となっている内容を紹介させて頂きます。
目次
- 全体の概念モデル ・・・プロセスの構造
- 計画の構造・・・ ３つの段階的な計画
- レトロスペクティブの構造・・・ ３つの階層で振返り
- プロダクトバックログアイテムの構造・・・主要素であるフィーチャの階層構造
- おまけ・・・インセプションデッキとスプリントバックログ管理台帳のテンプレート＆サンプルのダウンロード
１．全体の概念モデル
この構造を踏まえて、プロジェクト全体の計画、開発チームの構成（チーム数やメンバー数）、開発のイテレーション計画、開発が完了したプロダクトバックログの妥当性確認を実施します。
- プロダクトバックログ：プロダクトバックログアイテムの集合、優先度順に並べられている。
- プロダクトバックログアイテム：フィーチャ（ユーザにとってソフトウェアの価値を表現したもの、機能/特徴/性能/見た目/非機能要件など動くソフトウェアとして実現するもの）、見積り、優先順位で構成される
●計画（詳細は「２．計画の構造」を参照）
- リリース計画：プロダクトバックログ全体の計画、リリースバーンダウンチャートで可視化を行う（どのプロダクトバックログアイテムがいつのイテレーションでリリース可能になるか管理を行う）
- イテレーション計画：優先順位が高く開発可能なプロダクトバックロッグアイテムを完成させるための作業（タスク）計画。見積りは理想時間で行う。イテレーションバーンダウンチャートで可視化を行う
●プロダクトバックログアイテムは下の３つを達成しないと完成とならない
- 【具現化】⇒ フィーチャ：ユーザにとって価値のあるソフトウェア機能、ユーザーストーリー形式で定義する。開発のイテレーションではそのフィーチャを動くソフトウェアとして構築する
- 【クリア】⇒ 受入れ条件：フィーチャが動くソフトウェアとして構築された場合、その妥当性を確認するためめ条件（例：受け入れテスト仕様書、結合テスト仕様書など）
- 【網羅】⇒ 完成の定義：成果物の特性に合わせ、その成果物が完成するために実施しなければ行けない事柄。動くソフトウェアであれば、「設計/設計レビュー/実装/単体テスト/ソースコードレビュー/テスト環境で受入れ条件を試験し問題が無いこと」など
２．計画の構造
各計画は上の層から下の層へブレークダウンし、１計画単位が完了した場合は下の層から上の層へ結果がフィードバックされる。フィードバックされた層の計画はその内容を受けて計画自身を改善する。
●リリース計画
プロダクトバックログアイテムがいつのイテレーションでリリース可能となるかを計画したもの。
予定と実績の可視化はリリースバーンダウンチャートを使用する。
全体の期間は「規模（総ストーリーポイント）÷ ベロシティ ＝ 期間（イテレーション数）」で算出する。
●イテレーション計画（スプリントプランニング）
目標ベロシティの範囲内で優先度の高いプロダクトバックログアイテム選択し、それらを完成させるための計画（タスク）を作成する。（ベロシティ駆動イテレーションプランニング）
予定と実績の可視化はイテレーションバーンダウンチャートを使用する。
●日計画（ディリースクラム）
チームは毎日決まった時間に集まり、昨日の実績、今日の作業、課題を共有する（所要時間の目安は15分）
３．レトロスペクティブ（振返り）の構造
レトロスペクティブによる改善は、組織・サービス・開発の層でそれぞれの要因を分析し、改善を行うための手段を見出します。見出された手段は次の計画に反映。
●プロジェクトレトロスペクティブ
- 目的：プロジェクトの完了時にプロジェクト全体を対象として振り返りを行い、組織の改善につなげる
- 参加者：プロジェクトに関わったステークホルダー
●リリースレトロスペクティブ
- 目的：リリース可能となったプロダクトバックログアイテムに対して分析を行い、より良い価値のあるソフトウェアを早く継続的に提供するための改善を見出す（結果のフィードバック⇒リリース計画/プロダクトバックログアイテム）
- 参加者：プロダクトをリリースするために関わるステークホルダー
●イテレーションレトロスペクティブ
- 目的：実施したイテレーションに対して分析を行い、次のイテレーションのプロセス改善を見出す（結果のフィードバック⇒イテレーション計画）
- 参加者：開発チームが主体
４．プロダクトバックログアイテム（フィーチャ）の構造
プロダクトバックログアイテム構造は、そのフィーチャの構造である。フィーチャーの定義はユーザーストーリーの形式を用いて定義。結果、プロダクトバックログアイテムは下の階層構造となる。
●エピック（テーマ）：ユーザーストーリーを束ねる概念
プロダクトバックログアイテム最小構成のユーザーストーリーを束ねる概念。ユーザーストーリーとして詳細化出来ない場合はエピックとしてユーザーストーリーなしの状態で扱う。
作るべきものが明確にりユーザーストーリーが定義出来た場合テーマとして扱う。
例）
＜ユーザー＞として
＜商品を出品＞したい
なぜなら＜不用品を売って儲けたい＞からだ
●ユーザーストーリー
ユーザーがソフトウェアで実現したいフィーチャを簡潔に書いたもの
スケジュール可能なユニットで、エンド・ツー・エンド（UIからバックエンド）な機能として提供されるもの
例）
＜ユーザー＞として
＜届け先を選択したい＞したい
なぜなら＜届けたい場所が変わる＞からだ
５．おまけ
- インセプションデッキ（サンプル/テンプレート）のダウンロード (PowerPoint)
- スプリントバックログ管理台帳（サンプル/テンプレート）のダウンロード (Excel) ・・・チームのキャパシティ算出、残キャパシティの範囲内でプロダクトバックログからスプリントプランニングを定義、追加タスク対応、バーンダウンチャートの自動生成と更新（色々なサービスを使って管理してきましたが、今は壁に貼った紙が正でこの台帳を使って管理しています）
明日は @nami_t さんです！