postudy day 2012 in okinawa - ユーザーストーリーマッピング

POStudy Day 2013 Spring in Tokyo

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

2012年12月01日（土）POStudy

@fullvirtue

Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.

POStudy Day

in Okinawa


今日のアジェンダ（1/1）

第2回,第3回,第4回各チーム振り返り結果ご紹介

ユーザーストーリーマッピング解説

ワークショップ #1







振り返り＆ディスカッション

まとめ 2

おことわり（1/1）

今回の資料について（1/1）

今回の資料は、以下の資料を参考にしています。私自身のオリジナルはほとんどありませんので、ご了承ください。

前半のプロダクトバックログの説明部分と後半のワークショップは、@kawaguti さんがScrum Boot Campで使用した資料を参考にさせて頂いています。

前半のユーザーストーリーの説明部分については、 @ryuzee さんの公開資料を参考にさせて頂いています。 http://www.slideshare.net/Ryuzee/ss-8332120

ワークショップの内容は、Jeff PattonさんがScrum Gathering Tokyo 2011 Day2で実施したワークショップを参考にさせて頂いています。

Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 3

http://www.slideshare.net/Ryuzee/ss-8332120




第2回各チーム振り返り結果ご紹介

前回の振り返り結果をご紹介します

4

第2回各チーム振り返り結果ご紹介（1/2）

Aチーム（1/1） Keep

– ストーリーと時系列に並べて抜けた見えた

– ペルソナがあるとイメージしやすい

– システム化不要なモノが意外と多いことに気づいた

problem

– 時間が足りない、ペルソナ読むヒマない

– 背景が複雑だった→ストーリーが発散した

– 独立しているストーリーにはなっていない

– 価値が高いストーリーから出すことができなかった

Try

– 時間を増やす、ワークショップの時間を長く

– 開始時間に間に合うようにする、話を単純にする

– ストーリー出しはブレスト方式の方が良いかな・・

– 個人ワークの前にチームで話す時間が欲しい

– 自己紹介する時間を取る

Bチーム（1/1） – ストーリーカードに書くと要件が小さくなって良

い

– 字はきれいに書きたい

– 書く項目が多くて時間がかかる

» 色を使い分けると良いのでは

» 色で区別出来る

» 記号を使う

– カードの重なり具合でチームの考え方の傾向がわかる

– ストーリーを逆からも考える

» 双方向からだと抜けが少なくなる

– 時間が区切られていないと考えが発散する

– 見通しをよくする工夫

– 概要のフローがあると良い

5


Cチーム（1/1） – 最小限の機能

» 業務知識が高い

» 集約がうまかった

– 作り手が作りたくなるシンプルさ

– ストーリーが軽い

– モチベーションが下がらない

Dチーム（1/1） – 利用者の中でも重要人物に絞ると軽量化できる

– 幹事側の方が多かった

– なぜか

» 「自分が幹事だったら」という前提をおいてしまったから

» 「利用者目線」で書けていなかったかも

– ユーザーストーリー作成時

» 互いのズレがあった

» ワークショップを通して、認識のズレを解消できたと思う（短い時間でも）

– 「利用者」1人1人にもっと注目していけば、挙げられなかったストーリーが出てくると思う

6



7



– 自己紹介の時間は有意義だった

– ワークショップは面白い

– プランニングポーカーの意識合わせは面白い

– 振り返りのKPTのフレームは、次に使えそう

– プランニングポーカーは認識のズレをあぶり出すには手軽で良い

problem

– 時間が足りない、

– プランニングポーカーの見積は、スキルによる差の考慮が必要そう

Try

– 終了時間を遅らせる

– プランニングポーカーに適切なストーリーの粒度を見極めたい

Bチーム（1/2） Keep

– 各ワークショップで、個々のやり方の話ができた

– プランニングポーカーが面白かった

– 相対見積Good！

– チームの意志が合ってきた

problem

– 部屋が暑い

– デモストーリーの作成の時間がもっと欲しい

– デモの案を出すとき、拡散しすぎて終わらなかった

– チームの意識合わせに時間を取られた

– ワークショップの時間はもう少し欲しい

8


Bチーム（2/2） Try

– 1人1人が話せる場が欲しい

– 1日当たりの勉強会のスケジュールをもっとゆるやかにしても良いのでは？

– もっとプランニングポーカーがしたい！

– 基準を変えたプランニングポーカーをやってみたい。

– デモを行うという前提に立った作業を意識しながら

– 重要とするアクターを決めないといけない

– 誰に対して「価値」を与えるか

– スプリントバックログまで落とし込んでみたい

Cチーム（1/1） Keep

» 初参加者へのフォローがあり、初参加者が増えてよかった

» メインの機能（ユーザーストーリー）を5で見積もったことで、見積が簡単にできた

» 見積もりできてチーム内の合意が取れたこと

» 見直しによるシステムの効率化が出来て、開発規模がスリム化したこと

problem

» 見積の時間が断然足りなすぎ、、、ですw

» 優先順位を付けるワークショップがなかった

Try

» ワークショップのタイムボックスを増やして貰えるように働きかけてみたい

» 振り返りの時間は初参加者としてはありがたいが、時間が足りなくなるので事前に各自自習を義務づける

9


Dチーム（1/2）気づき

» ユーザーストーリーは、タスクレベルで書いてしまうのを避けるべき

» プランニングポーカーの「0」の意味 = ToDo やらないといけないけど、すぐおわるただし、めったにない

» 何かやることがあるならば、プランニングポーカーでは「1」とすべき

» プランニングポーカーでは、だいたい「13」が最大のボリューム

» プランニングポーカーで「13」を超える場合、ユーザーストーリーの分解を検討する

Dチーム（2/2）気づき

» プランニングポーカーのワークショップは、時間が足りなかった

» アジャイルを初めて実践する際、最初は時間が掛かることを身をもって実感できた

» 時間の意識を持って、今後は取り組みたい

» ユーザーストーリーを見積出来るレベルまで詳細化する必要があると思った

» プロダクトオーナーとして、ストーリーを立てて提示することを覚えると、プランニングポーカーの精度が高くなるまた、ストーリーの粒度も適切に分解出来ると思った

» ユーザーストーリーを見直すと、頂いたサンプルの形式で書くことは重要

» ユーザーストーリーは、交渉の余地がある書き方にする必要がある

10



11



– 最低限の機能に絞る

– ファーストリリースを検討する際に、足りないユーザーストーリーをアジャイルに追加したのが良かった

– ユーザーストーリーマッピングに触れてよかった

– ワークショップ参加は楽しい

– 笑って楽しかった

– いろいろな意見に触れられて勉強になった

– 多様な意見

– 新しい人とご挨拶

12


Aチーム（2/2） problem

– 立ち位置が混乱した

– セカンドストーリーが決まらなかった

– 見積もれなかった

– 価値の話が出てくるとわかりにくい

– 話さないと皆が何を思っているのかがわからない →前提を合わせていないから？

– 認識合わせに時間がかかった

– 言葉の認識の違いがあったなぁ

– 思ったほどスピードが出ない

– 細かい仕様に話が行ってしまう

Try

– ペルソナは初めての人も読む

– 優先順位を話し合って情報共有したい

– さらにチーム内のコミュニケーションアップを図って、効率よくストーリー作業する♪

– 笑いまくる

– 運用でカバー

– 誰をターゲットにして価値を出すか決めてからストーリーの優先順位を決めたい

– リリースの線を引きたい

– 価値の認識を合わせることを先に行う

– 価値・優先度を考える意識をする

13


Bチーム（1/1） Keep

– ストーリーのそぎ落とし

– 役割を分担してストーリーを作ったのが成功した

– 納得いくまで話した（ポーカー）

– 使うカードを絞ったのが良かった（ポーカー）

– 楽しかった

problem

– doneを書く時間がなかった

– ポーカーの軸ストーリーが後半ゆらいだ

Try

– doneをきちんと裏に書こう

– 話し合うこと

– ふりかえること

– ポーカーの基本ストーリーは小さいストーリーでやってみる

14


Cチーム（1/2） Keep

– アーキテクチャまで掘り下げて議論したので、見積が揃いやすかった

– 各テーブルに経験者とはじめての方がいて、スムーズでした

– スクラム経験者をまんべんなく入れるのは良いと思いました

– スクラムの進め方がどういうものかよく分かった

– ポーカーを始めての人に説明することで、自分も再認識

– システム化範囲を考えて、最優先事項を導き出した

– 画面イメージがあると話しやすい

15


Cチーム（2/2） problem

– 作らねばならないもののレギュレーションについては、もう少し細かく説明した方がよいと思う

– 青でまとめたものをアクティビティと呼んでしまってもよかったのでは？

– フローをみて書いたのでまとまった

– 知識が足りない

– 実際のユーザーがいないので、不明点が仮説の積み重ねになってしまう

– 行動の洗い出しとソフトウェアでサポートするものをどう議論するか

Try

– 時間があれば予定をきめるところから

– ユーザーの規模とか決定をもっと明確にしてあたれば良いモノを考えられたかな

– プラグマティックペルソナを作る系のワークもやりたい

16


Dチーム（1/2） Keep

– 前回よりストーリーの深掘りが出来てよかった

– 人間系と機械系の切り分けがはっきりしていた「人がやればいいでしょ」

– 各ストーリーのストーリーポイントが収束している

– 早く完成させることの目的を共有出来た

– 小さい単位にストーリーを落とすことが出来た

– 自己紹介の2週目は良かった

problem

– プロダクトオーナーなのにタスク（作業）レベルの見積になってしまった

– ストーリーが小さすぎた

– 技術面を洗い出しすぎる

– フローをちゃんと理解してなかった

– 勝手な要求をしてしまった

– 受入条件がきちんと書けなかった

– 見積の基準数字が小さいので場合によってはブレが大きくなるかも

– どれくらい価値があるかもっと議論してもよかった機がする

– 有効性をアピールする機能についてフォーカスをしてもよかった

– 基準としたポイントが小さすぎて 1～3にすべておさまってしまった

17


Dチーム（2/2） problem

– 見積時、幹事観点ばかりで出資者、参加者の観点がなかった

– タイムボックスを意識してなかったので、見積が終わらなかった

Try

– タイムボックスを意識して、各ワークショップを確実に完了させる

– プロダクトの題材を商用レベルのものにする

– フローとペルソナの読み合わせをしたい

– 受入条件を書く時間を取る

– 中くらいのストーリーを５ストーリーポイントくらいで基準にすべき

– どう展開出来るか考える

– 参加者がすごく多い場合のユーザーストーリーの見積をしたい

– 対象とするストーリーを絞ってでも完了基準を書くべき

18


Eチーム（1/1） Keep

– この場に来たことそのもの

– 以前やったときの復習になった

– ユーザーストーリーに対する認識を合わせることに気づいたこと

– 時間配分（チーム内）が良かった →余裕あった

– コンパクトなリリースに向けての方向性が合ってたこと

problem

– ユーザーストーリーの認識が合ってなかったこと →どうやって合わせる？

– 受入条件を見てなかった

– 受入条件を短い時間で書くのが難しい

– 利用者の行動順に考えていたので後ろの方のユーザーストーリーが充実しなかった

Try

– 実際の仕事で使いたい →ヒアリングの時 →ブレストの一環として

– 継続的に復習していきたい

– 自社で勉強会！ →POもメンバーも

– ストーリー出しの2週目（イテレーション）の後にやってみる

– 受入条件をきちんと書く

– ペルソナをおいてみる →よりユーザーストーリーマッピングらしく

疑問

– 実際のお客様とどうやってこの手法を使うか

– ユーザーストーリーマッピングの前後左右の知識がないので、応用方法がわからない

19


Fチーム（1/2） Keep

– 見積でいろいろな話を聞けた

– 見積の細かい擦り合わせ

– リリース物件のイメージができた

– ストーリーに分解する前に全体感を共有できて話がスムーズだった

– スコープを決めるのが早くできた

– プロダクトへの要求をシンプルにまとめることができた

– ワークショップの時間が長くなった

– ストーリーポイントを相対的に出すことで、一つ一つの大きさが把握出来てよかった

– ストーリー作成に参加出来た

20


Fチーム（2/2） problem

– 最後まで見積もれなかった

– 確認方法が書けなかった

– 机の線の使い方、付箋のまとめ方は、先に共有したかった

Try

– 時間足りなかった

– 時間配分間違えた

– ストップウォッチを活用する

– （チーム内で）時間を先にアナウンスする →タイムボックスを意識する

– タイムキーパーを決める

– 時計をテーブルに置く

– タイムキープできるようにマイルストンを設定する（ex ～分までに決める）

Try

– プロダクトの機能を固めるまえに見積を始めてしまった

– ストーリーの内容をすりあわせたかった

– 見積前に前提条件を共有する

– 見積前にストーリーのDoneの定義を裏書きする

– 最初にプロダクトの共有を詳しくやっておくべき

– PJの前提の共有をする →どんなプロダクト？

21

ユーザーストーリーマッピング解説ユーザーストーリーについて説明していきます


【参考：@ryuzee ユーザーストーリーとは？】 http://www.slideshare.net/Ryuzee/ss-8332120





ユーザーストーリーマッピング解説（1/15）

ユーザーストーリーとは（1/2）

要求仕様を自然言語で簡潔に記述したもの

[役割]として

[結果]が欲しい

それは [理由]のためだ

[役割]として

[機能や性能]が欲しい

それは [ビジネス価値]のためだ



ユーザーストーリーとは（2/2）

顧客との会話に役立つ

計画づくりに役立つ

無駄な詳細化から解放される



なぜユーザーストーリーが必要なのか（1/1）

要件（機能）のスケジュールが可能なユニット

– スケジュールは他に依存していない

ユーザーがどう使うかという目線に立って表現

– 他に依存せずにスケジュール可能な特徴を実現



Ron Jeffries の 3C / 3Cs（1/1）

Card

– ストーリーはカードに書き、見積もりやメモ等も一緒に書く

Conversation

– ストーリーの背後にある詳細事項は POとの会話から引き出される

Confirmation

– 受け入れテストによってストーリーが正しく実装されているか確認する



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



分割の方向（1/1）

技術的レイヤー単位で分割しない

– このやり方だと、全てが揃わないとリリースできないリスクがある。

動作する機能単位で分割する

– エンドツーエンドで動作する単位で分割する。

– リリース可能な単位が小さくなる

– 早くリリースできることはビジネス価値につながる



ユーザーストーリーのINVEST（1/7）

INVESTとは

Independent 独立

Negotiable 交渉可能

Valuable 価値

Estimable 見積可能

Sized right (Small ) 適切な大きさ

Testable テスト可能




Independent

互いに独立していること

依存関係や前後関係はなるべく排除

依存関係が高いと見積が難しくなる




Negotiable

交渉可能

会話のための道具

一度決めたことが絶対なわけではない




Valuable

価値がある

– ステークホルダーにとって

– ビジネスにとって

– チームにとって




Estimable

見積可能

見積できるくらいのストーリー粒度




Sized Right

適切な大きさ

十分にストーリーが分割されている




Testable

テスト可能

受入テストを記述できる



ユーザーストーリー作成時の大切なこと（1/1）

システムの利用者に焦点をあてる

ストーリーの記述では、ユーザーロールを意識する



PBI優先順位決定の原則（1/1）

高い価値のものから

市場投入への時間を短く

リスクを最小化

将来の無駄を避ける

– PBI：Product Backlog Item


ワークショップ#1

各チームごとに改めて自己紹介を行ってください

（チームワークショップ）

38

今日の進め方

今日は第2回・第3回で実施したワークショップ#1～#6の

ユーザーストーリーの作成を、 30分間で実施していきます

次に残り30分を使って、プランニングポーカーを使いながら、

ユーザーストーリーの見積をしていきます

39


題材を元に、10分間で黄色い付箋紙にユーザーストーリーを書き出していってください

裏には受入条件を記載してください

（個人ワークショップ）

40


チーム単位で、5分間で左から右へ時系列に並べてください（チームワークショップ）

41


チーム単位で、5分間で似たタスクをまとめてください

今までのワークショップで遅れを取っている場合は、

この5分間で遅れを取り戻してください（チームワークショップ）

42


チーム単位で、5分間でやっていることが変わっているところの上部に、青い付箋紙を貼ってください

青い付箋紙には、そのまとまりの概要を書いてください（チームワークショップ）

43


44


45


机の真ん中を境界線とします。チーム単位で5分間で最初のリリース対象にするものを境界線の上部に、次回以降のリリース対象にするものを境界線の下部にそれぞれ付箋紙を移動してください（チームワークショップ）

46


47


48

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

49

スプリントとリリース（1/2）


50

【参考：@kawaguti - 20110118 scrum 10 mins】 http://www.slideshare.net/kawaguti/20110118-scrum-10-mins

http://www.slideshare.net/kawaguti/20110118-scrum-10-mins










51










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

52

プランニングポーカーと見積もり（1/3）

プランニングポーカー（1/2）

53

【参考：@ryuzee – Scrum概論】 http://www.slideshare.net/Ryuzee/scrum-8048905

http://www.slideshare.net/Ryuzee/scrum-8048905





プランニングポーカー（2/2）

プランニングポーカーの進め方

1. 基準となるストーリーを決めます。 (早めに着手するであろう)基本的なストーリーで、全員が内容を想像でき、規模の小さいものを選びます。基準のストーリーのポイントを２とします。

2. 次のストーリーを選び、その規模を相対的に考え、カードで一斉に示します。

3. 数が食い違っている場合は、一番大きい数を出した人、一番小さい数を出した人に理由を言ってもらい、その情報を共有します。2に戻ります。

4. 数が一致した場合はその数で確定です。

5. ２～３回行って僅差なら、大きい数字を採用します。

54











相対的な見積もり（1/1）

55

【参考：@ryuzee – Scrum概論】 http://www.slideshare.net/Ryuzee/scrum-8048905






各チーム毎に、30分間でユーザーストーリーを見積してください

見積する際に、ストーリーポイントの基準をチーム内で決定し、その基準を元にプランニングポーカーを使って見積を実施してください

（チームワークショップ）

56


今日気づいたことをテーブルごとに共有してください

各チームでの振り返り結果を、配布したA3用紙に記載してください

次回、全チームの振り返り結果をまとめたものをご連絡します

57

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

58


今日お話したこと（1/1）

第3回の復習










まとめ 59


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

postudy day 2012 in okinawa - ユーザーストーリーマッピング

Technology