ブログ

ryuzeeによるブログ記事。不定期更新

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

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

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

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

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

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

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

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

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

例えば、過去3スプリントで完成したプロダクトバックログの合計ストーリーポイントの平均が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スプリントあたりのコストが明らかになるからだ。

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

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

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

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

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

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック