PBL作成のポイントプロダクトオーナー

開発チーム

スプリント
バックログ

プロダクトスクラムマスター

バックログ

インクリメント

ステークホルダープロダクトバックログの順序付けの基準
複数の観点から並び替える①インセプションデッキの「われわれはなぜここにいるのか」を達成するために必要なもの※⽬的には、プロダクトレベル、プロジェクトレベルがある②検証のために必要なもの (早く形にする必要がある機能)③技術観点 (プロダクトの基礎にあたる機能、早めの検証が必要な技術)①-③の間で優先度きめるのではなくて、①の観点で並び替え、②の観点で並び替え…と何度も繰り返すことで、全体の順序の納得感と合意を得るようにする。

プロダクトバックログ分割の基準：INVEST
5つの観点で分割する
Independent 独⽴している
先⾏する機能が完了してないと始められないなど他の影響を受けない。
Negotiable 交渉可能であるアイテムが具体的なタスクに落ちすぎておらず、プロダクトオーナーと実現⽅法について交渉することができる。
Valuable 価値がある
アイテム単独で顧客にとっての価値があること。
Estimable ⾒積もり
アイテムを⾒積もれるだけ、⼗分な情報があること。
Sized Right (Small) 適切な⼤きさである（⼩さい）実現するのに要する時間が⻑すぎない程度に分割されていること。
Testable テスト可能である
その開発が完了したかどうかをテストできること。受け⼊れ条件が明確になっている

PBLの表記
基本は3段構成（ユーザーストーリー形式）< ユーザー/顧客 > として< XXXを達成 > したい
なぜなら < YYY > だからだ
XXXが実現したいこと、YYYがその理由となる。
別表現：WHOとして、WHATしたい、なぜなら WHY だから。

PBL毎に受け⼊れ条件を設定する
基本はGWT
G=Given：〜な状態、条件下でW=When：XXXをしたら、T=Then：YYYができる、YYYという結果になる
少なくとも「〜できる」という語尾で条件をまとめること何ができれば、このPBIは完成したと⾔えるのか？
複数の条件になることも当然ありえる(ただしテストケースではない。条件をあまりにも網羅的にするとテストケースになってしまうので注意)

PBL作成の実際①
PBLをどこまで詳細にするべきなのかどの程度のインプットで、どういう精度のアウトプットが⽣み出せるは、以下に左右される。
① 該当テーマに対するチームの知⾒（経験値）② 「つくる」こと⾃体のチームの⼒量③ 該当テーマの難易度（複雑なルールの実装など）④ チーム外との関係性が複雑（多様な関係者の存在）ゆえに「絶対的にここまで詳細にするべき」という基準はない※対話で認識を揃えきれないならば補⾜の資料も作る

PBL作成の実際②PBLをいつ詳細化するか
最初期…MVP特定〜リリースプランニングの間
その後…次の（次の次の）スプリントをイメージしてそれまでにバックログリファイン
メントMVP特定※PBLのメンテンナンス⾏為

スプリントゼロ※スプリントゼロがどのくらいの⻑さになるかは、前述のとおり必要なインプットの量による（つまりチームに依る）

PBL作成の実際③PBLは誰が詳細化するかチームで⾏う（プロダクトオーナーが1⼈でやるわけではない）
つまり、スプリントの活動として織り込む必要がある「PBL詳細化する⼈」「受け取る⼈」という分け⽅は、スクラムの本意とならない。

PBL作成の実際④PBLをどうやって詳細化するか
プロダクト全体に影響を及ぼす → 早めに認識揃える
影響範囲は独⽴したPBIの範囲 → 開発までに揃える
全体(プロジェクトやテーマ単位での繰り返し)・リリースプランニングとその為に必要なPBLの整理
・アーキテクチャ設計
・プロダクトの情報設計
・概要レベルのデータモデリン
グ、ドメインモデリング部分(スプリント単位での繰り返し)
・PBIの受け⼊れ条件
・PBIに必要な機能の分割
・上記機能の仕様詳細
・PBIに必要なデータの設計
・PBIに関係するUIのデザイン
・PBIの受け⼊れテストケース

PBL作成の実際④PBLをどうやって詳細化するか全体と個別の詳細化を繰り返し進めていくイメージ↑スプリントの途中なのでここが漏れやすいスプリントレビューを実施しようプロダクトオーナー

開発チーム

スプリント
バックログ

プロダクト

スクラムマスター

バックログ

インクリメント

ステークホルダー

スプリントレビューとは？(⽬的)⽬的
アウトプットを提⽰することで、チームや関係者全員からフィードバックや協⼒を引き出す
・スプリントプランニングではスプリントで⾏うことの計画作りをする。
スプリントレビューではその結果の検査(と適応)を⾏う
・期待以上の結果も、不都合な真実も含めて、プロダクトの「今」を⾒れる機会
・アウトプットについて、質問をしたり、観察や提案をしたり、「今」を踏まえ今後の⽅針について議論を⾏う
・議論の⽬的は「価値を最⼤化するためには次に何ができるか」
批評だけして終わりとか、ただ進捗を確認するだけではなく、建設的に今後の具体的な⽅針ややることを考える会。
(誰かが誰かを吊るし上げるような会ではない)スプリントレビューとは？(参加者)
参加者
開発チームおよびプロダクトオーナー、スクラムマスター
ステークホルダー（関係者）
・スプリントの実施に毎⽇参加できないような⼈たちからフィードバックを得る機会。ゆえに、「本来は意⾒がほしいけどなかなか貰えていない⼈たち、専⾨家、ユーザー」「営業、法務コンプラなど事業的に関わりがある⼈たち (インプットを得たい)」「直接状況を⾒て適宜軌道修正をかけていきたいビジネス上のスポンサー」など、幅広くなる。
・常に全員ではなく、スプリントゴールや対象となるプロダクトバックログに関連の強い⼈を特に招き⼊れること。

スプリントレビューとは？(タイミング)
タイミング
スプリントの終了⽇・スプリント結果の検査だから、スプリントの終わりに⾏う・スプリントレビューにかける時間は、2週間スプリントの場合 → 2時間
1ヶ⽉スプリントの場合 → 4時間を⽬安とする。

スプリントレビューとは？(インプット)
インプット
スプリントバックログ
スプリントゴール
開発を完了しているプロダクト(機能)・スププリントレビューではスプリントゴール(⽬標)とプロダクト(結果)との⽐較を⾏う。ゆえに、その両者が必要となる。
・スプリントゴールに対して、何が達成できているのか、達成できていないことは何かを確認する。
(あくまでその結果を踏まえて次に⾏うべきことを決める)

スプリントレビューとは？(アウトプット)
アウトプットリファインメントしたプロダクトバックログ
更新されたリリースプラン
・スプリントレビューでの議論は2つのレベルに影響を与える。
① 次にやるべきこと (プロダクトバックログ)② 今後何をいつリリースするのか (リリースプラン)・関係者全員でプロダクトの「今」と、「今後」⽬指したいことを確認し、新しいプロダクトバックログアイテム(PBI)や既存のPBIの修正、優先順位の変更、不要となったPBIの削除を⾏う
・さらに⼀つ⼀つのPBIのレベルを越えて、リリースするスコープや⽇付、予算に関する意思決定も必要に応じて⾏うスプリントレビューとは？(事前準備①)
事前準備
誰を集めるのかを決める
スプリントの成果が受け⼊れ可能か判断する
デモの準備
ステークホルダー向けの補⾜資料

スプリントレビューとは？(事前準備①)
事前準備
誰を集めるのかを決める
・必要なステークホルダーは誰なのか判断し、先にスケジュールの確保を依頼しておく。まずはチームが固定しているレビュー⽇に決てもらうよう調整をかけるが⽇程が合わない場合は、別途そのための⽇程を予定に追加する。

スプリントの成果が受け⼊れ可能か判断する・スプリントレビューでは完成したものだけデモを⾏う。ゆえにレビューが始まる前に完成しているかどうかの判断を⾏っておく必要がある。
・POはジャストインタイムで、完成したPBIを事前に確認しておく。
(POは受け⼊れのための基準(テスト)を⽤意しておき、確認する)スプリントレビュー補⾜
POの確認パターン① 事前に結果を確認しておく・こちらがスクラムガイドにおける王道。
・スプリントレビューで、POがステークホルダーと⼀緒に結果を初めてみるということはやらない。
・その狙いはすばやいフィードバックをかける。スプリントレビュー時間を置かないため、チームのテンポがよくなる。リリースも早くなる。

POの確認パターン② レビュー⽇に結果を確認する
・とはいえ様々な背景から出来ないこともある。
- POが頻繁に時間を取ることができない- 1週間スプリントのため結果を出すまで、また確認⾏為が⽴て込んでしまう- プロダクトのサイズが⼩さく、ステークホルダーもPO以外ほぼいない- チームのフル稼働ではなく、スプリント内での軌道修正がそもそもかけられない
・以上の場合、1週間後のスプリントレビューでPOが確認するというパターンも実際にはありえるスプリントレビューとは？(事前準備②)
事前準備
デモの準備
・POが確認を終えられていれば、環境的な準備は終わっているはずだが、データの準備など他に必要なことがあれば済ませておく(肝⼼のデモで動かないということが無いように！)・デモ実施のためのシナリオを⽤意しておく・レビューで、誰が何をするか決める※フィードバックを得るためにはスムーズな進⾏が必要ということ

ステークホルダー向けの補⾜資料
・毎⽇チームやプロダクトに接していない⼈に向けて、⽂脈を補⾜する情報を提供する。
・特に、全体感を⽰す情報(⽇程感、プロダクトの⽅向性)は必要になりがち。
・ただし、こちらの説明がメインではないので資料作成に時間を使いすぎないことスプリントレビューとは？（内容①）内容
1. チェックイン
・普段コミュニケーションをしているわけではないステークホルダーが参加することもありえる。冒頭で、⾃⼰紹介やスプリントレビュー⾃体の⽬的について確認をする。
2. 前提事項の確認
・いきなりデモに⼊らず、このスプリント実施にあたって存在した前提、またスプリント中に判明した制約や条件などがあれば先に掲げておく
3. スプリントゴール及び、対象プロダクトバックログの説明
・スプリントゴールがなんであったか、またゴール達成のために必要とおいたプロダクトバックログは何か、説明する。
・そのうち完成したPBI、完成していないPBIは何か明らかにする。

スプリントレビューとは？（内容②）内容
4. デモおよび質問、フィードバック
・デモシナリオに基づいてチームもしくはPOが操作し、フィードバックを得るようにする。
・デモの操作者、進⾏役、フィードバックの記録など必要に応じて分担して進める(事前に決めておく)5. スプリントレビューの整理
・フィードバックとして挙がった内容について、再度確認を⾏い、扱いについて検討する（アイデアとして残すだけ、PBIとして対応する等）・プロダクトバックログやアイスボックス(⼀時保管)に必要なPBIを追加する
6. 今後の⾒通しと意思決定
・スプリントの結果を受けて、今後のリリースプランに何か変更を加るのであればその確認。踏まえて全体の予定を⾒直す。

スプリントレビューをより上⼿く進める⼯夫スプリントレビューで確認することチームからステークホルダーへの質問
・⾒たものが気に⼊ったか、何が気に⼊り、何が気に⼊らなかった
・期待どおりではなかったところはあるか・プロダクトを⾒ることによって何か思いついたところはあるか・プロダクトを成功させるために変えるべきところはあるか
・この⽅向性で作り進めていって問題はなさそうか
・不⾜している機能、過剰な機能はないか
・⾒た⽬で、動きで調整が必要なところはないかなどを質問する。これらの質問に対してステークホルダーが回答する内容をそのまま実現しなければならないということではない。
あくまでフィードバックとして受け⽌めて、対応可否については別途検討するスプリントレビューで受け⼊れをしないこと受け⼊れを⾏うのはあくまでプロダクトオーナー「スプリントレビューより前にPOが受け⼊れを確認しておくこと」を挙げたのは、スプリントレビューが受け⼊れの場ではないから。
受け⼊れの場にしてしまうと「ステークホルダーによる受け⼊れ」⾏う場と同義になってしまいかねない。これをやると「意思決定をPOに1本化する」前提が崩れ、プロダクトの⽅向性がブレかねない。

ステークホルダーマネジメントを⾏う
期待マネジメントはPOやスクラムマスターが引き受ける
ステークホルダーによってはスクラムのルールについて理解が不⾜しており、スプリントレビューで進捗を確認したり、受け⼊れをしたりすることがある。
これをやりはじめると、意思決定が定まらず、プロダクト開発が迷⾛しかねない。
ステークホルダーにスクラムの説明を⾏い、理解を⾼める活動はスクラムマスターが⾏う。⼀⽅、POは、ステークホルダーが何を期待しているかの把握、状況の共有について⾏うようにする。これらはスクラムイベントの外で⾏う。
スクラムイベントは、あくまでプロダクトの価値を⾼めていく場として捉え、チームがそのことに集中できるよう場作りを⾏うのが理想的であるスプリントレビューに必要な⼈を揃えるレビューとはプロダクトの価値を確かめる最前線
繰り返すがスプリントレビューでは、フィードバックに基づく対話を重視する。
ゆえに、この場に⼈が集まらないのは、前提が整っていないと⾔える。
プロダクトの価値やビジネスの可能性を確かめるべき⼈が必ず参加すること。
逆に、スプリントレビューに⼈が集まらないようでは、プロダクトに時間を使う価値がないということであり、プロダクト開発を中⽌した⽅が良い可能性がある。関係者に対して「プロダクトをより良いものしていく」ことへのコミットメントを求めること。

着地の予測をすること
スプリントを終えるごとに予測を⾏う
スプリントを終えるごとに、いつリリースができるのかの着地を⾒⽴て直すこと
スプリントが期待どおりにいかない場合、何か積み残してしまう場合、あるいは思いの外進みが良かった場合など、いずれにしても想定しているリリースに必要な残スプリント数に影響が出ることがある。
これを放置しているとステークホルダーとの期待が⼤きくなっていく可能性がある。
最初は⼩さな期待違いでも、積み重なっていくと、想定したスプリントの数と⼤きな開きができ、必要予算にも影響が出てくる。
⾒⽴ては変わっていくものなので「予定どおりであること」を⽬指せということではなく、着地の変化をタイムリーに共有していくようにしよう。

スプリントレトロスペクティブを実施しようプロダクトオーナー

開発チーム

スプリント
バックログ

プロダクト

スクラムマスター

バックログ

インクリメント

ステークホルダー

スプリントレトロスペクティブとは？(⽬的)⽬的チームへのレビューを踏まえて、カイゼンに踏み出せるようにすること・⼈、関係、プロセス、ツールの観点から実施したスプリントを検査(レビュー)する
・上⼿くいったことや、今後のカイゼンが必要なことを⾒つける、整理する・スクラムチームのカイゼンプランを⽴てる※スプリントでの学びを早速次のスプリントに活かすことができるスプリントレトロスペクティブとは？(参加者)
参加者
開発チームおよびプロダクトオーナー
スクラムマスター・スクラムチームの活動をふりかえるためのものなので、参加者はチーム全員。
・スクラムマスターがファシリテートを⾏う※スクラムマスターはチームの状態を捉えられている必要がある
ただし、プロダクトオーナーがチームと信頼関係をまだ築けていないようであれば参加は⾒合わせる。POは権威が強い場合があり、議論に遠慮が発⽣する可能性があるため。スクラムとして望ましい振る舞いを考える上で、忖度がないようにする
これはステークホルダーに対しても同様である。あくまでチームが⾃分たちの判断でカイゼンできる状況を作ることが前提。

スプリントレトロスペクティブとは？(タイミング)
タイミング
スプリントの最終⽇
・スプリントレビューの後に⾏う（レビューでの内容も踏まえるため）・タイムボックスは、
2週間スプリントの場合 → 1.5時間
1週間スプリントの場合 → 1時間

スプリントレトロスペクティブとは？(インプット)
インプット
客観的なデータ
主観的なデータ
カイゼンバックログ
・客観的なデータは、チームやプロダクトに関するデータが対象となる。
ベロシティや、PBLのリードタイム、不具合数、レビューの指摘数などを⽤いる
・主観的なデータは、個々⼈の課題感、所感・思いなどである。ふりかえりまでに個⼈で短くふりかえりをやっておくと取り出しやすい・カイゼンバックログは、前回レトロスペクティブのアウトプットである。
カイゼンの対象項⽬が⼊ったリストのことである。

スプリントレトロスペクティブとは？(アウトプット)
アウトプットカイゼンバックログ
特に次のスプリントで実施したいこと
・先に述べたように、カイゼンバックログとはレトロスペクティブで挙げられたカイゼン項⽬のことである。⼀度に解決、実施できないこと多いため、これらの項⽬もバックログ管理する・カイゼンバックログで挙げた内容は、スプリントプランニング時に、スプリントバックログへの追加を適宜⾏う
・特に、次のスプリントで実施したほうが効果的な項⽬については、特定をしておき、実施の優先度を⾼める。

スプリントレトロスペクティブとは？(事前準備)
事前準備

プラクティスの準備
・レトロスペクティブのやり⽅にも様々なパターンが存在する。どのプラクティスをどのような狙いで採⽤するか検討しておく。
①タイムラインふりかえり (状況を思い起こすためのふりかえり)
時間軸にそってどういう出来事合ったかをプロットしていく
ふりかえりタイムボックスが⻑い⽬のチームで⾏う②感情セイスモグラム (主観的なデータが可視化される)出来事に沿って、チームメンバーの感情の遷移も可視化するスプリントレトロスペクティブとは？（内容①）
内容
アクションを計画に織り込むまでがふりかえり① ルールを確認する
・⽬的はあくまでカイゼン。⼈を⾮難するための場ではない。
ふりかえりを実施するにあたってのルールを確認すること。
・前回ふりかえりのふりかえりを確認しておく② コンテキストを共有する
・客観データを確認する(ベロシティ、不具合数他)
・主観データを可視化する(タイムラインふりかえり→感情セイスモグラム)③ インサイト（気づき）を得る
パターン1 「エッセンシャルスクラムの3つの問い」
・何がうまくいったのか？
・何がうまくいかなかったのか？
・やり⽅を変えるところはないか？

スプリントレトロスペクティブとは？（内容②）
内容
アクションを計画に織り込むまでがふりかえり③ʼ インサイト（気づき）を得る
パターン2 「KPT」 Keep / Problem / Try
パターン3 「YWT」 Yatta / Wakatta/ Tsugi：※Tryを検討するにあたり、前回のふりかえり結果(カイゼンバックログ)を持ち込み、解消されているものなどを確認すること※気づきを引き出すインサイトワークの引き出しを充実させていくのも必要④ アクションを決める
・気づきのうち、特に優先するべき「次にやること」を特定する→ ドット投票などで、チームの意思を反映し決める
・特定したアクションを「カイゼンバックログ」に積む・スプリントプランニングでカイゼンバックログも実施対象にする

スプリントレトロスペクティブとは？（内容③）
内容
アクションを計画に織り込むまでがふりかえり⑤ ふりかえりのふりかえり
・ふりかえり後に、ふりかえり⾃体のふりかえりを⾏う・毎回⾏う必要はない。ふりかえり⾃体が上⼿く機能していないと感じるとき、マンネリを感じるときに実施する。
・スクラムマスターがふりかえりのふりかえりをリードする・ふりかえり⾃体のKeep / Problem / Tryをあげる

スプリントレトロスペクティブをより上⼿く進める⼯夫スプリントレトロスペクティブでの問題① 参加者が集まらない／開催されない問題
レトロスペクティブはもっとも省略されやすい、スクラムイベント。
実施しなくても、即座に致命的な問題が常に発⽣するわけではない。
また、参加しなくても個⼈として次のスプリントの活動に⽀障をきたすわけではない。ゆえに省略されやすい。
実際には、数あるプラクティスの中で「ふりかえり」こそ実施すべき。
なぜなら、カイゼンのサイクルが回り始めないためである。
カイゼンの動きがなければ、反復開発の意義は⼤幅に減ることになる。
(分かったことに基づいて次の活動を最適化するという動きが始まらない)スプリントレトロスペクティブでの問題② 責任追及／吊し上げ問題
ふりかえりを開催したとしても、検知した問題の犯⼈探しに躍起になり、責任追及、吊し上げと発展してしまう。こうした⾏為が⾏われると、「カイゼンに繋がらない」「失敗を恐れるようになってしまう」といったマイナスの影響が強くなる。
この事態が発⽣しないよう、もっとも注意をしたい。
①ルール確認のところで、責任追及が⽬的ではないこと②ふりかえり実施中に、スクラムマスターが状態を保全する③ふりかえり後のふりかえりで、(発⽣していた場合)状態の問題を指摘し注意を促す。

スプリントレトロスペクティブでの問題③ 意識⾼すぎる／正義はわれにあり問題
カイゼン意欲が⾼まり過ぎて、些細な問題でも⽬くじらを⽴ててしまう
すべての問題を根絶やしにしようと動いて、多⼤な時間をかけてしまう
⼀般的な原理原則を外から持ち込んできて、それと異なる状態をすべて問題として捉え、対処あるいはメンバーを追求してしまう。
以下を、ふりかえりのルールに追加するなりして⾏き過ぎの⻭⽌めをかける・チームメンバーひとりひとりの意⾒に⽿を傾ける・チームとしての意思決定を尊重する(特定の誰かに引っ張られていないか)・チームとしてのありたい姿、現状と照らし合わせて判断を⾏うスクラムマスターの⼼得

スクラムマスターとは？
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。
スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。
スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。

スクラムチームとともに⾃⼰管理型で機能横断型のチームメンバーをコーチする。
スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できるよう⽀援する。
スクラムチームの進捗を妨げる障害物を排除するように働きかける。
すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックスの制限が守られるようにする。

プロダクトオーナーとともに効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀援する。
明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
複雑な環境での経験的なプロダクト計画の策定を⽀援する。
必要に応じてステークホルダーとのコラボレーションを促進する。

組織とともに組織へのスクラムの導⼊を指導・トレーニング・コーチする。
組織においてスクラムの実施⽅法を計画・助⾔する。
複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
ステークホルダーとスクラムチームの間の障壁を取り除く。