ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう

Slide 1

Slide 1 text

ユーザーストーリーマッピングを使ってプロダクトバックログを作ろうノーストーチ株式会社伊藤いづみ @izumii19

Slide 2

Slide 2 text

今日のゴールユーザーストーリーマッピングを体験してみよう「プロダクトバックログは一体どうやって作るの？」という質問を受けることがありますが、実際には色々な方法があると思います。今日はプロダクトバックログを作成する方法としてユーザーストーリーマッピングをやってみましょう。 2

Slide 3

Slide 3 text

今日のゴールプロダクトバックログや、これに関連する知識もおさらいしましょう ⚫ プロダクト ⚫ プロダクトオーナー ⚫ プロダクトゴール ⚫ プロダクトバックログ ⚫ プロダクトバックログアイテム 3

Slide 4

Slide 4 text

おさらい：プロダクト

Slide 5

Slide 5 text

プロダクトプロダクト＝顧客へ価値を提供する手段 ⚫ ソフトウェアそのものに価値があるわけではない ⚫ 顧客がソフトウェアを利用して問題を解決したり、ニーズを満たすことができた時に価値は生まれる ⚫ ソフトウェアに加えサービス、サポートなども価値に含まれるプロダクト＝ソフトウェアプロダクト⊃ソフトウェア 5 ソフトウェアサポートサービスプロダクト

Slide 6

Slide 6 text

おさらい：プロダクトオーナー

Slide 7

Slide 7 text

プロダクトオーナー (スクラムガイド2020より抜粋) プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、プロダクトゴールを策定し、明示的に伝える。プロダクトバックログアイテムを作成し、明確に伝える。プロダクトバックログアイテムを並び替える。プロダクトバックログに透明性があり、見える化され、理解されるようにする。上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 7

Slide 8

Slide 8 text

プロダクトオーナー (スクラムガイド2020より抜粋) プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能なインクリメントによって見える化される。プロダクトオーナーは 1 人の人間であり、委員会ではない。プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する 8

Slide 9

Slide 9 text

プロダクトオーナーつまり、プロダクトオーナー(PO)は ⚫ プロダクトの価値を最大化する ⚫ 効果的なプロダクトバックログ (PBL)管理を行う • プロダクトゴールを策定し、明示的に伝える • プロダクトバックログアイテム (PBI)を作成し、明確に伝える • PBIを並び替える • PBLに透明性があり、見える化され、理解されるようにする ⚫ プロダクトの増加について受け入れるかどうかを判断する 9

Slide 10

Slide 10 text

POが参加するイベント 10 今日はここ

Slide 11

Slide 11 text

おさらい : プロダクトゴールとプロダクトバックログとプロダクトバックログアイテム

Slide 12

Slide 12 text

プロダクトゴール（PG）とは ⚫ プロダクトバックログに対する確約（コミットメント） ⚫ プロダクトの将来の状態を表しており、スクラムチームの計画のターゲットになる ⚫ プロダクトゴールはプロダクトバックログに含まれる ※スクラムガイド2020のアップデートにてプロダクトゴールが導入された 12 PBL PG

Slide 13

Slide 13 text

プロダクトバックログ（PBL）とは ⚫ プロダクトバックログアイテム(PBI)を集めたリスト ⚫ スクラムチームが行う作業の唯一の情報源である ⚫ PBIが優先順の高い順番に並んでいる*1 ⚫ 優先順位の高いPBIには詳細な記述が必要優先順位の低いPBIは曖昧でも良い（定期的な見直しは必要） ⚫ PBIの並べ替えについてはPOが責任を持つ *1 一般的にはビジネス価値の高いものが上位に来る傾向にある 13 PBI PBI PBI PBL PG

Slide 14

Slide 14 text

プロダクトバックログアイテム（PBI）とは ⚫ プロダクトゴールを達成する「何か（what）」 ⚫ POが価値があると判断したものはなんでもPBI 機能タスク／不具合対応／技術改善／スキルアップ顧客に見える部分／見えない部分ソフトウェア以外のもの（インフラとか）将来の価値をうむもの（検証、学習、実験） 14 PBI PBI PBI PBL PG

Slide 15

Slide 15 text

プロダクトバックログアイテム（PBI）とは ⚫ 良いPBIの基準 • 見積もり可能 • 受け入れ基準が明確 • 1スプリント内で終わる大きさ • デモ手順を決めることができる • 可能な限り独立 15 PBI PBI PBI PBL PG

Slide 16

Slide 16 text

1：PBLの作り方

Slide 17

Slide 17 text

PBLはどうやってつくる？ ⚫ 作り方に決まりはなくやり方は色々あります！ ⚫ ユーザーストーリーを書いて作る方法が広く知られている ⚫ 今回は以下の方法でTry！ 1. PGを理解する : インセプションデッキ 2. PBLを作成する : ユーザーストーリーマッピング 17

Slide 18

Slide 18 text

1.プロダクトのゴールを理解するインセプションデッキ 18 • 我々はなぜここにいるのか • エレベーターピッチ • パッケージデザイン • やらないことリスト • 「ご近所さん」を探せ why • 技術的な解決策 • 夜も眠れない問題 • 期間を明確にする • トレードオフスライダー • 何がどれだけ必要か how 今日はこれ

Slide 19

Slide 19 text

エレベータピッチ ⚫ ごく短い時間でプロジェクトやアイディアの本質を伝える ⚫ 誰のために何を作るのかを明快にする (あらゆる人の望みに応えるものを作るわけではない) 19

Slide 20

Slide 20 text

エレベータピッチ 20

Slide 21

Slide 21 text

2.ユーザーストーリーマッピングやり方 1. ユーザストーリーを書く 2. ナラティブフローを作る 3. 別のストーリーを探る 4. ナラティブフローを整理する 5. バックボーンを抽出 6. MVPリリースを切り出す 7. リリーススライスを引く 21

Slide 22

Slide 22 text

2-1. ユーザーストーリーを書く ⚫ 顧客が実現したいと思っているフューチャー*1 ⚫ 書き方に決まりはない（よく使うテンプレはあるよ） *1 フューチャー＝顧客の価値。お金を払ってでも欲しいと思えるもの *2 こういうのも顧客の価値。テンプレにこだわらず価値であれば書き出しておく 22 ストーリーカード［ユーザーの種類］として［達成したいゴール］をしたいなぜなら［理由・目的］だからだ制約*2 ○秒以内に表示できることストーリーカード［一般ユーザー］として［買った本を簡単に管理］したいなぜなら［同じ本をダブって買いたくない］からだ

Slide 23

Slide 23 text

2-2. ナラティブフローを作る ⚫ ユーザーストーリーを並べて物語を作る ⚫ マップの左から右へ向かうフロー ⚫ 「まず私はこれをした」「” それから私は”これをした」 23 制約ストーリーカードストーリーカードストーリーカードストーリーカードこれは置いといて・・・まず私はこれをしたそれから私はこれをしたそれから私は… それから私は…

Slide 24

Slide 24 text

2-3.別のストーリーを探る ⚫ ナラティブフロー以外のバリエーション • ユーザー別 • シチュエーション • 詳細、代替え、制約、例外など 24 制約詳細詳細制約制約ナラティブフロー新規登録者一般ユーザー A-1 A-2 ユーザーによる違い非機能っぽいやつとか大きいストーリーの分割新しく出てきたストーリー例外 Sign in

Slide 25

Slide 25 text

2-4.ナラティブフローを整理 ⚫ 別なストーリーを探っている中で出てきたストーリー、レベル合わせ ⚫ 順番の見直し 25 制約制約制約ナラティブフロー新規登録者一般ユーザー A-1 A-2 追加入れ替えレベル合わせ Sign in 例外

Slide 26

Slide 26 text

⚫ 共通の目標に向かうタスクを集約する（アクティビティの作成） 2-5.バックボーンを抽出 26 制約制約制約ナラティブフロー新規登録者一般ユーザー A-1 A-2 ユーザーは使用する準備を行うユーザーの情報を管理する本の情報を管理するアプリの使い方を知るバックボーン Sign in アクティビティ例外

Slide 27

Slide 27 text

⚫ Minimum Viable Product(MVP:望まれる成果を実現できる最小の製品) 2-6. MVPリリースを切り出す 27 制約制約制約ナラティブフロー新規登録者一般ユーザー A-1 A-2 ユーザーは使用する準備を行うユーザーの情報を管理する本の情報を管理するアプリの使い方を知るバックボーン Sign in MVP 最初のリリース！例外

Slide 28

Slide 28 text

⚫ 特的の目標を実現しやすいようにタスクをスライスする 2-7.リリーススライスを引く 28 ナラティブフロー A-1 A-2 ユーザーは使用する準備を行うユーザーの情報を管理する本の情報を管理するアプリの使い方を知るバックボーン Sign in リリース１制約制約制約例外やらない！リリース2 リリース3 MVP 新規ユーザー向け機能操作性の向上

Slide 29

Slide 29 text

2-8.ユーザーストーリーマップ完成 29 ナラティブフロー（物語） A-1 A-2 ユーザーは使用する準備を行うユーザーの情報を管理する本の情報を管理するアプリの使い方を知るバックボーン (骨格) Sign in リリース１ MVP 制約制約制約リリース3 例外リリース2 優先順位

Slide 30

Slide 30 text

PBLにする 30 1 2 4 5 リリース１ MVP リリース3 … 8 リリース2 7 各リリースの中でも優先順位をつける PBL PG 1 2 4 5 7 …

Slide 31

Slide 31 text

この形に近づけよう ⚫ 優先順位の高いPBIには詳細な記述が必要 ⚫ 優先順位の低いPBIは曖昧でも良い ⚫ 見積もり可能 ⚫ 受け入れ基準が明確 ⚫ 1スプリント内で終わる大きさ ⚫ デモ手順を決めることができる ⚫ 可能な限り独立良いPBIになっているか確認 31 PBL PG 1 2 4 5 7 …

Slide 32

Slide 32 text

ユーザーストーリーマッピングの良いところ 1. プロセス：３つのC Card:カードに書く、Conversation:会話する、Confirmation:確認する 2. 全体像を把握しやすい 3. ユーザー視点でストーリーを語ることができる 4. 追加、削除、入れ替えが容易なので最新を保ちやすい 5. ストーリのレベル・粒度を揃えやすい 6. 言葉が消えていくを防ぐ大切なのはドキュメントを書くことではなく会話から生まれる共通理解 32

Slide 33

Slide 33 text

大切なのは会話から生まれる共通理解

Slide 34

Slide 34 text

Enjoy ユーザーストーリーマッピング！

Slide 35

Slide 35 text

参考資料 ⚫ ユーザーストーリーマッピング ⚫ SCRUM BOOT CAMP THE BOOK ⚫ アジャイルサムライ−達人開発者への道− ⚫ 5分で分かるスクラム用語集 ⚫ プロダクトバックログ項目の明確化の必要性インセプションデッキのテンプレート ⚫ 簡単！楽しい！5分でわかるユーザーストーリーマッピング(User Story Mapping) 35

Slide 36

Slide 36 text

おまけ：実際にやってみたマップ 36