Scrum での「よくある勘違い」として、PBI（プロダクトバックログ / スプリントバックログ）をScrum チームのメンバーで分担してしまうというのがあります。
ウォーターフォールでの慣習・考え方では特に問題がないことのように思うかもしれませんが、Scrum ではこれはうまくいかないことが多いです。
開発者は（PBIではなく）タスクを分担する
以前の投稿で「To Do タスクを人に振らない（アサインしない）」というのを書きましたが、今回はタスクの親にあたる PBI についてです。
プロダクトバックログはこの開発で何を実現したいのか、何が欲しいのか？を、プロダクトオーナー（PO）が考えて決めたものです。Azure DevOps ではタスクの親にあたりますが、これは単純にタスクをグループ化しているだけのもの（いわゆる WBS : Work Breakdown Structure）ではなく、完成させればユーザーが利用できる最小単位を表しています。いわゆる受け入れ基準にあたる「どうなっていれば完成しているか？」まで明確にします。
そのプロダクトバックログを、Scrum チームがスプリント計画で「このスプリントで開発する」と決めたとき、プロダクトバックログはスプリントバックログになります。Azure DevOps では単に、そのスプリントでやると選択されるだけなので、スプリントバックログになってもアイテムの種類としては PBI のままですが・・・
そしてタスクは、その PBI を完成させるためにやらなければならないことを開発者が考えて計画し、実施する作業です。開発者はタスクを分担します。全員で分担してひとつの PBI を完成させます。
PBI を分担すると優先順に終わらせられない
プロダクトオーナー（PO）は、PBI をどの順番で完成させてほしいか？優先順位を決めています。これは（こうした方がいいという程度の提案ではなく）絶対です。ビジネス的な理由で変更することが出来ない優先順位があるはずです。開発者が「こっちから先に作った方が作りやすいから」という理由で順番を変えてよいものではありません。開発者は必ず、優先度１のPBIを完成させてから、次の優先度２の PBI に着手します。
もし、開発者が PBI を分担してしまうと、どのようなことが起こるでしょうか？
例えばこれから始まるスプリントで３つの PBI を完成させられると計画して、その PBI を３人で１つずつ分担したとします。しかし、実際には見積もり通りに作業が進まなくて遅れが出てしまいました。PBI を分担しているので当然、残っている Task を開発者が取り合って、優先度の高い PBI を先に終わらせるということもできません。スプリントの最後には、どの PBI もあと少しタスクが終わっていなくて、結局どの PBI も完成していない、このスプリントでは何も完成させられなかった、ということになってしまいます。これが Scrum の失敗パターンで一番よく見かける状態のように思います。
そうでなくても、最も優先順位の高い PBI が完成せず、優先度の低い PBI だけが完成している状態になってしまった場合にはどうでしょうか？開発者はプロダクトオーナー（PO）の希望を叶えられているでしょうか？
スプリントレビューで、ステークホルダーとして偉い人（部長様や役員など）を呼んでデモを行おうというときに、「これを見せます」と言って来てもらったのに、メインのそれができていなかったらどうなるのでしょうか？あるいは、ユーザーに「この機能を先行リリースします」と言っていたのにそれがリリースされずに、興味がない機能だけがリリースされたらユーザーはどう思うでしょうか？
プロダクトオーナー（PO）には優先順位の順に PBI を完成させなければならないビジネス的な理由があることを、もう一度思い出してください。
PBI をタスクと言わないで
Azure DevOps の初期設定では PBI に Unassigned と表示されるために、「あぁ、PBI に人をアサインするのね。PBI は Task をグループしたものなんだ。PBI はタスクとほぼ同じものなのね」と勘違いする人が多いのではないでしょうか。Scrum のトレーニングを実施していても、つい PBI のことを「タスク」と言ってしまう人が多いんですよね。PBI をタスクと呼んでいると、つい、PBI に人をアサインしたり、PBI を分担して並行して作業を実施したりしていしまいます。
こちらに、Azure DevOps の設定を変更して、PBI に Unassigned と表示されないようにする方法を紹介しています。ぜひ、この設定を変更して、PBI とタスクを間違えることがないようにしてください。
コメント
