この記事について
この記事は、aslead Agileの開発チーム「オキザリス」にて行っているアウトプット企画である「チーム「オキザリス」Advent Calendar」の10日目の記事です。
筆者の属性
2017年入社の社会人歴４年目の人間です。
2020年6月より業務にスクラムを取り込んで活動しています。
この記事の執筆時点でスクラム経験はちょうど６ヶ月です。
私のチームには１名アジャイルコーチがおり、週２日ほどの活動日にはいろいろとティーチング・コーチングいただきながら活動しています。
そのほか私が所属しているチームの詳細はオキザリスをご覧いただければと思います。
スクラムマスターを雇う時に聞いてみるとよい38個の質問
こちらのブログに記載されている、
「スクラムマスターを雇う時に聞いてみるとよい38個の質問」について、半年ほどスクラムを実践してきた身として、現在の理解度や自分の考えを整理する意味でこのタイミングで質問の回答を考えてみようと思った次第です。
質問数が多いため、このAdvent Calendarで予定している４回の記事投稿に分けて公開していきます。
本記事は第２回目の記事です。
＃第一回の記事はこちら
それではそれぞれ考えていきます
11: プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
まず気になった点として、プロダクトオーナーがステークホルダーの言いなりになっていないかという点です。
プロダクトオーナーはステークホルダーからのフィードバックは積極的にもらうものの、プロダクトバックログにはプロダクトオーナーとして咀嚼した内容を反映するのが大切かなと思いました。
おおまかな流れはこの通りかと思いますが、歯抜けだったりするのかなと思いました。
開発者との対話も含めて以下のような流れが良いかなと思います。
- バックログアイテムに積む
- 完成の定義を反映するなど、リファインメントする
- 開発者にバックログを説明する（QAをするなどして開発者の疑問解消をする）
- 見積もる
12: チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
この質問の状況がイマイチわかりませんでした。。。
プロダクトオーナーに競合プロダクトや、トレンドを聞く感じになるのでしょうか。
もしくは、利用者と最近どんな会話をしたか、と聞いてみるのも最新状況を知る手がかりになるかもしれません。
13: 誰がユーザーストーリーを書くとよいか？
ユーザーストーリーは実際のプロダクトの利用者に書いてもらうのがよいと思います。
もしプロダクトオーナー＝利用者、であればプロダクトオーナーが書くのもいいのかなと思います。
プロダクトオーナー≠利用者の場合、「利用者にこういうモノを提供すると嬉しいだろう」と、憶測の域を出ない考えのまま作り物を定義してしまうリスクがあると考えるからです。
利用者がユーザーストーリーの書き方に慣れていない場合は、サポートなども必要かもしれません。
14: よいユーザーストーリーとはどんなものか？どんな構造か？
「主語」「述語」「結果」「その結果が実現されるとどう嬉しいか。」があるといいかと思います。
（主語）が（述語）をすると（結果）になる。なぜならば（その結果が実現されるとどう嬉しいか）だからである。
より実現した状態が鮮明になり、かつなぜその価値が重要なのかということが開発者に伝わるようになると思います。
15: 「Readyの定義」には何が含まれているべきか？
「なに」がどんな「状態」になっているか、が含まれているべきだと思います。
たとえば
- 「〇〇の申請（なに）」が「XX部長の承認済みである」
といった感じです。
そうすれば、「今はReadyになっているか」どうかがわかると思います。
さらには、「状態」というのは誰が見てもyesかnoかわかるのが望ましいと思います。
16: ユーザーストーリーを時間で見積もらないのはなぜか？
人間の特性として、タスクの大きさを見積もる際に作業量で見積もるほうが感覚値と実績値のずれが小さくなる、ということがあったかと思います。
また、スクラムは経験主義に主眼をおいており、ベロシティに基づいて将来を予測する意味では、時間単位で見積もる必要がないのかと思います。
17: プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
新しく追加したいアイデアについては以下のような流れでまずはバックログに取り込むのがよいかと思います。
アイデアはすべてバックログで管理するために登録しておき、優先度高いタスクについてのみ詳細化を実施するのがよいでしょう。
優先度が低い／取り組むかわからないアイテムのリファインメントの時間をかけることは、コストがかかる一方で無駄になるリスクが高いと思います。
- 追加したいアイデアをバックログに積む
- 優先度順にPBLを並び替える
- 優先度が高く２スプリント先くらいまでで着手しそうなバックログアイテムについては、リファインメントと見積もりを実施する。
「200個のチケットに取り組めるかどうか」については、「取り組めるかもしれないし、取り組めないかもしれない」が回答になるかなと思います。
チームのベロシティや、いつまで活動できるか、途中で新たに優先度が高いアイテムが追加される、、、といった複合的な要因で変化するものだと考えているからです。
とはいえ、良し悪しは別として、一度すべてのアイテムを見積もってしまえば、あとは過去のベロシティから「どれくらいの期間があればすべてのアイテムに取り組める見込みである」「この期間では、どのアイテムまで取り組むことができる見込みである」といったことは言えるかと思います。
18: チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
すでにバックログに積まれている中の最も価値のあるストーリーに取り組めるようにうするのであれば、
スプリントゴールをしっかりと意識するするように意識付けすることが効果がありそうだと思います。
スプリントゴールが見定められていると、余計なタスクをスプリントバックログに積んでしまうことを防ぎ必要な情報にフォーカスできるようになると考えているからです。
また、スプリントゴールがしっかりと認識できていると、「今自分が取り組んでいるタスクはゴールにつながっているか」「今スプリントゴールにつながらない」ということを開発者がスプリント中に自問自答しながら自律した判断をすることもできるようになると思います。
19: ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？
「ユーザーストーリーが実現された場合に、利用者の生活がどのように変化するか。」が価値だと思います。
メトリクスとしては、利用者の生活の変化量が測れるものなのかなと思いました。
たとえば、業務効率化を目指した価値であれば、「XX業務の作業時間が〇〇分削減できる」などがわかりやすいメトリクスかと思いました。
定量的なメトリクスとなるとなかなか思い浮かびませんでした。。。
20: チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
プロダクトオーナーが最も価値のあるユーザーストーリーをバックログの一番上に持ってこれていることと、それがなぜ重要なのかということが開発者にも分かる状態になっていることが重要だと思いました。
そのため、
- プロダクトオーナーにバックログの優先順位付けの理由を聞いてみる
- 開発者にプロダクトバックログの優先順位が高い理由を説明してもらう
といった形で、チームメンバーがしっかりとユーザーストーリーの優先順位付けについて認識を共有できるように問いかけることが思い浮かびました。
まとめ
なかなかタフな質問が続きますね。。。
スクラムがどういう価値基準を大切にしているか、自分の経験からなにか引っ張ってこれるものがないか。などいろいろと頭を使わされます。
では、続編に乞うご期待！