バックログ・リファイメント

〜バックログ・アイテムの詳細化、優先度付け〜

バックログ・リファイメントとは

バックログ・リファイメントではバックログ・アイテムの

  • 詳細化
  • 分割
  • 見積もり
  • 優先度付け
  • 検証方法の検討

を行います。

バックログ・アイテムとは、プロダクトに必要な要件・仕様の最小単位です。

なぜバックログ・リファイメントをするのか

プロダクトには何が含まれ、それを作るにはどのくらいかかり、

できたことをどうやって決めるのかなどを関係者で話し合い決定します。

ここで決定した優先度を元に開発チームが製造に取り組むことになります。

どうやっておこなうのか

必要なもの

  • 大きめの付箋

やり方

今回紹介するのはあくまでも一例です。

作成にはいろいろな方法があります。

自分たちの組織にあった方法を模索してみましょう。

  1. ユーザーストーリーマッピングなどを用いて、ストーリーを作成。
  2. ストーリーをバックログ・アイテムに落とし込む (INVESTを意識。※INVESTについては後述)
  3. 見積もり、サイズ、優先度、受入条件などを話し合いながら決定する

注意点

受入条件をきちんと書こう

受入条件はとても大事です。

バックログ・アイテムを実装して、どのような条件を満たしたら、完成になるのかを定義します。

その際に、「要件ができていること」などのように曖昧に書いてはいけません。

できているの定義が曖昧なので人によって認識が異なる場合があります。

「確定ボタンが表示されていること」などのように

きちんと話し合ってなるべく具体的に受入条件を書きましょう。

INVESTを意識しよう

INVESTというのは、下記の頭文字をとったもので、

バックログを作る際に意識すると良いものとなっています。

  • Independent(独立している)
  • Negotiable(交渉可能)
  • Valuable(価値がある)
  • Estimatable(見積もり可能)
  • Small(十分に小さい)
  • Testable(検証可能)

機能ではなく価値を重視しよう

今まで機能を洗い出すことを重視している様な開発をされていた多いのですが、

バックログ・アイテムを機能基準で考えてしまうということです

本当にその機能はお客様の価値を生み出しているのでしょうか?

この観点で考えられるかどうかであなたのプロダクトの成功確率が大きく変わってくるはずです

また、バックログ・アイテムの解決策をチームメンバーと議論できるととてもよいです

そのためには選択肢がいくつか考えられるように、そのバックログ・アイテムで何をしたいのかを明確にしましょう

2、3 スプリント先のことがわかっていると調査が前もってできる

見積もりを行うために調査が必要な場合も多いです

調査は見積もりができるようになるまで行います

その調査にどのくらい価値があるのか、と 調査にかかる時間を天秤にかけて

調査する意義があるとするならば、スプリントに調査を組み込んでいきましょう。

見積もりが多かった場合、もっと分けられないか考えよう

見積もりのポイント数が多かった場合、十分に詳細化、分割ができていないことを疑いましょう。

あまりにも大きいポイント数だとそれだけ完了しないリスク(不確実性)も大きくなります。

特にチームを開始したばかりの時期は細かすぎるくらい細かいバックログ・アイテムにする気持ちで取り組んでみましょう。

参考資料

さいごに

文章の改善のため、フィードバックがありましたら、こちらopen in new windowからお願いいたします。

Last Updated:
Contributors: Tomoya Suzuki