プロダクトバックログにおけるよくある質問と答え

みなさんこんにちは。@ryuzeeです。

スクラム道FullBoostで出ていた質問と議論で若干うずうずするところがあったので、好き勝手に答えてみます。なお、回答はあくまでコーチとしての勝手な見解であり、全てのコンテキストに有効な絶対解では決してありません。そもそも自分達のおかれたコンテキストを踏まえた上で、どうやったらもっとうまくいくのかを考え続け改善していけばよいのです。

「パーキンソンの法則」を「ストーリーポイント」で防ぐ事はできるのか？

パーキンソンの法則とは、「ある資源に対する需要は、その資源が入手可能な量まで膨張する」という法則で、開発にあてはめれば、確保した時間は、それを使い潰すまでつ使ってしまう、ということになる。

この症状をストーリーポイントによって解消できるか、という質問に対しては、答えはNoだ。それは以下の理由だ。

ストーリーポイントは単なるポイントであり、なんら具体的な単位ではない
したがって物理作業時間への変換は不可能だし、そもそも大まかにサイズを測る道具であるため、同一ポイントの場合に完全に同一時間になるとも限らない
物理的な時間については、スプリントプランニングの第二部でのタスク出しで行う。バッファが取られるとしたらこのタイミング
しかしタスクについても開発チームの平均的な能力の人が行った場合にどれくらいかかるかという観点で見積りをするので、過度にバッファを恣意的に載せるのは無理
そもそもタスクの見積りは50:50であるべき
バッファを積んでのんびりやっているのか、そうではないのかはデイリースクラムでわかる
開発チームがバッファを積みたがっているのにはもしかしたら、タスク漏れが常に発生しているか、プロダクトバックログアイテムの受け入れ基準があいまいで、スプリント中に仕様の確認等に多くの時間が取られ、場合によっては仕様が膨れ上がるからだ
そのように考えると、ストーリーポイントによって何ら抑止効果があるわけではなく、むしろプロダクトバックログアイテムの粒度や会議体のやり方等に問題があるので、改善が必要になる

ベロシティは重要か？ベロシティによって自分たちの成長を測定するか？

ベロシティは「過去の天気」。この先の天気がどうなるかの予測に使う。

例えば、過去3スプリントで完成したプロダクトバックログの合計ストーリーポイントの平均が10であれば、次も10くらいだな、と予測できるし、残り80ストーリーポイントなので、8スプリントくらいで全部完成するな、とか、あと4スプリントしかできないので、合計ポイントが40を超えた先のストーリーは実装できないなとか。また、見積りの際に、例えば、8ポイントと13ポイントの間くらいかなと思ったら13ポイントにしたり、隣接するポイントに収束した場合には上の数字に寄せるといったことをしているので、ストーリーポイントの合算値は須らく誤差を含むものになっている。それを細かく比較したところであまり正確な比較はできないだろう。さらには、成長していることをベロシティの数値で示すような圧力がかかった場合は、スプリントプランニングでの見積りの際に、意図していなくても必ず開発チームのメンバーは数字を上積みしてくる。そんなことにはなんの意味もない。

ストーリーポイントを見積もる際の基準のプロダクトバックログアイテム（ストーリー）の見積りがそもそもあってなかったらどうするか？

僕が薦めているのは基準となるプロダクトバックログアイテムを2つ用意して、それを2ポイントと5ポイントと設定し、その2点との比較を行う方法だ。この基準プロダクトバックログアイテムだが、以下の点に注意しなければならない。

基準のプロダクトバックログアイテムに何を選択するのかも開発チームで合意すること
基準のプロダクトバックログアイテム自体の受け入れ基準や作業内容がある程度明確であること（Readyなプロダクトバックログアイテムから選ぶ。また画面数が多い、多くの部分と結合する、といったものは避ける）。すなわち人によってボリュームが著しく乖離しうるものは選択しないこと
基準のプロダクトバックログアイテムは優先順位が高い項目から抽出すること。これは上の項目の言い換えでもある。なぜならプロダクトバックログは一般的に優先順位の高いものは細かい粒度で、そうでないものは細かくし過ぎないようにした方がよいからだ。最初から全部のプロダクトバックログアイテムを細かくしすぎるのは、YAGNIの原則に反しているし、そもそも順位が低いものは実装されない可能性もあってムダである
それでも基準が不適切になる可能性は０ではない。その場合でも、初期のスプリントであれば基準を分かりやすいものに変えても良い
そもそもストーリーポイントがフィボナッチ数列になっているのは、サイズが増えれば増えるほど１ポイントの差に意味がなくなってくるためであって、逆に言えば、基準のプロダクトバックログアイテムを適性な物に選び直したとしても全体に対しても影響は大きくならない

プロダクトバックログ作成時に技術的な検証や挑戦的な項目をどう扱うか？

技術的な検証については、スパイクといってタイムボックスを決めて、その時間内で検証を行うようにする。挑戦的な項目についても同様である。これらの項目が、プロダクトにおいて重要な意味を持つ、例えばこれができなければ製品を作る意味がない、といった場合は、プロジェクトにおけるリスク項目であり、優先順位を高くして解決しなければならないため、スプリント0や最初の方のスプリントで実施をする。さらにそのようなものが複数ある場合は、優先順位をつける必要がある。なお、早い段階でできないことが判明してプロジェクトが中止になったとしても、それはそれで良い結果だ。なぜならずっとムダな時間と期間とコストをかけ続けることにはならなかったのだから。

初期開発をするのにプロダクトバックログを作ったら膨大な量になって見積もれない、すごい勢いでプロダクトバックログアイテムが追加になる

スクラムチームで扱えるプロダクトバックログの量には限界がある。特に成熟度が高くないうちは大変だ。一般的にはプロダクトバックログアイテムは50〜100個以内に抑えることが望ましい。さらには、プロダクトバックログアイテムは優先順位が高いほど粒度を細かく、優先順位が低いものは粗くという形にして、必要なタイミングで詳細化しながら分割していく。初期の見積りが予算確保のために必要なのであれば、例えば、1,2,3,5,8,13…のカードで見積もるのではなく、S,M,LのようにTシャツサイズで見積もってもよい。それであれば素早く見積りが終わるはずだ。さらに言えば、この見積りは当たる保証はないので、この見積りによって予算を確保したところで、その予算内でプロダクトバックログアイテムの全てができ上がる保証などない。あくまで取った予算の範囲内で上から順番につくるか、フィーチャー固定であるならば、プロジェクトバーンダウンの状況を見ながら予算追加が必要なら行うか、のどちらかだ。そして見積りがどの程度正確なのかは、実際に1,2スプリント実施すれば感覚としてつかめる。これはベロシティが明らかになり、１スプリントあたりのコストが明らかになるからだ。

プロダクトオーナーがうまくプロダクトバックログを作れない、プロダクトオーナーがつける優先順位が意味不明

最初からうまく作れる人はなかなかいない（先日コーチングしたあるスクラムチームのプロダクトオーナーは最初からお手本のようなプロダクトバックログを書いたが、相当稀な例だ）したがって、スクラムマスターや開発チームが協力をする、というのは必要になってくる。ただし、あくまで協力であって、開発チームがかわりに書く、というのは正直なところやめておいた方が良いだろう。まず、うまく書けるようになるためにはたくさん書いて慣れなければならない。最初うまくいかなくても徐々にうまくなってくるものである。釣った魚を与えるのではなく、魚の釣り方を教えるべき、というのはプロダクトオーナーに対しても同じと考えてよい。さらに、プロダクトバックログアイテムはビジネスと密接に関わっているため、開発チームがかわりに書くのが辛い場合もある。また、プロダクトバックログアイテムの通りに作ってスプリントレビューを行った際に、代理で作ってしまうと、「なんとなく違う」「いい忘れた」「そんなの当たり前だと思ってた」のようなことが大量に発生してしまい、ムダが大きくなる可能性がある。そもそも製品の責任者、その製品をつかったビジネスにおける結果責任はプロダクトオーナーが担うため、実行可能な仕様を開発チームに伝えるのは、プロダクトオーナーの責務である。

プロダクトオーナーが提示した優先順位が？？？なケースも時にはあり得るが、プロダクトオーナーはプロダクトオーナーの観点で順位付けを行なっているので、開発者の思う順位と相違することはそれほどオカシイことではない。むしろ開発チームが順番に対して口を出す場合に、作りやすさとか、同時に作った方が速くできるとか、実装の観点から言い出している場合も多い。開発チームがプロダクトオーナーに対して思っていることを伝えるのはもちろん重要であり、順位が？であることや開発チームとしての提案を行うことも良いことだ。ただし最終決定権はプロダクトオーナーにあることだけは忘れてはならない。

プロダクトバックログにスクラムチーム用と顧客用のものがあっても良いのか？

プロダクトバックログは、プロダクトオーナー、開発チームのもの。したがって、そもそも顧客用のプロダクトバックログというものは存在しえない。ただステークホルダーには説明が必要、ということであれば、必要なドキュメントは作れば良い。ただし本当に必要なのかは良く確認すること。単に進捗を伝えたい、作っているものの内容を伝えたい、ということであれば、スプリントレビューに参加してもらえば良いだけである。

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料）