スクラムでバックログをもっと活用してみる

スクラムのバックログ管理に迷っていたなら、具体案を通じて改善案の解像度を高くしてもらうことを目的とした資料。
チームでスクラムを導入してみたけど、上手く回せていない方にも参考になると思います。

ベストプラクティスなんて存在しないこのスクラム開発、バックログを通じてプロダクトをよりよいものにしていきましょう。

Transcript

1. バックログを もっと活用してみる バックログ管理の具体案を 課題から考える
2. このプレゼンのベネフィット • バックログの粒度がバラバラで管理できない状態から脱却できる • １つの具体案から運用方法を見つめ直すことができる • スクラムイベントを本質的に機能させることができる
3. 前提の考え方 - 人ではなく仕組みを変えていきたい - 今のやり方が「間違えている」ということはない - 当時は最適だったが、会社のフェーズが変わって合わなくなっただけかもしれない - スクラムを全て成功にするのは、ほぼ無理って思って良い - スクラムは「軽量」「理解は用意」 - でも「習得は困難」 - スクラムを突き詰めて人生かけた人が諦めたという話もある - スクラムいず正義ではない - スクラムマスターはスクラムを辞める選択を提案することもある - 正解はない - これまでわたしが関わったチーム単位で全てイベントの手法が違っていた - メンバー１人変われば最適解は変わると思って良い
4. スプリント活動における課題例
5. スプリントの考え方 • タイムボックスの中で検査と適応を行い、コストや労力のリスクを短い 時間の中に収める • プロダクトゴールの達成を常に目指している ◦ プロダクトゴールはプロダクトの将来の状態みたいなイメージ。長期的な目標 • プロダクトの品質を低下させない ◦ プロダクトゴールを危険に晒すような変更はしない • 経験主義で将来に見据えた意思決定を行う ◦ 意思決定に使用できるのはすでに発生したことだけ
6. スプリントの考え方 • タイムボックスの中で検査と適応を行い、コストや労力のリスクを短い 時間の中に収める • プロダクトゴールの達成を常に目指している ◦ プロダクトゴールはプロダクトの将来の状態みたいなイメージ。長期的な目標 • プロダクトの品質を低下させない ◦ プロダクトゴールを危険に晒すような変更はしない ◦ スプリントの前と後で品質は低下していない • 経験主義で将来に見据えた意思決定を行う ◦ 意思決定に使用できるのはすでに発生したことだけ スクラムイベント周期の中で検査と適応を行えるタイムボックスは「毎日」と「スプリント全体」。 【毎日】 ・Dailyで計画の調整は全員でできている？ 【スプリント全体】 ・レトロスペクティブでコストや労力のリスクについて話し合えてる？
7. スプリントの考え方 • タイムボックスの中で検査と適応を行い、コストや労力のリスクを短い 時間の中に収める • プロダクトゴールの達成を常に目指している ◦ プロダクトゴールはプロダクトの将来の状態みたいなイメージ。長期的な目標 • プロダクトの品質を低下させない ◦ プロダクトゴールを危険に晒すような変更はしない • 経験主義で将来に見据えた意思決定を行う ◦ 意思決定に使用できるのはすでに発生したことだけ ・プロダクトゴールが分かるようなアイテムはある？ ・PO（やデザイナー）・開発者間でゴール（細かくいうと仕様）の認識は合ってる？
8. スプリントの考え方 • タイムボックスの中で検査と適応を行い、コストや労力のリスクを短い 時間の中に収める • プロダクトゴールの達成を常に目指している ◦ プロダクトゴールはプロダクトの将来の状態みたいなイメージ。長期的な目標 • プロダクトの品質を低下させない ◦ プロダクトゴールを危険に晒すような変更はしない • 経験主義で将来に見据えた意思決定を行う ◦ 意思決定に使用できるのはすでに発生したことだけ ・品質はスプリントの前と後で低下していないと言える？
9. スプリントの考え方 • タイムボックスの中で検査と適応を行い、コストや労力のリスクを短い 時間の中に収める • プロダクトゴールの達成を常に目指している ◦ プロダクトゴールはプロダクトの将来の状態みたいなイメージ。長期的な目標 • プロダクトの品質を低下させない ◦ プロダクトゴールを危険に晒すような変更はしない • 経験主義で将来に見据えた意思決定を行う ◦ 意思決定に使用できるのはすでに発生したことだけ ・意思決定が上司依存になっていない？ ・意思決定が先輩依存になっていない？
10. まとめ（課題の羅列） • Dailyで計画の調整は全員でできてる？ • レトロスペクティブでコストや労力について話し合えてる？ • プロダクトゴールがわかるようなアイテムはある？ • PO（やデザイナー）・開発者間でゴール（細かくいうと仕様）の認識は 合ってる？ • 品質はスプリントの前と後で低下していないと言える？ • 意思決定が上司依存になってない？ • 意思決定が先輩依存になってない？
11. 具体的な案
12. このあたりに効果ありそうな具体案 • Dailyで計画の調整は全員でできてる？ • レトロスペクティブでコストや労力について話し合えてる？ • プロダクトゴールがわかるようなアイテムはある？ • PO（やデザイナー）・開発者間でゴール（細かくいうと仕様）の認識は合ってる？ • 品質はスプリントの前と後で低下していないと言える？ • 意思決定が上司依存になってない？ • 意思決定が先輩依存になってない？ 逆にいうと、今回の案には枠外 の解決は含まれていません （１歩ずつ解決しましょう）
13. スクラムイベントのあるある • デイリースクラム ◦ バックログ見ながらやったことを発表するだけになっている • スプリントレビュー ◦ バックログで終わったよねを発表するだけになっている • レトロスペクティブ ◦ 本当に改善されているか分からない • プランニング ◦ バックログで取れそうなものをリーダーが取るだけになっている • リファインメント ◦ やってない
14. バックログのあるある • バックログの全容を把握できている人がいない • POが優先判断できないバックログアイテムがある • バックログアイテム見てもやることが分からないものがある • 重さもわからない、またはかかりそうな日数だけがリーダーの主観で書かれている
15. バックログのあるある • バックログの全容を把握できている人がいない • POが優先判断できないバックログアイテムがある • バックログアイテム見てもやることが分からないものがある • 重さもわからない、またはかかりそうな日数だけがリーダーの主観で書かれている 以上のあるあるを想定して 改善案出しをしてみます
16. 具体案の概要 【スクラムイベント】 • デイリースクラム • スプリントレビュー • レトロスペクティブ • プランニング 【スクラムの成果物】 • バックログ ◦ 個人のタスクベース • プロダクト（インクリメント） 【スクラムイベント】 • デイリースクラム • スプリントレビュー • レトロスペクティブ • プランニング • リファイメント 【スクラムの成果物】 • プロダクトバックログ ◦ ストーリーベース • スプリントバックログ ◦ 個人のタスクベース • プロダクト（インクリメント） 想定される現状 案 リファイメント を しっかり やりませんか バックログ（チケッ ト）の活用方法を 見直しませんか
17. バックログの活用について 【スクラムイベント】 • デイリースクラム • スプリントレビュー • レトロスペクティブ • プランニング 【スクラムの成果物】 • バックログ ◦ 個人のタスクベース • プロダクト（インクリメント） 【スクラムイベント】 • デイリースクラム • スプリントレビュー • レトロスペクティブ • プランニング • リファイメント 【スクラムの成果物】 • プロダクトバックログ ◦ ストーリーベース • スプリントバックログ ◦ 個人のタスクベース • プロダクト（インクリメント） 想定される現状 案
18. PO・開発者のプロダクトへの触れ方 PO 開発者 プロダクト インクリメント （ソース） バックログ 見てる景色が異なる ・プロダクトの価値を最大化 ・これから価値をどう上げるか ・どうやって品質を上げていくか ・メンテナンス性、可用性・・・ • POと開発者のずれはこういうところから起こる（それは別に悪くない） • しっかり認識を合わせ、お互い納得感を持ちながらプロダクトを良くしたい
19. 【成果物】バックログを分けて考える プロダクト バックログ スプリント バックログ • プロダクトに必要なものの一覧 • 優先順位で並ぶ • 永遠に完成しない • スプリントでやることの一覧 • 開発者のためのツール • デイリーで検査する PO 開発者 インクリメント （ソース）
20. バックログの分け方あるある プロダクト バックログ スプリント バックログ • プロダクトに必要なものの一覧 • 優先順位で並ぶ • 永遠に完成しない • スプリントでやることの一覧 • 開発者のためのツール • デイリーで検査する ◯◯を作る by 誰々 ◯◯を作る by 誰々 スプリントA 現状 タスク タスク スプリント情報 をつけるだけ
21. プロダクトバックログ管理の変更点 プロダクト バックログ スプリント バックログ • プロダクトに必要なものの一覧 • 優先順位で並ぶ • 永遠に完成しない • スプリントでやることの一覧 • 開発者のためのツール • デイリーで検査する ◯◯を作る by 誰々 ◯◯を作る by 誰々 スプリントA 現状 案 ◯◯をできるようにする ◯◯をできるようにする スプリントA ◯◯を作る by 誰々 タスク タスク タスク ストーリー ストーリー プロダクトバックログは 基本ストーリーで管理 スプリントバックログで 初めてタスクが出てくる
22. ストーリーチケットで解決したいこと • PO観点 ◦ バックログで優先順位を並べ替えられる単位にする ◦ 並べ替えが行うために必要な情報が揃っているようにする • 開発者 ◦ アウトカムベースでPOやデザイナーと仕様の認識を揃える ◦ チケットの完了の条件を知る ◦ 着手する時に全体感を持つ
23. ストーリーチケットに記載すること（の例） 【記載項目】 • 背景 • 受け入れ条件 （確約：完成の定義） • ストーリーポイント （フィボナッチ数） • メモ （ポイントをつけるために必要なこと） 【具体例】 拠点の人数情報を手動入力で登録できるようにする • 背景 ◦ 拠点の人数を画面から登録する導線を確保して可用性を上げたい • 受け入れ条件 ◦ figmaと画面イメージが同じ ▪ figmaのURL：＊＊＊ ◦ モーダルで登録 ▪ モーダル枠外でクリックで消える ◦ 登録項目 ▪ 拠点 • オートコンプリートを利用 • 必須 ▪ 人数 • 必須 • 数値のみ • 0を含む整数を登録 • 上限値は10000 ◦ dev環境で動作を確認 • メモ ◦ やること ▪ モーダルは新規作成が必要 ▪ APIは1つ追加 ▪ オートコンプリートを少し変更 ◦ zodを利用する ◦ 既存のオートコンプリートに影響ないか確認 • ストーリーポイント：3
24. で、これは 誰がいつ こんな詳細に 書くの？？
25. リファイメントでみんなでやりませんか 【スクラムイベント】 • デイリースクラム • スプリントレビュー • レトロスペクティブ • プランニング 【スクラムの成果物】 • バックログ ◦ 個人のタスクベース • プロダクト（インクリメント） 【スクラムイベント】 • デイリースクラム • スプリントレビュー • レトロスペクティブ • プランニング • リファイメント 【スクラムの成果物】 • プロダクトバックログ ◦ ストーリーベース • スプリントバックログ ◦ 個人のタスクベース • プロダクト（インクリメント） 現状 案
26. リファイメントの目的 • プロダクトバックログを全員でメンテナンスする機会を意図的に作る ◦ POだけではなく、開発者側もプロダクトバックログを意識する効果を期待 • ストーリーチケットの詳細を詰める ◦ 詰めきれていない仕様の発見を期待 ◦ 仕様の認識を合わせて手戻りを減らす効果を期待 ◦ バックエンドとフロントエンドの認識を揃える効果を期待 • ストーリーチケットについて理解する ◦ PO・デザイナー・エンジニアの理解レベルを合わせる効果を期待
27. 1. チケットの説明を行う 2. ポイントをつけるために必要な疑問をその場で話し合う a. 実装の細かいところまでは不要だが、実装方針によって工数が明らかに異な るなら話し合う 3. 必要事項をチケットに記載する 4. 参加可能なメンバー全員でポイントをつける a. ここで認識がずれているとメンバー間でポイントがずれるので、認識が合うま で話し合う b. 1つ分の差分は大した差ではない（2と3、3と5など） c. 一定より多いポイントとなった場合はチケットを分割を検討する • チケットをピックアップ • チケットについて説明でき る状態にする • 必要なメンバーを召集 ◦ 全員参加の必要はない ◦ 頻度はスプリントに1回 以上を目安 • 3ポイントとなるチケットを 決めてポイント感を決める リファイメントの流れ 事前準備 リファイメント
28. 実際の流れを見ながらまとめ
29. スプリント バックログ スプリントの流れ（今まで） プランニング 開発作業 レビュー レトロ プロダクト バックログ タスクA タスクB タスクA PO 開発者
30. スプリント バックログ スプリントの流れ（今まで） プランニング 開発作業 レビュー レトロ プロダクト バックログ タスクB タスクC タスクA Dailyで検査をしながら実装 PO 開発者 PO バックログのメンテナンス
31. スプリント バックログ スプリントの流れ（今まで） プランニング 開発作業 レビュー レトロ プロダクト バックログ タスクB タスクC タスクA タスクA終わってヨシッ PO 開発者
32. スプリント バックログ （チームA） スプリント バックログ （チームB） スプリントの流れ（案ベース） プランニング 開発作業 レビュー レトロ プロダクト バックログ ストーリーA ストーリーB ストーリーA ストーリーB
33. スプリント バックログ （チームA） スプリント バックログ （チームB） スプリントの流れ（案ベース） プランニング 開発作業 レビュー レトロ プロダクト バックログ ストーリーA ストーリーB タスクA タスクA タスクB ストーリーから各チームでタスクを切ります。 これはリファインメントで事前にやっていても OKで す プランニング （各チーム） new
34. スプリント バックログ （チームA） スプリント バックログ （チームB） スプリントの流れ（案ベース） プランニング 開発作業 レビュー レトロ プロダクト バックログ ストーリーA ストーリーB タスクA サブタスクA サブタスクA プランニング （各チーム） Dailyで検査をしながら実装 バックログのメンテナンス ストーリーC
35. スプリント バックログ （チームA） スプリント バックログ （チームB） スプリントの流れ（案ベース） プランニング 開発作業 レビュー レトロ プロダクト バックログ ストーリーA ストーリーB タスクA タスクA タスクB プランニング （各チーム） バックログのメンテナンス ポイント付け ストーリーC ストーリーD new リファイメント 不定期イベント
36. スプリント バックログ （チームA） スプリント バックログ （チームB） スプリントの流れ（案ベース） プランニング 開発作業 レビュー レトロ プロダクト バックログ ストーリーA ストーリーB タスクA タスクA タスクB プランニング （各チーム） バックログのメンテナンス ポイント付け ストーリーC ストーリーD new リファイメント 不定期イベント リファインメント対象チケットは 「ストーリー単位」「タスク単位」 どちらでも良いですが、どちらかに揃えてくだださい
37. スプリント バックログ （チームA） スプリント バックログ （チームB） スプリントの流れ（案ベース） プランニング 開発作業 レビュー レトロ プロダクト バックログ ストーリーA ストーリーB タスクA タスクA タスクB プランニング （各チーム） ストーリーC ストーリーD リファイメント ストーリーAは終わってヨシっ ストーリーBは未完了なので次もよろ
38. まとめ • バックログを２つ使い分けたい ◦ プロダクトバックログ ▪ POの持ち物 ▪ ストーリーベース ◦ スプリントバックログ ▪ 開発者（チーム）の持ち物 ▪ ストーリーからのタスクベース • リファイメントを行いたい ◦ プロダクトバックログに 全員で向き合う時間 ◦ お互いの理解度を深めたい