はじめに
COSOJIプロダクト開発部PdM 荻野です。
スクラム開発において、バックログのチケット管理は非常に重要と考えています。チケットの中身次第でチームの生産性や品質に影響すると考えているためです。私たちのチームでは最近、開発バックログのチケットフォーマットをリニューアルしました。この記事では、その経験と得られた成果について共有します。
バックログのチケットフォーマットリニューアルの背景
私たちが直面していた主な問題点として以下がありました。
- チケットに記載されたタスクが走り書き状態で、誰の何の課題を解決するもの(Why)か整理されていないことがあった。
- Slackやミーティングでの議論内容がチケットに転記されていましたが、起票時の走り書き状態の部分に追記されるため、内容が読みづらい。
これらの問題により、チームメンバーがタスクの目的や重要性を理解しづらく、効率的な開発が阻害されていました。
参考：Whyから始めよ
なぜ「Why」が整理されていないといけないのか、なぜ「Why」からなのかは、サイモン・シネック氏が解説しているted動画が有名ですよね。
バックログを書くときのガイドライン
有名なガイドラインとして、INVESTというものがあります。これらを意識する必要があります。
- Independent：他のアイテムと独立していること
- Negotiatable：詳細は実装時に交渉、調整可能であること
- Valuable：顧客や利用者にとって、価値があること
- Estimable：作業量が見積もり可能であること
- Size right / Small：一つのスプリントで完結できること
- Testable：受け入れ基準が明確でテスト可能であること
リニューアルにあたって重視したポイント
上記も踏まえつつ、フォーマットをリニューアルするにあたり、以下の点を重視しました。
- Whyの明確化：誰の何の課題を解決するものかを必ず含めることにしました。なぜならば、Whyによって、What（何をやるのか）とHow（どのようにするのか）が影響を受けるからです。
- 情報の整理: 決定済みの仕様と、打ち合わせで議論した内容を明確に区別して記載するようにしました。これにより、必要な情報を素早く見つけられるようにしました。
新しいチケットフォーマット
リニューアルの結果、以下のような項目を採用しました。
- チケット名：「〇〇は、〇〇することができる。」の形式で記述
- エピック： ユーザーのどのフェーズに該当するかをラベル付け
- ユーザーストーリー：「〇〇は、〇〇することができる。（What）なぜならば、〇〇は〇〇だからだ。（Why）」の形式で記述
- DoR（Definition of Ready）: 開発着手するまでに必要なこと
- 各チケット固定で以下を入れました。
- 仕様が決まっていること
- デザインが必要な場合はデザインが確定できていること
- ユーザーストーリーの価値を把握した上で、記載されているACをもとに見積もりができていること
- 8ポイント以上の場合は分割できていること（実績との乖離が発生してしまうためです。）
- 各チケット固定で以下を入れました。
- AC（Acceptance Criteria）: 決定済みの仕様のみを記載（仕様が決まる過程はここに書かないことを徹底。）
- 備考: 見積もり時や仕様検討会での議論内容を記載（ACに至った経緯や没になった案も含む）
- 関連リンク: デザインリンクなど
- 見積もりポイント
- 優先度: RICEモデルに基づいた数値を記載（別の記事で詳細を記載をします。）
その他、担当者などの項目もありますが、割愛します。
実際の例
- チケット名：COSOJI依頼者は、新規募集登録の際、物件選択項目にて自由入力で物件を検索することができる。
- エピック：bb-1.案件登録
- 内容
- COSOJI依頼者は、新規募集登録の際、物件選択項目にて自由入力で物件を検索するができる。なぜならば、登録物件数が多いCOSOJI依頼者は、物件選択式だと、設定したい物件を見つけるのに、時間がかかり、不便だからだ。
- DoR
- 仕様が決まっていること
- デザインが必要な場合はデザインが確定できていること
- ユーザーストーリーの価値を把握した上で、記載されているACをもとに見積もりができていること
- 8ポイント以上の場合は分割できていること
- AC
- 依頼者は、物件の検索ができること
- ①〇〇を押下すると、物件検索モーダルが出てくること
- 検索ボックス、新規登録、既に登録されている物件が表示されていること
- 新規登録ボタンはスクロールできないこと
- バツボタンを押下すると、モーダルが閉じられること
- ②検索ボックスに検索KWを入力して、検索結果が表示されること
- 新規登録ボタンは非表示になっていること
- 最大５件まで表示されていること
- 「関連順に最大5件まで表示しています。」と表示されること
- 検索入力欄「×」を押下すると①の状態にもどること
- ヒットしない場合は「該当する物件が見つかりませんでした。」が表示されること
- 依頼者は、従来通り、物件の選択もできること
- ①〇〇を押下すると、物件検索モーダルが出てくること
- 依頼者は、物件の検索ができること
- 備考
- 背景
- 課題：物件が200件以上の事業者が多くおり、その事業者が物件を選択するのに時間がかかっているという声が上がっている
- 打ち手：時間の短縮を図るための改善を行う
- 打ち手の策：検索機能をつける
- 背景
運用後のチームの変化
新しいフォーマットの導入後、開発チームに以下のような声が挙げられました。
- タスクの目的が明確になり、Whyを念頭に考えやすく、動きやすい。
- チケットだけで仕様が理解できるようになり、デザインの補足情報に頼る必要がなくなった。
- チケット記載のACを使って、開発したものの漏れをしっかりチェックできるようになりました。
最後に
バックログのチケットフォーマットをリニューアルすることで、チームの効率と理解度が大幅に向上しました。特に、Whyを明確にすることと、情報を整理して記載することが重要でした。
スクラム開発に携わる皆さんも、自分たちのチームに合ったチケットフォーマットを検討してみてはいかがでしょうか？効果的なフォーマットは、チームの生産性と品質の向上につながります。
Discussion