チームを成長させるスプリントバックログとスプリントゴールの作り方 ─ ”とはいえ”シリーズ #11「スプリントバックログ編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第11回のテーマは「スプリントバックログ」です。
前編では、スプリントバックログの内容や具体的な書き方、タスク分解のポイントなどについてお話します。

スプリントバックログとスプリントゴール

中村：
まずは、スクラムガイドの該当部分を一緒に読んでみましょう。
…分かるような、分からないような（笑）。
でも、気になるトピックが山ほどありますね。

新井：
初見ですべてを理解するのは難しいかもしれませんね。

中村：
たしかにそうですよね。新井さんや私は実践を通してずっと触れているから、言わんとしていることが分かりますけど…。

何を言っているかというと、「スプリントバックログはスプリントゴールを実現するためにあるよ」ということ。スプリントゴールを見据えながら、スプリントバックログに対して活動していこうということです。

新井：
ペアで存在するということですね。

中村：
いい表現ですね！　スプリントバックログはあるけどスプリントゴールはないとか、その逆も、基本的にないということですよね。

スプリントバックログはタスクリストだけではないということも言っていますね。

「スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実行可能な計画（どのように）で構成される。」という一文は、読み飛ばしのないようにしたいところです。

新井：
タスクリストやタスクボードがあればいいと思われがちですが、それらは主にWhat（何を）にフォーカスしたものです。

スプリントバックログは、WhatだけでなくWhy（なぜ）とHow（どのように）も合わせた3つがセットになっているんですよね。

中村：
さらに、「より多くのことを学ぶにつれて、スプリントの期間を通して更新される」とあります。

途中で何かが見つかることもあるということを前提に置いていて、すごくいい書き方だなと思います。

新井：
決まったものだから変えちゃいけないと思い込んでしまったり、その通りにこなしていくことを優先するモードになりがちですが、実際はデイリースクラムで検査・適応するサイクルを回していくことが大事です。

そして、検査・適応のためには、ある程度充実したスプリントバックログが必要ということですよね。

中村：
スプリントゴールについては、プロダクトオーナーのものでも開発者のものでもなく「チームに一致団結した作業を促すもの」だと書いてありますね。

新井：
「スプリントの唯一の目的である」とも書いてありますね。

自分のことをふりかえると、スクラムをやり始めた頃はスプリントゴールを結構ないがしろにしてしまっていたなと思います。
やっぱり「タスク管理」になっちゃうんですよね。

スプリントバックログ、どんな風に書けばいい？

新井：
スクラムガイドには「スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要」とあります。

具体的には何を書いてもいいと言えばそうなのですが、受け入れ基準はきちんと書けるといいですね。

何が終わったらこのタスクは終わるのか。タスクごとにきちんと受け入れ条件を書いて、誰が担当するのかというところまで書けるといいかな。そこは必須条件じゃないかなと思います。

ただ、非エンジニアの人たちにスクラムのフレームワークを導入するとき、受け入れ条件（Acceptance Criteria）という考え方は理解が難しいこともあります。

例えば、「○○ミーティングを開催する」「○○ドキュメントを作成する」といったタスクで、明らかに全員が認知できているような場合には、あえて受け入れ条件を書かなくても問題ないと思います。

でも、はじめのうちは認識合わせをするために受け入れ条件をちゃんと書くようにするといいですね。

中村：
今のお話は「What」のところだと思うのですが、「How」についてはどうでしょうか？

代表的な方法としてはタスク分解があると思いますが、その場合は何か違いがあるでしょうか。

新井：
基本的には同じフォーマットで書くようにしますが、タスクのタイトルがきちんと内容を表しているか、誰が見ても同じタスクとして解釈できるかどうか、という点は気にした方がいいですね。特に最初の方は見落とされがちです。

中村：
タイトルは対象だけを書くのではなく、「○○を××する」という風に書くといいですね。

例えば「ニンジン」としか書いていないと、それを焼くのか切るのか分からないので、結局誰かに訊くことになります。それはもったいないですよね。

インクリメントを届けるための計画は、大体はタスクリストになりますが、全体の構造が一覧で見られるようにするといいですね。

1枚のボードの最上位に「何のためのスプリントなのか？」がちゃんと書いてあって、その下に「それを実現するためのバックログアイテム」があって、その横に「それらのバックログアイテムの受け入れ条件」を現実のものにするためのタスクのリストがあるみたいな感じです。

新井：
スプリントのバーンダウンチャートを使うのはどうでしょうか？

※バーンダウンチャートとは
プロジェクトの進捗状況を視覚的に見ることができるグラフのこと。縦軸に残りの作業量を、横軸に時間を示すことが多い。プロジェクトの総作業量と期間が決定したら、日々の作業量の進捗を記録し、理想線と実績線を書き入れる。

中村：
最近は、初手ではあまり作らないですね。チームの熟練度にもよりますが、チームが必要だと思えば作るという感じでしょうか。

1週間のスプリントなら実質は5日間ですから、そこまでしなくても大体分かるというのが体感です。

新井：
たしかに、2週間スプリントなら折り返し地点で「本当に終わるのか？」と気になるところですが、1週間スプリントなら大体見通せますよね。