GitHub Projectsを使った（プロダクト/ スプリント）バックログ管理 #スクラム

こんにちはCX事業本部のKyoです。

スクラムマスターを担当していたプロジェクトから離れることになったので、備忘録を兼ねて（プロダクト/ スプリント）バックログ管理の方法を書き残しておこうと思います。なお運用実績は半年ほどです。

背景

プロジェクトの参画時、開発手法として独自定義のアジャイルが採用されており、以下のような課題がありました。

• PBIの優先順位が不明確で、プランニングが困難
• 新規追加されたPBIの内容をチーム全員が把握できていない
  • そもそも追加されたこと自体に気づきにくい
• スプリントのゴールが分かりづらい
  • 数週間連続で同じPBIが残り続けるなども
  • プロダクトバックログ(相当のもの)とスプリントバックログ(相当のもの)が一体化している

これらを解決するために、開発手法をスクラムへ移行し、バックログの管理の方法を見直しました。なお、移行にあたってはメンタルモデルを獲得するため、先行してスクラムガイドの読書会を実施しています。

GitHub Projectsによるバックログの管理

概要

GitHub Projectsで4つのビュー（New Item、Product Backlog、Sprint Backlog、Completed）を作りました。Sprint Backlog以外はテーブル形式で、以下のカラムを使い分けています。

★ はGitHubによって作られるものです。

以降、ビュー名はアルファベットで表記します。

New Item

Product Backlog Item (PBI)候補の新アイテム一覧を表示します。新アイテムはリファインメントの度に確認され、Product Backlogへ移るため、本ビューは空が基本の状態となります。

クエリ

no:size -ready:"Drop"

Product Backlog

PBIの一覧を表示します。優先順位順に並んでおり、プロダクトオーナーの合意の下で並び替えを行うことができます。

クエリ

is:open -no:size  -ready:"Drop"

Sprint Backlog

今スプリントの対象となっているPBIとその進行状況を表示します。

クエリ

sprint:this

レーン概要

statusカラムの値ごとに整理されます。

• TODO
  • 進行中ではないアイテムが並ぶ
• In Progress
  • 進行中のアイテムが並ぶ
  • WIPの制限
    • In Progressに置けるアイテムは1人1つまで
    • 別のアイテムに着手するときは着手済みであってもTODOに戻す
      • 参考: なぜWIPの制限が重要なのか
• In Review
  • レビュー待ちのアイテムが並ぶ
    • Pull Request (PR)等のレビュー依頼をしたらこのレーンに移動
    • レビューで修正依頼を受けたものに関してはIn ProgressもしくはTODOへ
• DONE
  • レビュー完了後のアイテムが並ぶ

Completed

完成したPBIをスプリント番号の降順で表示します。主に過去のPBIのふりかえり用です。

クエリ

is:closed -no:size  -ready:"Drop"

主な操作

PBI候補の新アイテムを登録する

When

• いつでも

Who

• だれでも

How

New Itemの「Start typing to…」左の+ボタンから登録します。

アイテムの実体はIssueです。タイトルはユーザーストーリー形式 (例: ゲストは記事に対してコメントを投稿できる) で書きます。 本文についてはテンプレート(※)に従って記入します。

起票後、Size以外のカラムに内容を設定します。 ReadyカラムのラベルがNotReadyである場合はReady条件/備考を記入します。

この時点では新規PBIはNew Itemにのみ表示されProduct Backlogには表示されません。

※ テンプレートはIssue Templateで使っていました。以下に例を示します。

## 概要
<!-- このPBIにおける主要な課題や機能、及び期待される成果について簡潔に説明してください。-->

### 何をやるのか

### なぜやるのか

## 受入条件
<!-- このPBIを完了とするための条件をリスト形式で記載してください。受け入れ条件は状態として記載します。-->
- [ ] 受入条件1
- [ ] 受入条件2

## タスク
<!-- 開発者がこのPBIを達成するために必要なタスク（具体的な作業項目）をリスト形式で記載してください。-->
- [ ] タスク1
- [ ] タスク2

## その他
<!-- このPBIに関連するドキュメント、過去の類似したPBI、注記や備考などをここに記載してください。-->

新アイテムをPBIとしてProduct Backlogに追加する

When

• リファインメント

Who

• 新アイテムの起票者
• リファインメントのファシリテーター

How

起票者が新アイテムの概要を説明、チーム全員で Sizeカラムに適切なラベルを検討、妥当な値を設定します。 Sizeが設定されると、New Itemに表示されなくなり、Product Backlogに表示されます。

プロダクトオーナーが優先順位に合わせてProduct Backlogの中での位置を決定します。

スプリント対象のPBIをSprint Backlogに追加する

When

• (原則) スプリントプランニング

Who

• プランニングのファシリテーター

How

Product BacklogのSprintカラムにthisのラベルを設定します。これによってSprint Backlogに表示されます(Product Backlogにも表示されたままになります)。

なお、スプリントプランニング以外のタイミングでSprint Backlogにアイテムを追加した場合(差し込み)は通常のアイテム追加と区別するためにLablesにAdditionalを追加していました。

完成したPBIをProduct Backlogから非表示にする

When

• スプリントレビューで対象PBIの完成判定が出た時

Who

• スプリントレビューのファシリテーター

How

Product BacklogのSprintカラムをスプリント番号のラベル (例: S1)に変更します。これによってSprint Backlogに表示されなくなります。

PBIの実体であるIssueをクローズします。これによってProduct Backlogにも表示されなくなり、Completed に表示されるようになります。

利用イメージ

以下のように利用していました。

朝会 (リファインメント + デイリースクラム)

• New Itemを確認
  • あれば起票者が内容を共有
  • チーム全員でサイズを見積り
  • プロダクトオーナーがProduct Backlogの任意の位置へ
• Product Backlogの優先順位に変化がないかの確認
• Sprint Backlogを確認して、相談事のあるなしを確認

スプリントプランニング

• プランニングに含めたいNew Itemがないかを確認
  • 基本的には朝会で確認だが急ぎのものがあれば
• Product Backlogの優先順位に変化がないかの確認
• Product Backlogの上から順にSprintカラムにthisをつけていく
  • いくつ取るかはチームのキャパシティ（可処分時間）と相談

セルフふりかえり

よかったポイント

• 元々の課題(背景参照)はどれも解決できた
  • 実際に新規メンバーが途中参画した際にもスムーズにオンボーディングできた
• テンプレートによってチーム全員がPBIを起票できるようになった
  • 特に完成の定義(受け入れ条件)を明文化し、チームの共通認識にできるようになったのは大きい
    • テンプレートに対してはPRを出せるので主体的に提案＆相談できる
  • プロダクトオーナーから「アジャイル・スクラムの思想に合うように、仕組みとして誘導できている」というフィードバックをいただけた
• GitHub Projectsの使用感
  • 前述のテンプレートやPRとの統合などが非常に便利だった
  • バックログの管理にGitHub Projectsを利用するのは初めての試みだった
    • これまではGoogle SpreadsheetやNotionなどを利用
      • 本プロジェクトではこれらのツールが利用できないという制約があった

改善したいポイント

• Sprint BacklogをPBI単位で扱っている
  • 1つのPBIに複数のPRが紐づくケースなどで透明性が下がる
    • PRがマージされた時にPBI(の実体であるIssue)がクローズされてしまうので手動再オープンが必要
      • 参考: Pull RequestをIssueにリンクする
  • もう1段階粒度を下げてタスクの単位で扱うべき？
    • ただし、チームの人数等の要素もあるので一概には言えなさそう
• 微妙に操作しづらい部分が残っている
  • ラベルの設定等でGitHubの特定の画面からでないと行えない操作など

おわりに

改めて言語化すると思ったよりも情報量が多くなりました。ただ、実際に触ってみるとやっていることはシンプルであることを感じていただけると思います。

今回の仕組みを作る過程で、社内の有識者たちから実践的なアドバイスを受けることができました。さらに、チームメンバーからの直接的なフィードバックも大きな助けとなりました。この場を借りて、関わってくださった方々に感謝します。

どなたかのバックログ管理の参考になれば幸いです。