リファインメント

スクラムイベント

この記事では、

・リファインメントってなに?
と悩んでいる方に向けて

・リファインメントの基本ルール・やり方
を説明します。

この記事を読むと以下のことがわかります。

この記事で読んでわかること!
  • リファインメントとは何か
  • リファインメントの基本ルール
  • リファインメントを実施する時の流れ

スクラムイベントの概要を確認したい方は、以下記事をご確認ください。

5つのスクラムイベント
スクラムイベントの概要や推奨されるスプリント期間、スプリント中のスケジュール、各イベントの参加者や発言権に関して説明しています。各スクラムイベントの詳細を学習する前に、スクラムイベントの全体像をしっかりと把握・理解しておきましょう!

スプリントのスケジュールでいうと以下の赤枠部分です。

リファイメントとは?

プロダクトバックログアイテムをより詳細にするイベントです。

プロダクトオーナーと開発者が継続的に実施するプロセスであり、
PBIの説明・並び順・ストーリーポイントなどを追加し、PBIをより詳細にしていきます。

リファインメントが必要な理由

  • 大きいPBIを小さく分割することで、スクラムチーム内での認識合わせがしやすくなる
  • PBIを小さくすることで、見積りが簡単になる
  • POが開発者に対して、プロダクトビジョンや方向性を共有する時間になる
  • スクラムチームが全体像を把握することで”価値”を判断しやすくなる

基本ルール

タイムボックス
 - 1週間のスプリント場合は1〜2時間、2週間スプリントの場合は2〜4時間が目安。
 ※スプリントの中で少なくとも1回分はリファインメントの時間を確保しておきましょう!

参加者
 - PO、開発者、SM

発言権
 - PO、開発者、SM
 ※ SMは主にファシリテートするために発言する。

アウトプット
 - プロダクトバックログ(PBL)
 - プロダクトバックログアイテム(PBI)

リファイメントの流れ

【基本的な流れ】
以下の順番に実施するとスムーズに進行できると思います。

事前準備:
POは、顧客やステークホルダーからの新たな要求に対するPBIを作成し、
優先度順にPBLに登録しておく。

  1. 開発者から新たに追加したいPBIや優先度を変更したいPBIがないか確認する
  2. POが新しく登録したPBIの内容、受け入れ基準(AC)を説明する
  3. スクラムチームで新しく登録されたPBIの価値やリスク、依存性について話し合う
  4. 新しく登録されたPBIを、必要に応じて小さく分割する
  5. 話し合い及びPBI分割後、再度POがPBIを並び替える
  6. 開発者は、プラニングポーカーにてPBIのポイントを見積る
    (直近2〜3スプリント分の見積りが出来ていればOKです)
とも坊

PBIすべてが常に小さいPBIになっていなくても大丈夫だよ!
直近スプリントで作業するものを
リファイメントを通して適宜小さなPBIに分割していくんだ!

やりとりイメージ

1. 開発者から新たに追加したいPBIや優先度を変更したいPBIがないか確認する

それでは今週も「リファイメント」を始めます。

よろしくお願いします。

はじめに開発者の方から、既存のPBIで優先度を変更したいものや、

新たに追加したいPBIがあれば、共有お願いします。

SM
開発者

はーい。私から一つ提案させてください!

「PBI-1:〇〇機能を作成する」ですが、

受け入れ基準を見ると、正常系と異常系の実装が共に完了している必要がありそうです。

正常系の実装、異常系の実装にチケット分割できないでしょうか。

まとめてやった方が効率が良いと考えていましたが、

理由を教えてもらえますか?

PO
開発者

確かにまとめて実装した方が効率が良いところもありますが、

まとめて実施する場合、ストーリポイントの見積りが大きくなり

また、「異常系」のパターンがすり合わせも実施できていないので、

スプリント内に収まるか微妙なところです。

なので、「Undone」になるよりも、スプリントレビュー時に

正常系の動作だけでも、ステークホルダー確認いただいた方が良いと考えました。

了解です!

確かに、詳細化できていない項目があるので、

リスクを抑えて、動くプロダクトでインクリメントを確認してもらうためにも

異常系は、別チケットにした方が良さそうですね!

ありがとうございます。

PO

2. POが新しく登録したPBIの内容、受け入れ基準(AC)を説明する

SM

続いて、POから新しく登録されたPBIの説明をお願いします!

はい、今回追加で「クーポンを受け取ることができる」を追加させていただきました。

前々から、ステークホルダーから打診は受けていたのですが、

要件が固まってきたので、このタイミングで追加しました。

PO

[実施理由]

当社別サービスで利用できるクーポンを配布することで、別サービスへの購買意欲につなげたい。

ユーザーとしても、当社別サービスをお得に利用することができる。

また、競合他社から本サービスを選択するメリットもなると考えているため。

[AC]

AC-1:アカウント作成後に、登録されたメールアドレス宛に「クーポンコード」が送付される

AC-2:送信文章、クーポンコードは、管理画面から設定できる

AC-2:管理画面から「クーポンコード」の設定時に、テストメールを送ることができる

PO

3. スクラムチームで新しく登録されたPBIの価値やリスク、依存性について話し合う

開発者

ユーザーへ「アカウント登録完了」のメールは既に送信しているし、

管理画面での送信内容の設定も技術的には、問題ないです。

ただ、DBのテーブルも追加しないといけないので、このPBIの前に実施しようとしていた「DB構築」のチケットには影響がありそうです。

了解!

「DB構築」のPBIは、

「クーポンコード配布」を考慮した説明、ACに修正しておくね!

PO

4. 新しく登録されたPBIを、必要に応じて小さく分割する

開発者

PBIはテストの実施に時間がかかるので、

以下2つの観点で分割してほしいなー!

[ユーザー向けの機能]

– ユーザーにクーポンを送付する

[管理者向けの機能]

– 管理画面で送信内容を設定する

– 管理画面でクーポンコードを設定する

– 管理画面でテストメールを送信する

確かに、利用者も異なるので、

PBIは分けた方がいいですね!

コメントありがとうございます。その観点でPBIを分割しておきます!

PO

5. 話し合い及びPBI分割後、再度POがPBIを並び替える

これまでの話し合いを受けて

以下のPBIの順番で進めたいと思います!

PBI-3:DB構築をする

PBI-1:ユーザーが〇〇機能を利用できる

PBI-2:〇〇機能の異常系テストを実施する

PBI-4:ユーザーにクーポンコードを送付する

PBI-5:管理画面でクーポンコード送付時の送信内容を設定できる

PBI-6:管理画面でクーポンコードが設定できる

PBI-7:管理画面でテストメールが送信できる

PO
開発者

了解でーす!

6. 開発者は、プラニングポーカーにてPBIのポイントを見積る

それでは、今後のスプリントへ向けて、本日話したPBIに対して、開発者にてポイント見積りをお願いします!

SM
開発者

了解です。

いつも通り、プランニングポーカーでポイントを見積りしていきましょう!

※プランニングポーカーの具体的な説明は、別記事を作成予定です。今しばらくお待ちください。

上記のような流れでリファインメントを実施します。
リファインメントでは、PBIの詳細化の他に今後のプロダクトゴールへ向けた確認など、POと開発者の認識合わせの場としてもOKです。

まとめ

  • リファインメントは、プロダクトバックログアイテムをより詳細にするイベント。
  • タイムボックスは、1週間のスプリント場合は1〜2時間、2週間スプリントの場合は2〜4時間が目安。
  • スクラムチームで認識合わせができ、全体像を確認できる。
  • PBIを小さく分割し、詳細化することで、見積りのしやすさ、正確さが向上する。
  • PBIの見積りまで実施し、PBIをReadyな状態にする。

Sponsored Link

コメント

タイトルとURLをコピーしました