スクラムチーム(Scrum Team)はプロダクトバックログ(Product Backlog)というリストの一番上の項目を、次の(あるいは最初の)スプリントで開発して完成させます。ごくごく簡単に言うと、「このスプリントで作ると決めたプロダクトバックログ」が、スプリントバックログです。

Scrum.orgスクラムガイドによると、スプリントバックログについて次のように書かれています。

スプリントバックログは、スプリントゴール(なぜ)、スプリント向けに選択されたいくつかのプロダクトバックログアイテム(何を)、およびインクリメントを届けるための実⾏可能な計画(どのように)で構成される。

スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。

https://www.scrum.org/resources/scrum-guide

これによると『「作ると決めたプロダクトバックログ」だけがスプリントバックログではない』ということがわかります。その他に、スプリントゴールと計画を合わせてスプリントバックログと呼びます。

なぜ作るのか?何を作るのか?どのように作るのか?を合わせてスプリントバックログバックログなのですね。

この「計画」については Azure DevOps などのシステムを使っているスクラムチームであれば、特に意識していなくても扱うことになると思いますが、「スプリントゴール」については意識していないスクラムチームが多いかもしれません。また、バックログの選択の仕方やタスクの扱い、リアルタイムに更新できているかどうかについても、慣れるまではなかなか難しいところがあります。それぞれのポイントについて、もう少し詳しく見てみましょう。

なぜ作るのか?= スプリントゴール

プロダクトオーナー(PO)は、プロダクトゴールによって開発者にプロダクトの将来の状態を示します。プロダクトゴールは、今のスプリントや次のスプリントでどうなるか?というよりも、もっと先の将来のスプリントが終わったときに、プロダクトがどうなっていてほしいか?ということを表しています。では、次の(あるいは最初の)スプリントが終わったときにはどうなっていて欲しいのでしょうか?それがスプリントゴールです。

そんなの、最初のプロダクトバックログが完成していて欲しいに決まっているよ、と思うかもしれません。それは半分は正しいかもしれませんが、半分は正しくないかもしれません。例えば、プロダクトバックログの1つの項目が、スプリント1回で完成させるには大きすぎる場合にはどうでしょうか?

大きすぎるPBIの例「□□検索 」

もう少し具体的な例で考えると「ユーザーが□□を検索する」とか単に「□□検索」とタイトルがつけられたようなプロダクトバックログがあって、そこには対象の □□ を検索する様々な方法、入力できるキーワードや曖昧検索ができること、フィルタリングできる列の項目や、ページネーション・ページングがどうであってほしいということが Description にしっかり記載されていたとします。スクラムチームが見積もりをしてみるまでは1スプリントで完成させられそうなイメージでしたが、実際に見積もりをしてみるといくつかの難しい=時間がかかるポイントがあることが数名の開発者から指摘されて、1スプリントでは完成させられそうにないことがわかりました。この時、どのようにしたらよいのでしょうか?ここで重要になるのがスプリントゴールです。

大きすぎる PBI を2つに分割した様子

PO がユーザーなどのステークホルダーと会話して、最初に欲しいのは(様々なキーワードで検索することではなく)○○番号 で検索できればOKで、それで実務利用に十分耐えられるということがわかっていました。今は全く検索はできないので、とにかく検索できるようになることが最優先で、それがこのスプリントのゴールだと。そしてそれ以外の検索方法は、業務効率化のために、後のスプリントで追加されると嬉しいと。そういう背景が PO から開発者に説明されれば、この1スプリントには大きすぎる Product Backlog Item(PBI)をうまく分割することが出来ます。例えば「ユーザーが○○番号を入力して□□を検索できる」という PBI と、それ以外の検索方法の PBI に分割します。

もし PO からスプリントゴールが示されない場合には、開発者はどのように PBI を分割すればよいのか、イメージすることが出来ません。例えば最悪のケースでは「検索条件を入力する画面を作ります。検索結果は表示されません。検索結果は次のスプリントで表示されるようになります。」という PBI になるかもしれません。それでは誰も使うことが出来ないので、全くビジネス的価値が生み出せていません。そこまで酷いケースでなくても、「これで誰が使えるの?」というような状態はよくあるのではないでしょうか?それでは、たとえ PBI を計画通りに完成させられたとしても、「スクラムチームはこのスプリントで全く価値を出せなかった」という評価になってしまいます。これは悲劇ですが、もしかしたらかなり多くのうまく行っていないスクラムチームが、この状態に陥っているのではないでしょうか?

スクラムチームとしては毎回、スプリントで作ると宣言したものをちゃんと作っているし、遅れも全くないのに、スクラムチームの外部からは評価が全くされない、いつまでたっても価値が出せない、作るのが遅いと思われている。こういうことがあれば、もしかしたらこれはスプリントゴールをうまく決めることが出来ていないことが原因かもしれません。PO がスクラムチームの外のステークホルダーと十分に会話して、適切なスプリントゴールを決めることが出来ていれば、それがコミットメントになります。そしてそのうえで、スクラムチームがスプリントゴールをちゃんと達成できれば、スクラムチームは価値を出せていると認められるはずです(べきです)。

スクラムチームがスプリントの終わりにステークホルダーにレビューしてもらうものは、スプリントゴールを実現したインクリメントであって、それは将来のプロダクトゴールへ向かっている現時点でのものだということを、ステークホルダーにも十分納得してもらったうえで進めましょう。

他にも品質の面や細かい動作の仕様を考えるときにもスプリントゴールは重要な判断材料になります。どうすべきか迷ったときには、「あぁ、あのユーザーさんが、こういう風に使うはずだから、それならこっちの方がいいはずだな」というような、より具体的なイメージで検討することが出来ます。

このようにスプリントゴールは、これから作ろうとするものを、なぜこのスプリントに作らなければならないのか?という Why の部分をより明確にするために必要です。

Azure DevOps では Sprint Goal 拡張機能でスプリントゴールを Sprint 画面に表示する

プロダクトゴールと同じように、スプリントゴールもシンプルなテキストで記載して、スクラムチームがいつでも見えるようにしておくのがよいでしょう。

Azure DevOps にスプリントゴール拡張機能(Sprint Goal extension)をインストールすると、Sprints 画面にスプリントゴールを表示できます。

Sprints 画面に、スプリントゴールが表示されている

今のスプリントのスプリントゴールを、Sprints の画面に表示できるのはとてもわかりやすいですね。他に、ウィジェットとしてダッシュボードに表示することもできます。スクラムチームはプロダクトバックログアイテム(PBI)だけではなく、スプリントゴールも意識するようにします。

何を作るのか?=選択されたプロダクトバックログアイテム

なぜ作るか?の Why の部分が明確になった後は、実際に何を作るか?です。それは、プロダクトバックログのリストの中で、このスプリントで作ることになった項目です。ここまではとても分かりやすいと思います。

改めて注意しなければならないのは、プロダクトバックログのリストは、優先順に並んでいるということです。それも、(よく聞く「全てが最優先」というのではなく)本当に、1番のものを最初に実現します。2番のものは必ず、1番のものが完成してリリース可能になったあとに着手します。それまで同時並行で着手したりしません。それを踏まえて、まずはプロダクトバックログのリストの1番優先度の高いもの、つまり1番上の項目をこのスプリントでやると決めます。

先ほど、最初の項目(Product Backlog Item : PBI)が大きすぎて1スプリントで完成しない場合は、スプリントゴールに合わせて、かつ1スプリントに収まるサイズに分割する、という話をしました。では逆に、1スプリント1PBI では早く完成してしまって時間が余ってしまいそう、という場合はどうでしょうか?その場合には、2番目の PBI をスプリントバックログとして選択します。もちろん2番目の PBI が、1番目の PBI を完成させた残りの時間で完成させられるサイズではない場合には、完成させられるサイズに分割します。(あるいはもし、どうしてもPBIを入れることが出来ないぐらいの時間だけ余るというような場合には,他の PBI を詳細化するリファインメントや、将来の PBI を実現するために必要な技術を調査するようなスパイクに着手するなどを検討します。)

ここで注意しなければならない点が2つあります。1つ目は、2つ以上の PBI をスプリントバックログとして選択したとしても、PBI は同時並行で着手しないという点です。かならず 1つ目の PBI が完了・完成してから、2つ目の  PBI に着手するということです。それはもちろん全てのテストや必要な環境へのデプロイ、リリース可能にすることやスプリントレビューの準備も含めてすべての作業が1つ目の PBI について完了して、初めて2つ目のPBI に着手するということです。

では、スプリントバックログは 1つ目の PBI だけを選択しておいて、それが完成して時間が余ったら、2つ目の PBI をスプリントバックログとして選択するのか?というとそれは違います。それが2つ目の注意しなければならないポイントです。

もし実際に開発を進めた結果、スプリントの途中で全ての選択した PBI を完了させてしまってやることがなくなってしまった場合には、残りの時間で次の PBI を着手できるかどうか?検討するのは正しいことです。ただ、そうはならないということです。多くの場合、スプリントバックログとして 1つの PBI を選択してスプリントを開始すると、1スプリントの時間を全て使って、選択された1つの PBI を完成させるようにしてしまうでしょう。「時間が余ったら次のをやる」というのは「時間が余らなかったらやらなくていい」というメッセージを送っているようなものです。そうではなくて、自分たちのチームがこのスプリントでいったいどの PBI を完成させられるのか?ちゃんと見積もって、それをコミットメントとして、スプリントを開始するべきです。

PBI を数値として見積もっていれば、前回のスプリントで完成させられた数値が、今のこのチームの生産力の目安となる数値であるはずです。前回のスプリントで選択し、完成させた PBI の見積もりの合計と、同じ数値まで今回のスプリントでも完成させられるだろうと予想して PBI を選択します。そして、そのうえで、1つずつ PBI を完成させていきます。

プロダクトオーナー(PO)は技術的な内容や見積もりの正しさはわかりません。それでも、開発者が数値で見積もった数値の合計が、生産力の数値より大きいか小さいかは理解できます。開発者は(なんとなくの感覚で間に合いそう、とか、間に合わなそうとか言うのではなくて)数値で PO に説明することで、またそれをちゃんと完成させることで、PO の信頼を得られると思います。

Azure DevOps の Backlogs でプロダクトバックログをスプリントに入れる

Azure DevOps のプロダクトバックログアイテム(PBI)には、Effort の項目に、見積もりをした数値を入れることが出来ます。詳細画面の他、Backlogs の画面でも確認することが出来ます。

また、チームの生産力を表すベロシティは Backlogs の画面で、オプションの Forecasting(予測)を On にして表示される、velocity に入力します。

Effort とvelocityを入力した Backlogs の Forecasting の例

Backlogs 画面の Forecasting の機能で、今の生産力(velocity)のまま開発を続けたら、どの PBI がどのスプリントで完成しそうか?という予測を表示してくれます。これはもちろん、今の数値で単純に割り算をしているだけなので、この時点で将来のどのスプリントでどの PBI が完成させられると保証できるものではありません。しかし、少なくとも前回のスプリントでの実績値で見積もっているので、感覚的に間に合うかどうか?という話よりは正しく予測できていそうです。この予測を見ながら、このスプリントで完成されられる PBI を上から選択します。

Planning で Sprint に入れるときは、文字がないところをドラッグ

選択した PBI はまとめて右の Planning のパネルに移動させることで、スプリントを指定できます。マウスで操作するときに、タイトルの文字があるところをクリックしてしまうと、項目の詳細画面を開いてしまってうまく行きません。文字のないところで選択をして、文字のないところでマウスのボタンを押して、そのままドラッグしてスプリントの枠に持っていきます。

ここで指定するのは、これから始める今のスプリントの分だけです。その先のスプリントのことは、まだ次のスプリントになるまでわかりません。まだこの時点では先のスプリントは指定しないようにします。次のスプリントや将来のスプリントに入れてしまうと、開発者やステークホルダーに、そうするのが Scrum で当たり前のこととか、どのスプリントで完成させるとコミットしているかのような間違った印象を与えてしまいます。必ず、今のスプリントだけを指定して、将来のスプリントは指定しない状態を保つようにしましょう。

一度、先のスプリントを指定してしまった PBI は、Planning の一番上の枠(「〇〇 Team Backlog」というような表示になっているはずです)にマウスで持っていって入れてやれば、スプリントの指定が削除されて、一旦、どのスプリントでやるか未定の状態に戻ります。

スプリントをいくつか経験したチームは、前回のスプリントで完成させられた PBI の Effort の合計が velocity の数値となりますが、まだこれから初めてのスプリントを開始するというチームの場合はベロシティがわかりません。チームの生産力がまだわからないのは、まだ開発をしていないので当たり前のことですよね。最初のスプリントでは、仮のベロシティを決めて見積もりをするしかありません。当然、それは予想通りに行かずに、多少ズレが出るはずです。何スプリントか見積もりと開発を繰り返していくなかで、徐々にベロシティが安定してきます。逆に見積もりや PBI の選択をしないと、いつまで経っても見積もれないし、生産力の数値もわからないですよね。それを前提として、最初のスプリントの見積もりと PBI の選択を行います。

どのように作るのか?=インクリメントを完成させる計画を1~2時間で終わらせられるタスクで洗い出す

なぜ作るのか?(Why)と、何を作るのか?(What)が決まったあとは、どうやって作るのか?(How)を決めること=計画ですね。このスプリントで作ると選択したプロダクトバックログアイテム(PBI)を、実現するために必要な作業をタスク(Task)として洗い出します。

タスクを洗い出すコツは、ひとつのタスクを 1時間~2時間 で完了させられるぐらいの粒度で記載するということです。例えば、PBI が「ユーザーが□□検索できる」だとして、タスクが「□□検索を作る」では大きすぎるということです。また「設計をする」「実装をする」「テストをする」でも、まだ大きすぎます。もしこの粒度でしかタスクが思い浮かばないとすると、PBI の詳細化・リファインメントが足りていないのかもしれません。PBI で実現したいことや、それを実装するために必要なアーキテクチャや利用するフレームワーク・ライブラリなどがまだ十分に見えていない場合には、このように「設計する」というタスクしか上げられないと思います。そうではなくて、例えば利用するフレームワークがわかっているなら、それを利用した「検索画面の View を作る」とか「検索画面の Model を作る」など、もう少し具体的なタスクが見えてくるはずです。それらが見えてくるまで、リファインメントやスプリントプランニングの中で話し合って、詳細が見えてきたところで、それぞれ1~2時間程度で作業できるサイズでタスクを記載していきます。

タスクを1~2時間で記載するというのには、もうひとつ、進捗をトラッキングしやすいという都合があります。もし例えば8時間(1日の稼働時間)以上で実行する大きなタスクを作ってしまった場合、進捗を見える化できるでしょうか?デイリースクラムで、1日目には「このタスクに取り組みます」と宣言し、2日目には「まだやっていますがもうすぐ終わります」と言ったとき、3日目に本当に終わっていそうか?それともここで誰かが支援した方がいいのか?など、チームはこのタスクの状況を正確に把握できるでしょうか?3日目になってもまだ終わっていなかったとき、いったい何時間の遅延になっているのでしょうか?

よく「進捗は 90% まで進んだあと、ずっと進まない、ずっと 90% で何日も・・・」というのは、ウォーターフォールの開発でもよく見られることですが、まだ完了していないタスクの進捗を正確に表すのは非常に難しいものです。タスクの進捗は、タスクが終わったか、まだ終わっていないか?で判断するのが最も正確です。それ以外の % の自己申告に頼るのは非常に危険です。本人はあと少しで終わる、と思ったまま、当初予定の何倍も時間をかけてしまった、なんてことはよくあることです。

もしタスクが1~2時間で終わるサイズで記載されてれば、予定の1~2時間を過ぎてもまだ終わらなけばすぐにアラートを挙げて、他の人に支援してもらうことが出来ます。また、担当者自身でアラートをあげられなくても、最長でも次のデイリースクラムには他の誰かが気づいてすぐに支援することが出来ます。最大の遅延でもそこで食い止めることが出来ます。そのためにもタスクは 1~2時間で洗い出していきます。

スプリントプランニングが終わるまでの間に、全てのタスクが出し切れなくても、一旦、数日分のタスクが洗い出せていれば、開発を開始できます。洗い出せなかったタスクは、開発を進めながら少しずつ洗い出して追加するしかありません。しかし、その場合には、「始めてみたら思ったより大変で、完成させられそうになかった」ということが起きやすいように思います。そうならないように、理想的には、スプリントプランニングが終わるまでにこれで大丈夫そうだと思えるぐらいにはある程度のタスクを出し切っておくと良いと思います。

Azure DevOps の Sprints 画面で計画をする(PBI に Task を追加する)

Azure DevOps でタスクを扱うには Sprints の画面を使用します。Backlogs の画面でスプリントを指定したプロダクトバックログアイテム(PBI)が、Sprints の今のスプリントに表示されます。

Sprints にタスクを追加、残時間の合計も表示される

PBI の + ボタンを押してタスク(Task)を追加します。簡潔なタイトルだけを入力して、タスクを洗い出し、必要に応じて、Description に詳細を記載して作業ミスや漏れが無いように工夫します。

Task 詳細画面

Task の Description も PBI の Description と同じように簡単な書式が使えます。表は、OneNote など他の Office アプリで入力したものをコピペすると入力できます(そのあとは自由に編集できます)。

Remaining Work に残時間を、「時間」単位で記載します。1~2時間 になるようにタスクを洗い出していると理想的です。作業を開始したら、Remaining Work を減らしていきます。例えば 1~2時間で見積もったタスクが、作業開始後にいつまでも残り時間 1~2時間であれば、「これはおかしい」と気づいて声をかけるべきです。

また作業時間は Sprints 画面の上に合計が表示されるので、スプリントの残りの全員の稼働時間で、全てのタスクが終わらせられるかどうか?確認することが出来ます。

タスクを自分で In Progress にし、終了したら Done にする

Task の担当者(Assigned)は、最初 ToDO にタスクがあるときは入力せず、これから着手するときに開発者自身が自分でタスクに自分の名前を入れます。

理想的には本当に着手するまで In Progress にしません。これから作業するという瞬間に In Progress にして、In Progress にあるタスクが開発者の人数と一致している状態にするのがわかりやすいです。もしそれでは1日の計画が難しい場合には、デイリースクラムでその日の作業分を In Progress にするなど、最大でも1日分だけを In Progress にするようにします。明日の以降の作業を In Progress にしたり、前日から作業をずっとやり続けて完了させずにずっと In Progress にしていたり、ということが無いように気を付けます。

ひとつのタスクを複数名で実施するときには、同じ内容のタスクを人数分作って、それぞれを自分で In Progress にして取り組みます。もちろん時間もそれぞれに入れます。これをやらないと、残タスクの残時間と、稼働時間で実施できる残時間の計算が食い違って、間に合うと思っていた作業が間に合わないということになってしまいます。複数名で同じタスクをやることが分かった時点で、残時間を適切に入力したタスクを人数分作成するようにします。

これらを前提に、タスクを洗い出して PBI の Task として登録していきます。

開発者が自分たちで計画する(管理職にアサインされるのではなく、リアルタイムに更新する)

スクラムチームは自己管理型(セルフマネジメント)で開発を行います。タスクは、誰か管理職やリーダーにアサインされるのではなくて、開発者自身が、残っているチームのタスクから選択して、作業を開始します。

タスクの洗い出しは開発者全員で行います。誰か有識者やリーダーだけがタスクを洗い出すということが無いように気を付けます。全員でタスクを洗い出すということは、開発者全員が、すべてのタスクのことを理解しているということです。理想的には全てのタスクをどれでも、どの開発者でも実施できると良いです。スキル的な面でそれが難しい場合でも、何名かは担当できて、そのほかの人もある程度何をやっているかわかるレベルで認識しているのが望ましいです。これによって、自分が着手したタスクが完了したら、次の残っているタスクをすぐに実施することが出来ます。

もし技術的に、最初にタスクに見積もりされた Remaining Work (残時間)で自分が実施できない場合には、チームで相談をして、残時間を増やしてでも担当した方が良いか、別のタスクを実施した方が良いのか、チームで判断をします。個々のそれぞれのスキルによってどうしても同じ時間ではできない、あるいは早く終わらせられる、という差があるはずです。それらをうまく調整することで、スプリントの残りの時間でプロダクトバックログアイテム(PBI)を完成させられるように、チーム全員で再計画をしていきます。それがセルフマネジメントということです。それができるようにするためにも、タスクの洗い出しや PBI の見積もりの時点で、開発者全員が参加している必要があります。

また、この再計画を行うためにも正しく状況を把握する必要があります。開発者は作業を開始するときにタスクを In Progress にして自分の名前を入れる。作業を行うと Remaining Work を減らす。完了するとタスクを Done にする。これを全員がそれぞれ自分で行うことで、常にチームの状況がリアルタイムに更新されます。これを毎日の再計画のために活用します。

こういった意味で、スプリントバックログは開発者のための計画だと言えます。

コメント