スクラムチーム（Scrum Team）はプロダクトバックログ（Product Backlog）というリストの一番上の項目を、次の（あるいは最初の）スプリントで開発して完成させます。ごくごく簡単に言うと、「このスプリントで作ると決めたプロダクトバックログ」が、スプリントバックログです。
Scrum.org のスクラムガイドによると、スプリントバックログについて次のように書かれています。
スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実⾏可能な計画（どのように）で構成される。
スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。
https://www.scrum.org/resources/scrum-guide
これによると『「作ると決めたプロダクトバックログ」だけがスプリントバックログではない』ということがわかります。その他に、スプリントゴールと計画を合わせてスプリントバックログと呼びます。
なぜ作るのか？何を作るのか？どのように作るのか？を合わせてスプリントバックログバックログなのですね。
この「計画」については Azure DevOps などのシステムを使っているスクラムチームであれば、特に意識していなくても扱うことになると思いますが、「スプリントゴール」については意識していないスクラムチームが多いかもしれません。また、バックログの選択の仕方やタスクの扱い、リアルタイムに更新できているかどうかについても、慣れるまではなかなか難しいところがあります。それぞれのポイントについて、もう少し詳しく見てみましょう。
目次
- 1 なぜ作るのか？＝ スプリントゴール
- 2 Azure DevOps では Sprint Goal 拡張機能でスプリントゴールを Sprint 画面に表示する
- 3 何を作るのか？＝選択されたプロダクトバックログアイテム
- 4 Azure DevOps の Backlogs でプロダクトバックログをスプリントに入れる
- 5 どのように作るのか？＝インクリメントを完成させる計画を１～２時間で終わらせられるタスクで洗い出す
- 6 Azure DevOps の Sprints 画面で計画をする（PBI に Task を追加する）
- 7 開発者が自分たちで計画する（管理職にアサインされるのではなく、リアルタイムに更新する）
なぜ作るのか？＝ スプリントゴール
プロダクトオーナー（PO）は、プロダクトゴールによって開発者にプロダクトの将来の状態を示します。プロダクトゴールは、今のスプリントや次のスプリントでどうなるか？というよりも、もっと先の将来のスプリントが終わったときに、プロダクトがどうなっていてほしいか？ということを表しています。では、次の（あるいは最初の）スプリントが終わったときにはどうなっていて欲しいのでしょうか？それがスプリントゴールです。
そんなの、最初のプロダクトバックログが完成していて欲しいに決まっているよ、と思うかもしれません。それは半分は正しいかもしれませんが、半分は正しくないかもしれません。例えば、プロダクトバックログの１つの項目が、スプリント１回で完成させるには大きすぎる場合にはどうでしょうか？
もう少し具体的な例で考えると「ユーザーが□□を検索する」とか単に「□□検索」とタイトルがつけられたようなプロダクトバックログがあって、そこには対象の □□ を検索する様々な方法、入力できるキーワードや曖昧検索ができること、フィルタリングできる列の項目や、ページネーション・ページングがどうであってほしいということが Description にしっかり記載されていたとします。スクラムチームが見積もりをしてみるまでは１スプリントで完成させられそうなイメージでしたが、実際に見積もりをしてみるといくつかの難しい＝時間がかかるポイントがあることが数名の開発者から指摘されて、１スプリントでは完成させられそうにないことがわかりました。この時、どのようにしたらよいのでしょうか？ここで重要になるのがスプリントゴールです。
PO がユーザーなどのステークホルダーと会話して、最初に欲しいのは（様々なキーワードで検索することではなく）○○番号 で検索できればOKで、それで実務利用に十分耐えられるということがわかっていました。今は全く検索はできないので、とにかく検索できるようになることが最優先で、それがこのスプリントのゴールだと。そしてそれ以外の検索方法は、業務効率化のために、後のスプリントで追加されると嬉しいと。そういう背景が PO から開発者に説明されれば、この１スプリントには大きすぎる Product Backlog Item（PBI）をうまく分割することが出来ます。例えば「ユーザーが○○番号を入力して□□を検索できる」という PBI と、それ以外の検索方法の PBI に分割します。
もし PO からスプリントゴールが示されない場合には、開発者はどのように PBI を分割すればよいのか、イメージすることが出来ません。例えば最悪のケースでは「検索条件を入力する画面を作ります。検索結果は表示されません。検索結果は次のスプリントで表示されるようになります。」という PBI になるかもしれません。それでは誰も使うことが出来ないので、全くビジネス的価値が生み出せていません。そこまで酷いケースでなくても、「これで誰が使えるの？」というような状態はよくあるのではないでしょうか？それでは、たとえ PBI を計画通りに完成させられたとしても、「スクラムチームはこのスプリントで全く価値を出せなかった」という評価になってしまいます。これは悲劇ですが、もしかしたらかなり多くのうまく行っていないスクラムチームが、この状態に陥っているのではないでしょうか？
スクラムチームとしては毎回、スプリントで作ると宣言したものをちゃんと作っているし、遅れも全くないのに、スクラムチームの外部からは評価が全くされない、いつまでたっても価値が出せない、作るのが遅いと思われている。こういうことがあれば、もしかしたらこれはスプリントゴールをうまく決めることが出来ていないことが原因かもしれません。PO がスクラムチームの外のステークホルダーと十分に会話して、適切なスプリントゴールを決めることが出来ていれば、それがコミットメントになります。そしてそのうえで、スクラムチームがスプリントゴールをちゃんと達成できれば、スクラムチームは価値を出せていると認められるはずです（べきです）。
スクラムチームがスプリントの終わりにステークホルダーにレビューしてもらうものは、スプリントゴールを実現したインクリメントであって、それは将来のプロダクトゴールへ向かっている現時点でのものだということを、ステークホルダーにも十分納得してもらったうえで進めましょう。
他にも品質の面や細かい動作の仕様を考えるときにもスプリントゴールは重要な判断材料になります。どうすべきか迷ったときには、「あぁ、あのユーザーさんが、こういう風に使うはずだから、それならこっちの方がいいはずだな」というような、より具体的なイメージで検討することが出来ます。
このようにスプリントゴールは、これから作ろうとするものを、なぜこのスプリントに作らなければならないのか？という Why の部分をより明確にするために必要です。
Azure DevOps では Sprint Goal 拡張機能でスプリントゴールを Sprint 画面に表示する
プロダクトゴールと同じように、スプリントゴールもシンプルなテキストで記載して、スクラムチームがいつでも見えるようにしておくのがよいでしょう。
Azure DevOps にスプリントゴール拡張機能（Sprint Goal extension）をインストールすると、Sprints 画面にスプリントゴールを表示できます。
今のスプリントのスプリントゴールを、Sprints の画面に表示できるのはとてもわかりやすいですね。他に、ウィジェットとしてダッシュボードに表示することもできます。スクラムチームはプロダクトバックログアイテム（PBI）だけではなく、スプリントゴールも意識するようにします。
何を作るのか？＝選択されたプロダクトバックログアイテム
なぜ作るか？の Why の部分が明確になった後は、実際に何を作るか？です。それは、プロダクトバックログのリストの中で、このスプリントで作ることになった項目です。ここまではとても分かりやすいと思います。
改めて注意しなければならないのは、プロダクトバックログのリストは、優先順に並んでいるということです。それも、（よく聞く「全てが最優先」というのではなく）本当に、１番のものを最初に実現します。２番のものは必ず、１番のものが完成してリリース可能になったあとに着手します。それまで同時並行で着手したりしません。それを踏まえて、まずはプロダクトバックログのリストの１番優先度の高いもの、つまり１番上の項目をこのスプリントでやると決めます。
先ほど、最初の項目（Product Backlog Item : PBI）が大きすぎて１スプリントで完成しない場合は、スプリントゴールに合わせて、かつ１スプリントに収まるサイズに分割する、という話をしました。では逆に、１スプリント１PBI では早く完成してしまって時間が余ってしまいそう、という場合はどうでしょうか？その場合には、２番目の PBI をスプリントバックログとして選択します。もちろん２番目の PBI が、１番目の PBI を完成させた残りの時間で完成させられるサイズではない場合には、完成させられるサイズに分割します。（あるいはもし、どうしてもPBIを入れることが出来ないぐらいの時間だけ余るというような場合には，他の PBI を詳細化するリファインメントや、将来の PBI を実現するために必要な技術を調査するようなスパイクに着手するなどを検討します。）
ここで注意しなければならない点が２つあります。１つ目は、２つ以上の PBI をスプリントバックログとして選択したとしても、PBI は同時並行で着手しないという点です。かならず １つ目の PBI が完了・完成してから、２つ目の PBI に着手するということです。それはもちろん全てのテストや必要な環境へのデプロイ、リリース可能にすることやスプリントレビューの準備も含めてすべての作業が１つ目の PBI について完了して、初めて２つ目のPBI に着手するということです。
では、スプリントバックログは １つ目の PBI だけを選択しておいて、それが完成して時間が余ったら、２つ目の PBI をスプリントバックログとして選択するのか？というとそれは違います。それが２つ目の注意しなければならないポイントです。
もし実際に開発を進めた結果、スプリントの途中で全ての選択した PBI を完了させてしまってやることがなくなってしまった場合には、残りの時間で次の PBI を着手できるかどうか？検討するのは正しいことです。ただ、そうはならないということです。多くの場合、スプリントバックログとして １つの PBI を選択してスプリントを開始すると、１スプリントの時間を全て使って、選択された１つの PBI を完成させるようにしてしまうでしょう。「時間が余ったら次のをやる」というのは「時間が余らなかったらやらなくていい」というメッセージを送っているようなものです。そうではなくて、自分たちのチームがこのスプリントでいったいどの PBI を完成させられるのか？ちゃんと見積もって、それをコミットメントとして、スプリントを開始するべきです。
PBI を数値として見積もっていれば、前回のスプリントで完成させられた数値が、今のこのチームの生産力の目安となる数値であるはずです。前回のスプリントで選択し、完成させた PBI の見積もりの合計と、同じ数値まで今回のスプリントでも完成させられるだろうと予想して PBI を選択します。そして、そのうえで、１つずつ PBI を完成させていきます。
プロダクトオーナー（PO）は技術的な内容や見積もりの正しさはわかりません。それでも、開発者が数値で見積もった数値の合計が、生産力の数値より大きいか小さいかは理解できます。開発者は（なんとなくの感覚で間に合いそう、とか、間に合わなそうとか言うのではなくて）数値で PO に説明することで、またそれをちゃんと完成させることで、PO の信頼を得られると思います。
Azure DevOps の Backlogs でプロダクトバックログをスプリントに入れる
Azure DevOps のプロダクトバックログアイテム（PBI）には、Effort の項目に、見積もりをした数値を入れることが出来ます。詳細画面の他、Backlogs の画面でも確認することが出来ます。
また、チームの生産力を表すベロシティは Backlogs の画面で、オプションの Forecasting（予測）を On にして表示される、velocity に入力します。
Backlogs 画面の Forecasting の機能で、今の生産力（velocity）のまま開発を続けたら、どの PBI がどのスプリントで完成しそうか？という予測を表示してくれます。これはもちろん、今の数値で単純に割り算をしているだけなので、この時点で将来のどのスプリントでどの PBI が完成させられると保証できるものではありません。しかし、少なくとも前回のスプリントでの実績値で見積もっているので、感覚的に間に合うかどうか？という話よりは正しく予測できていそうです。この予測を見ながら、このスプリントで完成されられる PBI を上から選択します。
選択した PBI はまとめて右の Planning のパネルに移動させることで、スプリントを指定できます。マウスで操作するときに、タイトルの文字があるところをクリックしてしまうと、項目の詳細画面を開いてしまってうまく行きません。文字のないところで選択をして、文字のないところでマウスのボタンを押して、そのままドラッグしてスプリントの枠に持っていきます。
ここで指定するのは、これから始める今のスプリントの分だけです。その先のスプリントのことは、まだ次のスプリントになるまでわかりません。まだこの時点では先のスプリントは指定しないようにします。次のスプリントや将来のスプリントに入れてしまうと、開発者やステークホルダーに、そうするのが Scrum で当たり前のこととか、どのスプリントで完成させるとコミットしているかのような間違った印象を与えてしまいます。必ず、今のスプリントだけを指定して、将来のスプリントは指定しない状態を保つようにしましょう。
一度、先のスプリントを指定してしまった PBI は、Planning の一番上の枠（「〇〇 Team Backlog」というような表示になっているはずです）にマウスで持っていって入れてやれば、スプリントの指定が削除されて、一旦、どのスプリントでやるか未定の状態に戻ります。
スプリントをいくつか経験したチームは、前回のスプリントで完成させられた PBI の Effort の合計が velocity の数値となりますが、まだこれから初めてのスプリントを開始するというチームの場合はベロシティがわかりません。チームの生産力がまだわからないのは、まだ開発をしていないので当たり前のことですよね。最初のスプリントでは、仮のベロシティを決めて見積もりをするしかありません。当然、それは予想通りに行かずに、多少ズレが出るはずです。何スプリントか見積もりと開発を繰り返していくなかで、徐々にベロシティが安定してきます。逆に見積もりや PBI の選択をしないと、いつまで経っても見積もれないし、生産力の数値もわからないですよね。それを前提として、最初のスプリントの見積もりと PBI の選択を行います。
どのように作るのか？＝インクリメントを完成させる計画を１～２時間で終わらせられるタスクで洗い出す
なぜ作るのか？（Why）と、何を作るのか？（What）が決まったあとは、どうやって作るのか？（How）を決めること＝計画ですね。このスプリントで作ると選択したプロダクトバックログアイテム（PBI）を、実現するために必要な作業をタスク（Task）として洗い出します。
タスクを洗い出すコツは、ひとつのタスクを 1時間～2時間 で完了させられるぐらいの粒度で記載するということです。例えば、PBI が「ユーザーが□□検索できる」だとして、タスクが「□□検索を作る」では大きすぎるということです。また「設計をする」「実装をする」「テストをする」でも、まだ大きすぎます。もしこの粒度でしかタスクが思い浮かばないとすると、PBI の詳細化・リファインメントが足りていないのかもしれません。PBI で実現したいことや、それを実装するために必要なアーキテクチャや利用するフレームワーク・ライブラリなどがまだ十分に見えていない場合には、このように「設計する」というタスクしか上げられないと思います。そうではなくて、例えば利用するフレームワークがわかっているなら、それを利用した「検索画面の View を作る」とか「検索画面の Model を作る」など、もう少し具体的なタスクが見えてくるはずです。それらが見えてくるまで、リファインメントやスプリントプランニングの中で話し合って、詳細が見えてきたところで、それぞれ１～２時間程度で作業できるサイズでタスクを記載していきます。
タスクを１～２時間で記載するというのには、もうひとつ、進捗をトラッキングしやすいという都合があります。もし例えば８時間（１日の稼働時間）以上で実行する大きなタスクを作ってしまった場合、進捗を見える化できるでしょうか？デイリースクラムで、１日目には「このタスクに取り組みます」と宣言し、２日目には「まだやっていますがもうすぐ終わります」と言ったとき、３日目に本当に終わっていそうか？それともここで誰かが支援した方がいいのか？など、チームはこのタスクの状況を正確に把握できるでしょうか？３日目になってもまだ終わっていなかったとき、いったい何時間の遅延になっているのでしょうか？
よく「進捗は 90％ まで進んだあと、ずっと進まない、ずっと 90% で何日も・・・」というのは、ウォーターフォールの開発でもよく見られることですが、まだ完了していないタスクの進捗を正確に表すのは非常に難しいものです。タスクの進捗は、タスクが終わったか、まだ終わっていないか？で判断するのが最も正確です。それ以外の ％ の自己申告に頼るのは非常に危険です。本人はあと少しで終わる、と思ったまま、当初予定の何倍も時間をかけてしまった、なんてことはよくあることです。
もしタスクが１～２時間で終わるサイズで記載されてれば、予定の１～２時間を過ぎてもまだ終わらなけばすぐにアラートを挙げて、他の人に支援してもらうことが出来ます。また、担当者自身でアラートをあげられなくても、最長でも次のデイリースクラムには他の誰かが気づいてすぐに支援することが出来ます。最大の遅延でもそこで食い止めることが出来ます。そのためにもタスクは １～２時間で洗い出していきます。
スプリントプランニングが終わるまでの間に、全てのタスクが出し切れなくても、一旦、数日分のタスクが洗い出せていれば、開発を開始できます。洗い出せなかったタスクは、開発を進めながら少しずつ洗い出して追加するしかありません。しかし、その場合には、「始めてみたら思ったより大変で、完成させられそうになかった」ということが起きやすいように思います。そうならないように、理想的には、スプリントプランニングが終わるまでにこれで大丈夫そうだと思えるぐらいにはある程度のタスクを出し切っておくと良いと思います。
Azure DevOps の Sprints 画面で計画をする（PBI に Task を追加する）
Azure DevOps でタスクを扱うには Sprints の画面を使用します。Backlogs の画面でスプリントを指定したプロダクトバックログアイテム（PBI）が、Sprints の今のスプリントに表示されます。
PBI の ＋ ボタンを押してタスク（Task）を追加します。簡潔なタイトルだけを入力して、タスクを洗い出し、必要に応じて、Description に詳細を記載して作業ミスや漏れが無いように工夫します。
Task の Description も PBI の Description と同じように簡単な書式が使えます。表は、OneNote など他の Office アプリで入力したものをコピペすると入力できます（そのあとは自由に編集できます）。
Remaining Work に残時間を、「時間」単位で記載します。１～２時間 になるようにタスクを洗い出していると理想的です。作業を開始したら、Remaining Work を減らしていきます。例えば １～２時間で見積もったタスクが、作業開始後にいつまでも残り時間 １～２時間であれば、「これはおかしい」と気づいて声をかけるべきです。
また作業時間は Sprints 画面の上に合計が表示されるので、スプリントの残りの全員の稼働時間で、全てのタスクが終わらせられるかどうか？確認することが出来ます。
Task の担当者（Assigned）は、最初 ToDO にタスクがあるときは入力せず、これから着手するときに開発者自身が自分でタスクに自分の名前を入れます。
理想的には本当に着手するまで In Progress にしません。これから作業するという瞬間に In Progress にして、In Progress にあるタスクが開発者の人数と一致している状態にするのがわかりやすいです。もしそれでは1日の計画が難しい場合には、デイリースクラムでその日の作業分を In Progress にするなど、最大でも１日分だけを In Progress にするようにします。明日の以降の作業を In Progress にしたり、前日から作業をずっとやり続けて完了させずにずっと In Progress にしていたり、ということが無いように気を付けます。
ひとつのタスクを複数名で実施するときには、同じ内容のタスクを人数分作って、それぞれを自分で In Progress にして取り組みます。もちろん時間もそれぞれに入れます。これをやらないと、残タスクの残時間と、稼働時間で実施できる残時間の計算が食い違って、間に合うと思っていた作業が間に合わないということになってしまいます。複数名で同じタスクをやることが分かった時点で、残時間を適切に入力したタスクを人数分作成するようにします。
これらを前提に、タスクを洗い出して PBI の Task として登録していきます。
開発者が自分たちで計画する（管理職にアサインされるのではなく、リアルタイムに更新する）
スクラムチームは自己管理型（セルフマネジメント）で開発を行います。タスクは、誰か管理職やリーダーにアサインされるのではなくて、開発者自身が、残っているチームのタスクから選択して、作業を開始します。
タスクの洗い出しは開発者全員で行います。誰か有識者やリーダーだけがタスクを洗い出すということが無いように気を付けます。全員でタスクを洗い出すということは、開発者全員が、すべてのタスクのことを理解しているということです。理想的には全てのタスクをどれでも、どの開発者でも実施できると良いです。スキル的な面でそれが難しい場合でも、何名かは担当できて、そのほかの人もある程度何をやっているかわかるレベルで認識しているのが望ましいです。これによって、自分が着手したタスクが完了したら、次の残っているタスクをすぐに実施することが出来ます。
もし技術的に、最初にタスクに見積もりされた Remaining Work （残時間）で自分が実施できない場合には、チームで相談をして、残時間を増やしてでも担当した方が良いか、別のタスクを実施した方が良いのか、チームで判断をします。個々のそれぞれのスキルによってどうしても同じ時間ではできない、あるいは早く終わらせられる、という差があるはずです。それらをうまく調整することで、スプリントの残りの時間でプロダクトバックログアイテム（PBI）を完成させられるように、チーム全員で再計画をしていきます。それがセルフマネジメントということです。それができるようにするためにも、タスクの洗い出しや PBI の見積もりの時点で、開発者全員が参加している必要があります。
また、この再計画を行うためにも正しく状況を把握する必要があります。開発者は作業を開始するときにタスクを In Progress にして自分の名前を入れる。作業を行うと Remaining Work を減らす。完了するとタスクを Done にする。これを全員がそれぞれ自分で行うことで、常にチームの状況がリアルタイムに更新されます。これを毎日の再計画のために活用します。
こういった意味で、スプリントバックログは開発者のための計画だと言えます。
コメント
