第4回スクラムプロダクトオーナー勉強会に参加してきた #postudy
(写真:ユーザーストーリーに対して見積もり作業(プランニングポーカー)を行っているところ。)
今回で第4回を数える『スクラムプロダクトオーナー勉強会』。今回は第2回や第3回での各種振り返り・感想等を踏まえつつの内容となりました。
テーマは『ユーザーストーリーと見積』について。概要文については以下引用をご参照下さい。
第4回は、「ユーザーストーリーと見積」について、 プロダクトオーナーの立場から実際にワークショップを通して経験し、 ディスカッションを通して理解を深めていきます。 第2回〜第3回でも「ユーザーストーリーマッピング」について それぞれ5分〜10分という短時間でワークショップをこなしてきましたが、 参加者の方々から ・「もっとそれぞれ時間をかけて行いたい」 ・「プロダクトオーナーの価値観をもっと共有したい」 ・「前回とは違ったメンバーともワークショップを行いたい」 ・「プロダクトオーナー経験者の生の声をもっと聞きたい」 ・「プランニングポーカーによる見積をもっとやりたい」 との要望を多く頂きました。 そこで第4回では、ユーザーストーリーと見積について、 第2回〜第3回よりさらに深掘りしていきます。 ------------------------------------ 「ユーザーストーリーマップ」とは、自分たちが構築している プロダクトに関する自分たちの理解を手助けしてくれる手法です。 まず、製品をイテレーティブ(反復的)かつインクリメンタル(漸進的)に開発できるように、 小さな部品に分割します。そうすることで、製品の出荷に必要な最小限の機能 (MVP: Minimal Viable Product)を効果的に計画することができます。 さらに、(アジャイルで重要な)機能のスライスについて、全体最適を目指すことができます。 このチュートリアルでは、参加者自身のストーリーマップを素早く協調的に作り、 それを通じて、ユーザーストーリーマップ作りの基本を学んでいきます。 ------------------------------------
第4回の作業スケジュールとしては以下の様な形に。ワークショップ#6までを約30分、ワークショップ#7のプランニングポーカーについては単独で大きく約30分という時間構成。
第3回の復習(プロダクトバックログ〜ユーザーストーリー) 第3回各チーム振り返り結果ご紹介 ワークショップ #1 各チームごとに改めて自己紹介(10分) ワークショップ #2 ユーザーストーリー書き出し(10分) ワークショップ #3 ユーザーストーリー整理(時系列に並べ替え) ワークショップ #4 (時間調整) ワークショップ #5 ストーリーの切れ目に概要タイトル付加 ワークショップ #6 初回リリース分の範囲選定 ワークショップ #7 プランニングポーカー(30分)
『ワークショップの回数多い!』と一瞬思いましたが、実際のところは作業(ワークショップ)毎に細かく区切った形と成っており、そのワークショップ単位でも幾らか(前回よりは)余裕を持たせた形と成っていたのでそこまで『時間が足りない』感はありませんでした。
また、今回はワークショップにより時間を割いた形になっており、そこまで講演のメモは無い感じかも。ワークショップの流れ、またそこで感じたことなどを書いていこうと思います。
当日のスライド
- スクラムプロダクトオーナー勉強会 第4回
- View more presentations from full virtue
はじめに
スクラムプロダクトオーナー勉強会の説明など、概要的な説明が幾つか。
今回第4回の勉強会は参加者総勢31名。(事前に関さんが調整して頂いたお陰で、前回より広いスペースでの開催が可能になりました。ありがとうございます!) あ、開催場所はこれまで同様のTIS株式会社様となっております。
ちなみに今回が初参加という方も総勢14名いらっしゃいました。参加定数も比較的早く埋まりつつあったようですし、いよいよ認知もされ始めて来たというところでしょうか。
関さんの方から今回の参加に関してのアンケート結果も発表。それによると、今回参加された方で資格取得者は3名/業務経験者は5名。少なさも気になったところではありますが、ここで何よりも驚きだったのが川口さんが資格を持っていない(ここでの文脈だと、対象は『プロダクトオーナー認定資格』?)という点、講習する側に居られたのに、まさか・・・という驚きが会場を包みました。(^_^;)
第3回の復習
基本、前回までのスライド資料(及び各所で公開されているスクラムマスターな方々のスライド資料)を参考に今回が初参加の方にざっくり説明する、という部分なのでここでは見出しキーワードのみでサクッと。
- ユーザーストーリーって何?
- 要求仕様を自然言語で簡潔に記述したもの。
- 裏には受入条件を記述
- 要求仕様を自然言語で簡潔に記述したもの。
- なぜユーザーストーリーが必要なのか
- 要件(機能)のスケジュールが可能なユニット
- スケジュールは他に依存していない
- 要件(機能)のスケジュールが可能なユニット
-
- ユーザーがどう使うかという目線に立って表現
- 他に依存せずにスケジュール可能な特徴を表現
- ユーザーがどう使うかという目線に立って表現
- 予備知識(3c)
- Card
- Conversation
- Confirmation
- スプリントとリリース
- 初回リリースと次回のリリースに回すモノを決める。
- 参考
- 20110118 scrum 10 mins
- View more presentations from kawaguti
- 20110118 scrum 10 mins
- プランニングポーカー
- 進め方の説明
- 相対的な見積もり
- ビルの画 by ryuzee氏
- ストーリー単位でいきなり見積もり
- 基準を決めよう。
- (後半30分見積もる)
- 5人1組、チームで相談して決めよう。
第3回各チーム振り返り結果ご紹介
前回第3回の振り返り内容をまとめたものを関さんが編集し、A3用紙に展開して紹介。チームでざっくり内容を閲覧・振り返りました。
※ちなみに今回の座席決めは前回懇親会同様、『プランニングポーカーを引き、 番号に該当する席に座ってチームを組む』と言う方式を採用。当然ながら前回とは異なります。 上記席決めと併せてプロダクトオーナー若しくはそれ相当の経験を持つ人がチームに1人加わる形が取られていたので、 作業は全般を通してスムーズに進みました。
ワークショップ #2 ユーザーストーリー書き出し(10分)
これまで使った『お題』を利用し、新しいチームで再度ユーザーストーリーを出す作業を行いました。
前回前々回で同じ題材を使いユーザーストーリー出しを行っていた方も自分含め何人か居ましたので、その時の内容を踏まえつつ今回は『役割で担当を決め、役割毎に想定しうるストーリーを出してみよう』という方式でストーリー出しを試して見る事に。
結果として、登場の人物の役割や順序(時系列)で偏りが出来ることなく、ほぼ万遍なくストーリー出しが出来ました♪ あとは時系列で片寄らない様にフローの最初から・最後から攻めるという方法もアリかな〜と思いましたが、今回の『役割』ではそこまで時間軸を意識することなく(一番多いストーリー出しに人数を割いていたのもあるので)行けていたような気がします。
ワークショップ #3 ユーザーストーリー整理(時系列に並べ替え)
洗い出した付箋紙(ユーザーストーリー)を時系列に並べ替え。上記写真のようにフローを参考にしつつ、整理完了。
ワークショップ #5 ストーリーの切れ目に概要タイトル付加
作業・ストーリーの切れ目をチームで共有し、概要タイトルを設ける作業。こちらの作業については、一番作業量が多いであろう役割をベースに考え、その役割ユーザーが一息付ける部分を見つけ出し(ここまで進まないと区切れない、ってポイントとも言えるか)、その単位でタイトル付けを行いました。
ワークショップ #6 初回リリース分の範囲選定
一本境界線を設け、『初回リリースに含めるもの』と『そうでないもの』に分ける作業。
チームとしては上記で設定した『概要』で分けるか?(縦に線を引く)という案も一瞬出ましたが、ここはやはり機能単位で『初回リリース』と『そうでないもの』に分けるべきだろう、と意見が一致。
振り落とす際には、『人力で何とかなるものは落とす』という基準でやってみようとしたのですが、それだと『全部人力で出来るじゃん…』となりボツに(笑) ここではひとまず『メンバーが遠隔地にいて直接会って連絡が取れない』前提で『システムとして無いと立ちゆかないもの』はどれか、位のイメージで振るい落としを決行。
白紙に引いた赤い線が『リリースの境界線』になります。線より上が『初回リリース対象』です。
※ちなみにここまで(ワークショップ#6まで)の作業で約30分。以外と短い時間でしたが、同じテーマでワークショップをやっている人も居たせいか時間の短さ程には切羽詰まった感は無かったような気がします。
ワークショップ #7 プランニングポーカー(30分)
ここからの30分は『プランニングポーカー』作業1本。じっくり作業に取り掛かれました。(前回のプランニングポーカーでは正味1つしか見積もりが出来なかったので…^^;)
まずは見積もりに対する基準となるストーリーについて1つ抽出し、基準ポイントを割り振り。システムの初期段階で構築するであろう基礎となる部分について議論を交わし、ひとまず『3』ポイントを設定。
その後、同じ括りで纏められているストーリーについても見積もりを実施して行ったのですが、そこで挙がった印象的なポイントが一つあったのでご紹介。
・ストーリーに『と』(=並列の接続詞?)が含まれていると、それは分割した方が良いのかも。 →一覧機能を見積もる際に、結果表示の形態としてWEB(画面で一覧)とCSV(ダウンロード)を含めた話し合いになり、ポイントが上手く見積もれなかった。 →ストーリーから『CSV』に関する部分を切り出し(&初回対象外に移動)、再度見積もることですんなり意見が一致。
『リストで確認』という段階では表示形式まで言及されていなかったため、話し合いでそこが焦点となり、より細かい単位に分割した事で見積もりが上手く行った。話し合いが無ければ無かった展開だったかも知れないですね。この辺りは印象に残ったし、勉強にもなりました。
『こういう兆候が出たら○○』みたいなのは他にもあるのかも?
また、ここ(見積もり作業前)まで比較的チームとしては順調に作業を進めていたのですが、ここで顕著化した問題が『Doneの定義が不十分だった事により、見積もり精度のブレが生じてしまった』という点でした。
Doneの定義については、ここ最近のスクラム・アジャイル関連のイベントや勉強会では耳にしない日は無いと言う程にメジャーなフレーズだったりすると思いますが(また、ストーリーの裏側に/併せて書くべきという指導・レクチャーも良く聞きますが)、今回のチーム作業では1人を除いて確か(付箋の裏)にDoneの定義を記載していなかったような気がします。
そんな状態でしたので見積もる際の意見交換で『あれ、これは○○という前提?』『あ〜、そうなるなら見積もりも変わるな〜…』と見積もりの過程で前提が微妙にブレ出し、当初見積もった『3』ポイントの基準も見直さなければならないか?という点も懸念せざるを得ない状況になりました。
今回はそこまでの時間が無かったのでざっくり対処しましたが、ここいらの点について、個人的には疑問というか気になる点が多かったので箇条書きでメモ。
- 単純にDoneの定義まで書く時間が無かった
- ストーリー洗い出しの時点でDoneの定義を書く時間を十分に取れていればある程度は見積もり精度も向上したのかな?
- そもそも、Doneの定義が『プランニングポーカーによる見積もり』でここまで重要な判断基準となる事があんま分かっていなかったかも。
- 実際にじっくり実践してみて、あ〜やっぱり必要なんだと実感。良い経験になった。
- じゃあDoneの定義について、深く考えてみよう...
- ストーリー単位で個々人で出してしまうと、Doneの定義を構成する各要素の粒度・精度もバラバラになってしまう?
- チームで一定の認識共有は必要なのは前提として、じゃあどうやって出す?誰が出す?チームメンバーも一緒に考える?
- Doneの定義の一覧はどこかにまとめる?どうやってまとめる?(今回ワークショップでは付箋の裏。実際の現場ではどう動く?)
今回第4回プロダクトオーナー勉強会に参加された方の中で、CSPO(認定スクラムプロダクトオーナー)を持っておられるうちの1人であるKIMURA Takao(TwitterID:@tw_takubon)さんからは、以下のように返信を頂けました。
実際の現場で行われている『Doneの定義』について、スクラムマスター・チームとしてはどういう対処をしているのか。
また、プロダクトオーナーの視点から見るとどういう過程でDoneの定義が構築されて行っているのか。
自分の中では一気に『Doneの定義』の深掘り欲がUPしてきた感じです。
懇親会
前回と同様、開催会場から程近い浜松町駅近辺の居酒屋で懇親会開始。この場もプランニングポーカーで席決め。参加人数は約20人程。本編参加人数(31人)からしても結構高い参加率だったような気がします。プロダクトオーナー勉強会は毎度懇親会参加者が多い印象ですね。
懇親会会場でも、私が着席した方の島では上記のように『Doneの定義』で迷った・悩んだという方が私以外にも居たようで、その辺はもうちょっと踏み込みたいね〜という話はしたかな。その他気になる点も皆さんお持ちだったようで、幹事として奔走されていたfullvirtue(TwitterID:@fullvirtue)さんも参加者の方々に今回の感想、次回への展望・要望などを聞かれていました。
聞くところによると当日資料作成にあたり、かなり頑張っておられていたようで…@fullvirtueさん、ありがとうございました!
また、今回参加された皆様、プロダクトオーナー実践者・経験者の皆様、ありがとうございました!ワークショップでは色々な気付き、発見がありました。また次回もよろしくお願いします。(次回予定:2011/11/11(金) 18:45〜20:30)