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

 2012/05/13
このエントリーをはてなブックマークに追加

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

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

パーキンソンの法則とは、「ある資源に対する需要は、その資源が入手可能な量まで膨張する」という法則で、開発にあてはめれば、確保した時間は、それを使い潰すまでつ使ってしまう、ということになる。 この症状をストーリーポイントによって解消できるか、という質問に対しては、答えはNoだ。 それは以下の理由だ。
  • ストーリーポイントは単なるポイントであり、なんら具体的な単位ではない
  • 従って物理作業時間への変換は不可能だし、そもそも大まかにサイズを測る道具であるため、同一ポイントの場合に完全に同一時間になるとも限らない。
  • 物理的な時間については、スプリント計画会議の第二部でのタスク出しで行う。バッファが取られるとしたらこのタイミング
  • しかしタスクについてもチームの平均的な能力の人が行った場合にどれくらいかかるかという観点で見積もりをするので、過度にバッファを恣意的に載せるのは無理
  • そもそもタスクの見積もりは50:50であるべき。
  • バッファを積んでのんびりやっているのか、そうではないのかは朝会でわかる
  • チームがバッファを積みたがっているのにはもしかしたら、タスク漏れが常に発生しているか、プロダクトバックログ項目の受け入れ基準があいまいで、スプリント中に仕様の確認等に多くの時間が取られ、場合によっては仕様が膨れ上がるからだ。
  • そのように考えると、ストーリーポイントによって何ら抑止効果があるわけではなく、むしろバックログの粒度や会議体のやり方等に問題があるので、改善が必要になる。

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

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

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

ストーリーポイントを見積もる際の基準ストーリーの見積もりがそもそもあってなかったらどうするか?

僕が薦めているのは基準ストーリーを2つ用意して、それを2ポイントと5ポイントと設定し、その2点との比較を行う方法だ。 この基準ストーリーだが、以下の点に注意しなければならない。

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

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

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

初期開発をするのにバックログを作ったら膨大な量になって見積もれない、すごい勢いでバックログ項目が追加になる

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

POがうまくプロダクトバックログを作れない、POがつける優先順位が?

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

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

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

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

 2012/05/13
このエントリーをはてなブックマークに追加

サイト内検索


著作

寄稿

Latest post: