『ユーザーストーリーマッピング～後編～』第3回 POStudy 〜プロダクトオーナーシップ勉強会〜

ユーザーストーリーマッピング
～後編～
2011年10月14日（金）第3回 POStudy
@fullvirtue
1Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.

POStudyのご紹介（1/3）
POStudy（プロダクトオーナーシップ勉強会）とは（1/1）
 日本のITサービス業界において「プロダクトマネジメント」と
いう分野が欠落していると言われています。そんな中で、
いかに「プロダクトオーナーシップ」を発揮していくかについて、
普段の生活や仕事を通して自己成長を重ねていく為のヒントを
提供していきます。
– 【オフライン】
» 東京・沖縄を中心にワークショップ形式の勉強会を通じて
「参加者同士で議論」を行い「情報交換」をすることで
互いに有益な場を作っていきます。
– 【オンライン】
» ワークショップを中心とした動画・静止画コンテンツを
配信していきます。

POStudyの情報を得るには（1/1）
Question Answer / URL
イベント情報のメール通知を
受け取りたいときは？
POStudy用のDoorKeeperへメンバー登録してください！
次回以降の告知やお知らせがメールで届きます。
http://postudy.doorkeeper.jp/
過去の資料を閲覧したり、
参加レポートを参照したい
ときは？
以下のPOStudy公式サイトにて過去の資料や今後の予定等
を公開しています。
https://sites.google.com/site/spostudy/
ツイートする時の
ハッシュタグは？
以下のハッシュタグをお使いください！
#postudy
POStudyの最新情報が欲しい、
or 参加者と議論をしたいとき
は？
POStudyのFacebookグループへご参加ください！
https://www.facebook.com/groups/postudy/
Twitterによるお知らせを
購読したいときは？
POStudyのTwitterアカウントをフォローしてください！
https://twitter.com/POStudySmile/

過去に実施してきたテーマ（1/1）
実施日テーマ参加者
第1回 2011/09/16（金）アジャイルとスクラム 9名
第2回 2011/09/30（金）ユーザーストーリーマッピング ~前編~ 18名
第3回 2011/10/14（金）ユーザーストーリーマッピング ~後編~ -
第4回 2011/10/28（金）ユーザーストーリーマッピング ~再演~ -

Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.
今日のアジェンダ（1/1）
第2回の復習
第2回各チーム振り返り結果ご紹介
ワークショップ #4
スプリントとリリース解説
プランニングポーカーと見積もり解説
振り返り＆ディスカッション
成果発表＆共有
5

おことわり（1/1）
今回の資料について（1/1）
 今回の資料は、以下の資料を参考にしています。
私自身のオリジナルはほとんどありませんので、
ご了承ください。
 前半のプロダクトバックログの説明部分と
後半のワークショップは、
@kawaguti さんがScrum Boot Campで
使用した資料を参考にさせて頂いています。
 前半のユーザーストーリーの説明部分については、
@ryuzee さんの公開資料
http://www.slideshare.net/Ryuzee/ss-8332120
を参考にさせて頂いています。
Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 6

第2回の復習
いきなり本題に入る前に、前回の復習をしましょう
7

第2回目の復習（1/16）
スクラムの進め方（1/2）
• 出典：MOUNTAIN GOAT SOFTWARE
http://www.mountaingoatsoftware.com/scrum/figures
8
PO SM
プロダクトオーナースクラムフィーチャーチーム
マスター＋スクラム

プロダクトバックログ（1/1）
# 概要デモ方法優先 SP
21 管理者画面を利用出来る
トップ画面から「管理者」ボタンで
画面に遷移
700 3
25
管理者として
ログインできるようになる
管理者権限を持つIDだけに「管理者」ボタ
ンを表示するところを見せる
640 5
27
セッションは15分間維持
されるが、その後は破棄
操作終了後15分待ってから操作を行う
（その間は、他のデモを見せる）
500 2
24
管理画面は50件ごとに
ページを分けて表示
管理画面を表示する。
次ページを選択して
最終ページまで見せる
490 2
29
タイトルを文字列検索で
探すことが出来る
トップ画面の検索窓に入力し、
検索結果画面へ。
～項目をクリックして
470 3

スプリント計画（1/4）
 スプリント計画第1部では、チームの到達範囲を予測
ベロシティ＝６
2
1
3
5
1
2
1
3
当スプリント
で着手

ベロシティ＝８
2
1
3
5
1
6

2
1
3
5
1
6
2
1
3
1
5
7

2
1
3
5
1
6
2
1
3
1
5
7
2
1
3
2
3
1
8

タスクボード（1/1）
#172
リリース作業
3/22 18:00
#195
障害調査
IE6で表示が
崩れる
#193
件名からの
絞り込み表示
ができる 1
2
3

バーンダウンチャート（1/1）

ユーザーストーリーとは（1/2）
 要求仕様を自然言語で簡潔に記述したもの
 [役割]として
 [結果]が欲しい
 それは [理由]のためだ
 [役割]として
 [機能や性能]が欲しい
 それは [ビジネス価値]のためだ

ユーザーストーリーとは（2/2）
 顧客との会話に役立つ
 計画づくりに役立つ
 無駄な詳細化から解放される

なぜユーザーストーリーが必要なのか（1/1）
 要件（機能）のスケジュールが可能なユニット
– スケジュールは他に依存していない
 ユーザーがどう使うかという目線に立って表現
– 他に依存せずにスケジュール可能な特徴を実現

Ron Jeffries の 3C / 3Cs（1/1）
 Card
– ストーリーはカードに書き、
見積もりやメモ等も一緒に書く
 Conversation
– ストーリーの背後にある詳細事項は
POとの会話から引き出される
 Confirmation
– 受け入れテストによってストーリーが
正しく実装されているか確認する

どちらの作り方を選びますか？（1/1）

分割の方向（1/1）
 技術的レイヤー単位で分割しない
– このやり方だと、全てが揃わないと
リリースできないリスクがある。
 動作する機能単位で分割する
– エンドツーエンドで動作する単位で分割する。
– リリース可能な単位が小さくなる
– 早くリリースできることは
ビジネス価値につながる

ユーザーストーリーのINVEST（1/1）
 INVESTとは
 Independent 独立
 Negotiable 交渉可能
 Valuable 価値
 Estimable 見積可能
 Sized right (Small ) 適切な大きさ
 Testable テスト可能

PBI優先順位決定の原則（1/1）
 高い価値のものから
 市場投入への時間を短く
 リスクを最小化
 将来の無駄を避ける
– PBI：Product Backlog Item

第2回各チーム振り返り結果
ご紹介
前回の振り返り結果をご紹介します
24

第2回各チーム振り返り結果ご紹介（1/2）
Aチーム（1/1）
 Keep
– ストーリーと時系列に並べて抜けた見えた
– ペルソナがあるとイメージしやすい
– システム化不要なモノが意外と多いことに気づいた
 problem
– 時間が足りない、ペルソナ読むヒマない
– 背景が複雑だった→ストーリーが発散した
– 独立しているストーリーにはなっていない
– 価値が高いストーリーから出すことができなかった
 Try
– 時間を増やす、ワークショップの時間を長く
– 開始時間に間に合うようにする、話を単純にする
– ストーリー出しはブレスト方式の方が良いかな・・
– 個人ワークの前にチームで話す時間が欲しい
– 自己紹介する時間を取る
Bチーム（1/1）
– ストーリーカードに書くと要件が小さくなって良
い
– 字はきれいに書きたい
– 書く項目が多くて時間がかかる
» 色を使い分けると良いのでは
» 色で区別出来る
» 記号を使う
– カードの重なり具合でチームの考え方の傾向がわ
かる
– ストーリーを逆からも考える
» 双方向からだと抜けが少なくなる
– 時間が区切られていないと考えが発散する
– 見通しをよくする工夫
– 概要のフローがあると良い
25

第2回各チーム振り返り結果ご紹介（2/2）
Cチーム（1/1）
– 最小限の機能
» 業務知識が高い
» 集約がうまかった
– 作り手が作りたくなるシンプルさ
– ストーリーが軽い
– モチベーションが下がらない
Dチーム（1/1）
– 利用者の中でも重要人物に絞ると軽量化できる
– 幹事側の方が多かった
– なぜか
» 「自分が幹事だったら」
という前提をおいてしまったから
» 「利用者目線」で書けていなかったかも
– ユーザーストーリー作成時
» 互いのズレがあった
» ワークショップを通して、認識のズレを
解消できたと思う（短い時間でも）
– 「利用者」1人1人にもっと注目していけば、
挙げられなかったストーリーが出てくると思う
26

ワークショップ#4
各チームごとに改めて自己紹介を行ってください
（チームワークショップ）
27

前回実施したワークショップ#1～#3の内容について、
各チームごとにフィードバックを実施してください
28

利害関係者に最初にデモンストレーションを実施するとしたら、
どのストーリーを実現するか？を各チームで考えてください
29

スプリントとリリースについて解説します
30

スプリントとリリース（1/2）
31
【参考：@kawaguti - 20110118 scrum 10 mins】
http://www.slideshare.net/kawaguti/20110118-scrum-10-mins

32

プランニングポーカーと見積もりについて説明します
33

プランニングポーカーと見積もり（1/3）
プランニングポーカー（1/2）
34
【参考：@ryuzee – Scrum概論】
http://www.slideshare.net/Ryuzee/scrum-8048905

プランニングポーカー（2/2）
 プランニングポーカーの進め方
1. 基準となるストーリーを決めます。
(早めに着手するであろう)基本的なストーリーで、全員が内容を
想像でき、規模の小さいものを選びます。
基準のストーリーのポイントを２とします。
2. 次のストーリーを選び、その規模を相対的に考え、カードで
一斉に示します。
3. 数が食い違っている場合は、一番大きい数を出した人、
一番小さい数を出した人に理由を言ってもらい、その情報を
共有します。2に戻ります。
4. 数が一致した場合はその数で確定です。
5. ２～３回行って僅差なら、大きい数字を採用します。
35

相対的な見積もり（1/1）
36
【参考：@ryuzee – Scrum概論】
http://www.slideshare.net/Ryuzee/scrum-8048905

プランニングポーカーを使って
各チームで見積を実施してください
37

今日気づいたことをテーブルごとに共有してください
各チームでの気づきを配布した用紙に記載してください
後ほど全チームの気づきをまとめたものをご連絡します
38

各チームの振り返り結果を共有しましょう
39

まとめ
今日お話したことを振り返ってみましょう
40

今日お話したこと（1/1）
第2回の復習
第2回各チーム振り返り結果ご紹介
41

ご静聴ありがとうございました。

『ユーザーストーリーマッピング ～後編～』第3回 POStudy 〜プロダクトオーナーシップ勉強会〜

More Related Content

What's hot

Similar to 『ユーザーストーリーマッピング ～後編～』第3回 POStudy 〜プロダクトオーナーシップ勉強会〜

More from 満徳 関