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

Copyright © 2011 @fullvirtue. All rights reserved.

第2回スクラムプロダクトオーナー勉強会～ユーザーストーリーマッピング～

2011年09月30日（金）

@fullvirtue

1

Copyright © 2011 @fullvirtue All rights reserved.

スクラムプロダクトオーナー勉強会の紹介（1/2）

スクラムプロダクトオーナー勉強会について（1/2）

勉強会の目的

「現場でスクラムを実践するためにはどうすればよいか」という命題に対して、「スクラムプロダクトオーナー」という切り口から改善策を自己発見していく

勉強会の進め方

過去の導入事例やワークショップなどを通じて「参加者同士で議論」を行い「情報交換」をすることで互いに有益な場を作っていく

勉強会の参加対象者

スクラムに興味はあるが、まだ中身をよく知らない方

スクラムをすでに実践している方

2


スクラムプロダクトオーナー勉強会の紹介（2/2）

スクラムプロダクトオーナー勉強会について（2/2）

勉強会の元ネタ

認定スクラムプロダクトオーナー研修（日本で2回目）

‒ Certified Scrum Product Owner Course（CSPO）

» 2011/07/28～2011/07/29 実施済

‒ http://scrumalliance.org/courses/20111911-certified-scrum-product-owner

スクラムギャザリング東京2011

‒ Scrum Gathering Tokyo 2011

» 2011/10/19（水）、2011/10/22（土）開催予定

‒ http://www.scrumgatheringtokyo.org/sgt2011/

3

http://scrumalliance.org/courses/20111911-certified-scrum-product-owner











http://www.scrumgatheringtokyo.org/sgt2011/




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

第1回目の復習

プロダクトバックログ解説

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

ワークショップ＃1




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

まとめ


おことわり（1/1）

今回の資料について

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

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

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

5

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





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

6


第1回目の復習（1/9）

アジャイルソフトウェア開発とは

「アジャイルソフトウェア開発宣言」の「4つの価値」と「12の原則」に基づいた開発

‒出典：Agile Manifesto

» http://agilemanifesto.org/

7

http://agilemanifesto.org/



アジャイルソフトウェア開発宣言–4つの価値（1/1）

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

8



アジャイルソフトウェア開発宣言–12の原則（1/3）

アジャイル宣言の背後にある原則

私たちは以下の原則に従う

1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

9






5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

7. 動くソフトウェアこそが進捗の最も重要な尺度です。

8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

10






9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

11



アジャイルの現在（1/1）

出典：平鍋健児氏 http://www.publickey1.jp/blog/10/post_121.html

12

http://www.publickey1.jp/blog/10/post_121.html

http://www.publickey1.jp/blog/10/post_121.html



スクラムにおける役割（1/1）

13

• プロダクトの機能と特徴を定義し、リリースの内容と日付を決める

• プロダクト収益性または投資収益率の責任者

• 機能の市場価値をもとに機能の順付けをする

• スプリントごとに仕様や優先順位を変える権利がある

• 作業結果を許可または却下する

プロダクトオーナー

• チームの機能と効率を支援または保証する

• 作業者の協力を支援し、それを妨害するものに対処する

• チームを外部妨害から守る

• プロセス通りの作業を保証し、デイリースクラム、スプリント末の

レビューとプラニングを設定する

スクラムマスター

• 多数目的に対応

• ３人から９人まで

• スプリントゴールを選択し、目標となる結果を定義する

• プロジェクト規則内であれば目標達成するには何してもよい

• 作業とチーム自身の整理と制御をする

• 作業を結果をプロダクトオーナーの為にでもする

チーム



スクラムの進め方（1/2）

» 出典：MOUNTAIN GOAT SOFTWARE ▹ http://www.mountaingoatsoftware.com/scrum/figures

14

PO SM

プロダクトオーナースクラムフィーチャーチーム

＋スクラムマスター

http://www.mountaingoatsoftware.com/scrum/figures



スクラムの進め方（2/2）

» 出典：MOUNTAIN GOAT SOFTWARE + Powerd by @nawoto @yattom

▹ http://www.mountaingoatsoftware.com/scrum/figures 15

PO SM

プロダクトオーナースクラムフィーチャーチーム

＋スクラムマスター

http://www.mountaingoatsoftware.com/scrum/figures



前回やったプロダクトバックログについて、

もう少し踏み込んで説明していきます

16

【参考：@kawaguti Scrum Boot Camp資料】


プロダクトバックログ解説（1/16）

プロダクトバックログ（1/2）

17

＃概要デモ方法優先 SP

21 管理者画面を利用出来るトップ画面から「管理者」ボタンで

画面に遷移 700 3

25 管理者として

ログインできるようになる

管理者権限を持つIDだけに「管理者」ボタンを表示するところを見せる

640 5

27 セッションは15分間維持

されるが、その後は破棄

操作終了後15分待ってから操作を行う（その間は、他のデモを見せる）

500 2

24 管理画面は50件ごとに

ページを分けて表示

管理画面を表示する。

次ページを選択して

最終ページまで見せる

490 2

29 タイトルを文字列検索で

探すことが出来る

トップ画面の検索窓に入力し、

検索結果画面へ。

～項目をクリックして

470 3



プロダクトバックログ（2/2）

18

＃概要デモ方法優先 SP

21 管理者画面を利用出来るトップ画面から「管理者」ボタンで

画面に遷移 700 3

25 管理者として

ログインできるようになる

管理者権限を持つIDだけに「管理者」ボタンを表示するところを見せる

640 5

27 セッションは15分間維持

されるが、その後は破棄

操作終了後15分待ってから操作を行う（その間は、他のデモを見せる）

500 2

24 管理画面は50件ごとに

ページを分けて表示

管理画面を表示する。

次ページを選択して

最終ページまで見せる

490 2

29 タイトルを文字列検索で

探すことが出来る

トップ画面の検索窓に入力し、

検索結果画面へ。

～項目をクリックして

470 3



スプリント計画（1/10）

スプリント計画第1部では、チームの到達範囲を予測

19

2

1

3

5

1





プロダクトバックログ

＝優先順位順に積まれた提供項目のリスト

20

2

1

3

5

1





21

2

1

3

5

1





ベロシティ＝６

22

2

1

3

5

1






23

2

1

3

5

1

2

1

3

当スプリントで着手






24

2

1

3

5

1





ベロシティ＝８

25

2

1

3

5

1





ベロシティ＝８

26

2

1

3

5

1

6





27

2

1

3

5

1

6

2

1

3

1

5

7





28

2

1

3

5

1

6

2

1

3

1

5

7

2

1

3

2

3

1

8



タスクボード（1/2）

29



タスクボード（2/2）

30

#172

リリース作業 3/22 18:00

#195

障害調査 IE6で表示が崩れる

#193

件名からの絞り込み表示ができる

1

2 3



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

31



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

32



ユーザーストーリーについて説明していきます

33

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






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

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

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

[役割]として

[結果]が欲しい

それは [理由]のためだ

[役割]として

[機能や性能]が欲しい

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

34



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

顧客との会話に役立つ

計画づくりに役立つ

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

35



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

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

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

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

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

36



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

Card

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

Conversation

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

Confirmation

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

37



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

38



分割の方向（1/1）

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

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

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

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

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

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

39



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

INVESTとは

Independent 独立

Negotiable 交渉可能

Valuable 価値

Estimable 見積可能

Sized right (Small ) 適切な大きさ

Testable テスト可能

40




Independent

互いに独立していること

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

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

41




Negotiable

交渉可能

会話のための道具

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

42




Valuable

価値がある

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

‒ビジネスにとって

‒チームにとって

43




Estimable

見積可能

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

44




Sized Right

適切な大きさ

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

45




Testable

テスト可能

受入テストを記述できる

46



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

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

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

47



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

高い価値のものから

市場投入への時間を短く

リスクを最小化

将来の無駄を避ける

‒ PBI：Product Backlog Item

48


ワークショップ#1

ワークショップの題材を確認した後、

ユーザーストーリーをストーリーカードに書き出して下さい

（個人ワークショップ）

49



個人で作成したストーリーカードを

チームで共有し、まとめて下さい

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

50



チームでまとめたストーリーカードを元に

最低限のリリース目標を設定して下さい

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

51


ワークショップ#4 ※今回時間切れだったので、次回続きをやります

52



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

各チームでの気づきを配布した用紙に記載して下さい

後ほど全チームの気づきをまとめたものをご連絡します

53


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

54


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

第1回目の復習








まとめ

Copyright © 2011 @fullvirtue All rights reserved. 56

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

Technology

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

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