スプリントバックログのタスクはどのように分解するとよいか？

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

スクラムチームのなかで分業と平行作業が多くなっているのを見かけることがあります。この理由の1つは、スプリントバックログの一環として作られたタスクの分解の仕方にあります。今日はこれについて見ていきたいと思います。

スプリントバックログとは？

まずは復習です。ご存じのとおり、スプリントプランニングでは、そのスプリントで達成したいスプリントゴールを検討し、スプリントゴールの達成に必要なプロダクトバックログアイテムを選択し、インクリメントを届けるための実行計画を作成します。これら3つを合わせたものをスプリントバックログと呼びます。

スプリントバックログは、開発者による開発者のためのもので、必要に応じてリアルタイムで更新していきます。毎日のデイリースクラムで進捗を検査できる程度の粒度である必要があります。

スプリントプランニングではタスクの分解が必要なのか？

スプリントプランニングでは必ず詳細なタスク分解が必要だと思っている人も多いですが、実はそんなことはありません。必要なのは、毎日検査可能な実行計画です。その形を満たしていれば、全てを詳細なタスクに分解する必要もありません。何十個かに分解したタスクをRedmineやJiraに入れなければいけないわけでもありません。ホワイトボードに箇条書きし実行計画の概要を踏まえて、日々スクラムチームで会話しながら作業を進めていくのでも構いません。スクラムチームにはスクラムチームごとにやりやすいやり方があるので、自分たちにとって過不足のないやり方を模索していくのがよいでしょう。

とは言え、タスク分解がよく使われているので、どのように分解すると良いか見ていきましょう。

あまり良くないタスク分解

まずはあまり良くないタスク分解を見てみましょう。対象とするプロダクトバックログアイテムは、例として「新しい注文を登録したい（Web画面から入力された情報をRDBに登録）」とします。

データベースのスキーマを設計する
API設計をする
画面デザインをする
画面を実装する
APIを実装する
結合する
テストする

どういう点で課題があるかを順番に見ていきましょう。

まず最大の問題は、タスクが開発者の行動の観点で記述されている点です。この書き方だと、タスクが完了したときにインクリメントがどういう状態になっているのかが分かりません。また作業内容自体も認識が揃っていない可能性があります（なお、この問題だけであればタスク分解の際に認識を揃えるためにさらに詳細な議論をしたり、完了条件を列挙したりすることでカバーできる可能性はもちろんあります）。

次の問題は、技術コンポーネントベースでの分解になっている点です。このように分解してしまうと、それぞれが繋がって動作する状態になるタイミングが遅くなります。この例だと、プロダクトバックログアイテムが完成しそうだと確証を持てるタイミングは「結合する」のタスクが終わったあたりになります。設計段階やコンポーネントの実装段階では自信が持てません。またコンポーネント単位で全部入りを作るため、それぞれの作業に時間がかかります。スプリントの後半に向かってリスクが大きくなるのはあまり良い作戦ではありません

じゃあどう分解するのが良いか？

ここまでの内容を踏まえてどうしたら良いでしょうか？もうお分かりだと思いますが、タスクが完了したときの状態と明らかにしつつ、早めに結合しリスクを減らす作戦で行きます。たとえば、前述のプロダクトバックログアイテムであれば、以下のようにタスクに分解します。

RDBに注文情報を登録できるようにする（SQLで）
画面から注文情報を登録できるようにする（注文内容は固定値）
最小限の受入テストを書く（これ以降は実装ごとに更新）
品目を選べるようにする（品目マスターを参照する）
数量を選べるようにする
色を選べるようにする
合計金額を計算できるようにする
注文者からのメッセージを入力できるようにする

このタスクであれば、何ができればそのタスクが完了なのかが明瞭になります。その上で、最初の2つが終われば結合リスクはだいぶ低くなっており、自信を持ってその先に進められるようになっています。またデイリースクラムで進捗を検査した結果、どうもスプリントに収まらない状況になった場合にタスクの下2個を減らす判断をプロダクトオーナーとともに行う余地も生まれます（スプリントゴールの達成に影響がなければ）。

また、前述のあまり良くない例の場合、コンポーネントを完成させないと後続作業が一切進まず、分業と組み合わさることでリファクタリングやテストが不十分なコードが生まれることがありますが、このようにタスク分解することで、全コンポーネントを横断的かつ継続的に変更していくため、テストの追加やリファクタリングを継続して行いやすくもなっています。

まとめ

以上を踏まえると、プロダクトバックログアイテムを実現していくときには、一気通貫で動作する最低限のものを作ってから、順番に肉付けしていくようにするのが良く、それができるような形でタスクに分解するのが良いということになります。もちろん、チームのスキルや成熟度、アーキテクチャー等によってこのアプローチと適合しない可能性はありますので、スプリントレトロスペクティブなどで自分たちのタスク分解について考えた上で、実験してみると良いと思います。

本日は以上です。