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 リリース1 制約 制約 制約 例外 やらない! リリース2 リリース3 MVP 新規ユーザー向け 機能 操作性の向上

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

PBLにする 30 1 2 4 5 リリース1 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. プロセス:3つの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