初心者スクラムチームが陥っていた間違ったスクラムの見積もり方法とそれに対するカイゼン

Transcript

1. 　　　　　　 © Chatwork 2022年10月01日　やまごん(Yamagoshi Tomonori) XP祭り2022 初心者スクラムチームが陥っていた 間違ったスクラムの見積もり方法と それに対するカイゼン
2. まず だれやねん 2 2020年 8月 　　　　　　　　　　　　にJoin 2020年 8月末 Team SuperNovaを結成 （なんちゃってスクラム開始） 2021年 1月 チームメンバーが3人→2人に （スクラムマスター不在） 2022年 3月 メンバー再編のタイミングで スクラムマスターをすることに（兼任） 2022年4月 認定スクラムマスター取得 やまごん (Yamagoshi Tomonori) Chatwork株式会社 サーバーサイド開発部(PHP) Team SuperNova スクラムマスター 兼 開発者
3. スクラムにおける見積もりって？ スクラム初心者のやりがちな見積もり 間違った見積もり方法とカイゼン点 スプリントプランニング 最後に 1 2 3 4 5 AGENDA アジェンダ
4. 本編 1
5. 5 さて
6. 6 今回の発表内容
7. 7 間違ったスクラムの 見積もり方法と それに対するカイゼン
8. 8 に入る前に
9. 9 スクラムを知らない方 向けに スクラムについて軽く説明
10. スクラム開発とは 10 プロダクト開発におけるスクラム（英: Scrum）は複雑な問題への適応型ソリューションをチームで開発し価値を生み出すた めの軽量級フレームワークである ◦概要 複雑な問題に対する完璧なソリューションを1度で実現することは難しい。異なるアプローチとして、不完全なソリューショ ンを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従う べき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その 目的は開発したソリューションを介して価値を生み出すことである。 スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰 り返し」を実現できる環境を生み出すシンプルなアプローチである[2]。スクラムのカギとなる基本原則は、プロジェクト開 発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処 することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定 義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプロー チである。 スクラムはチームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメン バーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケー ションをとり、プロジェクトにおける規律を守ることである。 ◦背景 複雑な問題と適応型ソリューション 複雑な問題は難しい。もし1回で問題への完璧な解決策/ソリューションを提供できれば大きな価値を提供できる。しかし「完 璧に計画されたソリューション」は往々にして不完全に終わる。そうでないやり方の1つが適応型ソリューション（英: adaptive solutions）である。すなわち最初は不完全だが段階的に学び改善されていくソリューションである。 ソリューション開発と目的 wikipedia から引用
11. 11 ❓
12. 12 つまりは
13. 13 最近イケてる アジャイル開発の方法
14. 14 現在Chatwork社が 全社的に”推し”進めている 開発手法でもある
15. 15 そのスクラムをやるために 必要な役割について説明
16. 16 【スクラムチーム】 開発者 プロダクトオーナー スクラムマスター で構成される ざっくり説明
17. 【開発者】 実際に使える成果物を作ることに 責任を持つ 17 ざっくり説明 実際に開発してモノをつくるよ 作る予定をしているモノの 見積もりもするよ
18. 18 【プロダクトオーナー】 スクラムチームから生み出される モノの価値の最大化に責任 ざっくり説明 どんな価値を提供するか考える よ プロダクトゴールを見据えて、 作るモノの優先度も考える よ
19. 19 【スクラムマスター】 スクラムの理解と実践を推進し、 プロジェクトを円滑に進めることに 責任を持つ ざっくり説明 スクラムチームがスクラムでの 開発に集中できるように障害を取り除く よ チームをコーチングしたりする よ
20. 20 スクラムはいくつかの スクラムイベントで 構成されるフレームワーク
21. 21 スクラムイベントの1つで 作業の見積もりをするのが スプリントプランニング
22. 22 スプリントプランニングに ついても軽く説明
23. スプリントプランニングとは 23 スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計 画を⽴てる。結果としてできる 計画は、スクラムチーム全体の共同作業によって作成される。 プロダクトオーナーは参加者に対して、最も重要なプロダクト バックログアイテムと、それら とプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチ ームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよ い。 スプリントプランニング は次のトピックに対応する： トピック 1：このスプリントはなぜ価値があるのか？ プロダクトオーナーは、プロダクトの価 値と有⽤性を今回のスプリントでどのように⾼めるこ とができるかを提案する。次に、スクラムチーム全体が協⼒して、その スプリントになぜ価値 があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、ス プリン トプランニングの終了までに確定する必要がある。 トピック 2：このスプリントで何ができるのか？ 開発者は、プロダクト オーナーとの話し合いを通じて、プロダクトバックログからアイテムを 選択し、今回のスプリントに含める。スクラムチーム は、このプロセスの中でプロダクトバッ クログアイテムのリファインメントをする場合がある。それによって、チームの理解 と⾃信が ⾼まる。 10 スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、 開発者が 過去の⾃分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を 深めていけば、スプリントの予測に⾃信 が持てるようになる。 トピック 3：選択した作業をどのように成し遂げるのか？ 開発者は、選択したプロダクトバックログ アイテムごとに、完成の定義を満たすインクリメン トを作成するために必要な作業を計画する。これは多くの場合、プロダク トバックログアイテ ムを 1 ⽇以内の⼩さな作業アイテムに分解することによって⾏われる。これをどのように⾏う かは、開 発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変 換する⽅法は誰も教えてくれない。 ス スクラムガイド2020より引用
24. 24 ❓
25. 25 つまりは part2
26. 26 スプリント期間中(1週間とか)に やりきりたいこと(PBI)を 作業単位にして見積もり 本当にスプリントに収まるか 計画するイベント
27. プロダクトバックログアイテム(PBI) →ユーザーに価値を届けられる単位で用意された ユーザーストーリー（チケット） 27 用語の補足
28. 28 なるほど! スプリント内でやることを 見積もればいいのか！ 当時のぼくたちのちーむ
29. 29 スクラムの見積もりを 早速やってみよう！
30. 30 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする まず見積もるために やらなきゃいけないチケッ トを切って・・・ これでプロダクトバックロ グアイテム(PBI)とやらが できたぞ！ 開発者 ↓PBI(プロダクトバックログアイテム）
31. 31 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする ふむふむ スクラムのPBIは SP（ストーリーポイント） っていう相対見積もりを使 うらしい ?SP 開発者 ↓PBI(プロダクトバックログアイテム） ?SP ?SP ?SP ?SP
32. 32 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする 最初は比較に使う実績が あるPBIがないから、 一番小さいのと大きそうな PBIにSPを決め打ちするら しい・・・ ?SP 開発者 ↓PBI(プロダクトバックログアイテム） ?SP ?SP ?SP ?SP
33. 33 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする よし！それぞれ 5SP 1SP ってつけてみたぞ！ 5SP 1SP 開発者 ↓PBI(プロダクトバックログアイテム）
34. 34 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする 相対的に見て こんな感じかな？ 5SP 1SP 1SP 3SP 4SP 開発者 ↓PBI
35. 35 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする よし！ スプリントやってくぞ！ 5SP 1SP 1SP 3SP 4SP 開発者 ↓PBI
36. 36 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする 相対的に見て こんな感じかな？ 5SP 1SP 1SP 3SP 4SP 開発者 ↓PBI 〜何スプリントか経過した後〜

37. 37 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする 次のスプリントだ！ スプリントプランニングを するぞ！ Aの実装する Aのドキュメントを更新 1SP 4SP 開発者 ↓PBI
38. 38 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする この前実装したAのときは 4SPは2日ぐらいかかって、 1SPは半日ぐらいかかった から・・・ Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI
39. 39 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいかかりそうだから 5SP！ Aの実装する Aのドキュメントを更新 1SP 4SP 10SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI 5SP
40. 40 Bの設計をする バックログ スプリント2 Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP スクラムな見積もりじゃない 開発者 2日ぐらいかかった 半日ぐらいかかった ↓PBI 10SP 5SP 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいかかりそうだから 5SP！
41. 41 どこがスクラムな見積もり じゃない？
42. 42 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいだから 5SP！ Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 どこが問題でしょうか？ ↓PBI 10SP 5SP
43. 43 パッと見ただけで わかる問題が5つ
44. 44 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいだから 5SP！ 10SP 5SP 見積もりがSPといいつつ ただの工数見積になっている
45. 45 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 5SP 見積もりがSPといいつつ ただの工数見積になっている 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいだから 5SP！ 10SP
46. 46 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 5SP 見積もりがSPといいつつ ただの工数見積になっている 1SPが半日規模と大きすぎる 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいだから 5SP！ 10SP
47. 47 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 見積もった結果、SPが大きかっ たのに分割していない 5SP 見積もりがSPといいつつ ただの工数見積になっている 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいだから 5SP！ 10SP 1SPが半日規模と大きすぎる
48. 48 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 見積もった結果、SPが大きかっ たのに分割していない 5SP PBIなのに【開発者】が チケットを作成している 見積もりがSPといいつつ ただの工数見積になっている 1SPが半日規模と大きすぎる 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいだから 5SP！ 10SP
49. 49 これらの5つの問題があった
50. 50 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 見積もった結果、SPが大きかっ たのに分割していない PBIなのに【開発者】が チケットを作成している 5SP 見積もりがSPといいつつ ただの工数見積になっている 1SPが半日規模と大きすぎる 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいだから 5SP！ 10SP
51. 51 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする 今回のBの実装は 3日ぐらいかかりそうだから 6SPだ！ テストは 2日半ぐらいだから 5SP！ Aの実装する Aのドキュメントを更新 1SP 4SP 6SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 見積もった結果、SPが大きかっ たのに分割していない PBIなのに【開発者】が チケットを作成している 見積もりがSPといいつつ ただの工数見積になっている 1SPが半日規模と大きすぎる それぞれにどうやって
 アプローチすべき？

52. ◦なぜ問題なのか？ SP(ストーリーポイント)は他のPBIとの相対見積もりをすることでPBIの大まかな規模感 を【バックログリファインメント】で見積もるためのもの それなのに 0.5日 = 1SP という工数をもとにした計算方法で見積もってしまっているこ とが問題である。 ①見積もりがSPといいつつただの工数見積になっている 52
53. ①見積もりがSPといいつつただの工数見積になっている 53 　改善のためのアプローチ 実際に達成したPBIに掛かった時間にとらわれず、規模感・大きさでPBIを比較して ざっくりで見積もることが大事。 SP(ストーリーポイント)は多少実績とずれても別に問題ないゆるい見積もりだと思うこと。 他の意見を聞くと流されたり影響を受けてしまうため、 【プランニングポーカー】という決定方法で、一斉に各メンバーが思った数字をあげ、最低点 と最高点の人がなぜそうおもったか発表して、再び数字を上げる、といった方式を取ることが 多いとされる。 選ぶ数字はフィボナッチ数列(1,2,3,5,8,13…)の値から選ぶ場合が多い 参考： Q. プロダクトバックログの見積りについて、規模や工数を算出する時にどんな方法を使えばいいですか？
54. ◦なぜ問題なのか？ PBI(プロダクトバックログアイテム) とは、 プロダクトの価値を向上させるためのユーザーストー リーであるため、 PBIが一つ達成された時にプロダクトの価値が向上し ているようなものでなければならない 現在のチケットは 作業レイヤーでチケットが別れてしまっているため、 ウォーターフォール的な区切り方になっていることが 問題となっている。 ②やること単位でチケット(PBI)を切ってしまっている 54
55. 　改善のためのアプローチ ユーザーストーリーとして、単体で価値提供できる粒度でチ ケット(PBI)を作成をする。 例えばコンタクト追加機能を提供したい場合 ①別のユーザーに対してコンタクト申請を送ることができる ②送られてきたコンタクト申請を申請中の一覧として確認できる ③送られてきたコンタクト申請を拒否できる ④別のユーザーに対して送ったコンタクト申請をキャンセルできる ⑤送られてきたコンタクト申請を許可する ⑥申請を許可したユーザーがコンタクト一覧で確認できる といった様に、単体で価値が提供できる単位になっているとよい ②やること単位でチケット(PBI)を切ってしまっている 55 参考：Q. プロダクトバックログアイテムの分割の指針について教えてください
56. ③1SPが半日規模と大きすぎる 56 ◦なぜ問題なのか？ 1SPが大きすぎると、SPで見積もった場合の誤差が発生しやすくなってしまうため、 相対比較の精度がかなり低下してしまうため 今回の例でいうと、SPの最小単位が半日規模だと 見積もった時に 0.2SP などが生まれてしまう可能性があったり、同じ[2SP]とつけたPBI の中でも、[1SPよりの2SP]と[3SPよりの2SP]などで誤差が大きくなってしまう
57. ③1SPが半日規模と大きすぎる 57 　改善のためのアプローチ 前提として 1SP が何時間などとSPを具体的な時間などは照らし合わせてはいけない そして半日よりもっと少ない規模感で終わったPBIを1SPとして、 新たにSPを見積もる前に基準を修正してから見積もる。 そうすることで、ベロシティの制度や見積もりの精度も高まり、見積もった時にSPが大 きくなった場合分割しよう、という動きに繋がりやすくなる。
58. ◦なぜ問題なのか？ 何度かスプリントを回すことで、1スプリントで一体いくつのSPが達成できるかが ベロシティという形で見えてくる そのベロシティが例えば 8SPだった場合 このBの実装をするというPBIは絶対に1ス プリントでは完了しない そうなるとそもそもスプリントに組み込むことができないことになってしまう ④見積もった結果、SPが大きかったのに分割していない 58
59. 　改善のためのアプローチ PBIの大きさは細かくできるのであれば細かいほどよいとされているが、 最大でも1スプリント内で終わるサイズにすべきなので、見積もった結果大きいPBIだと判明した場合 は分割する必要がある。 例として【①別のユーザーに対してコンタクト申請を送ることができる】が2スプリントにまたいで しまうサイズだった場合、以下のように分割することが可能 1. コンタクト申請を送信するユーザーを検索、指定ができる 2. 選択したユーザーがコンタクト申請が可能であることを確認した上でコンタクト申請メールを送信する 3. コンタクト済み・申請済みのアカウントが表示・指定出来ないようにする ..etc ④見積もった結果、SPが大きかったのに分割していない 59 参考1：Q. プロダクトバックログアイテムの分割の指針について教えてください 参考2：Q. 1つのプロダクトバックログアイテムが大きくて1スプリントでは作れません。複数スプリントにまたいで開発していいですか？
60. ⑤PBIなのに【開発者】がチケットを作成している 60 ◦なぜ問題なのか？ PBI(プロダクトバックログアイテム)はPOの持ち物なので、 勝手に開発者が作成したり変更してはいけないため
61. ⑤PBIなのに【開発者】がチケットを作成している 61 　改善のためのアプローチ PBIはPOが管理しているので、開発者はPOとの合意がない場合は勝手に作成・並び替えしたりしな いこと バックログリファインメントでPOの合意の上で操作するのは問題ない。また、スクラムメンバーと してPBIへの意見や提案を行うのはより良いインクリメントを出す上で効果があるので、POと開発者 は積極的に話し合うとよいでしょう Q : POがいない場合 → POがいないとスクラムではないので、POを連れてきましょう Q2 : POが忙しい場合 → 忙しくてバックログリファインメントやPBIを作れない人はPOじゃないのでPOを連れてきましょう
62. 62 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 見積もった結果、SPが大きかっ たのに分割していない PBIなのに【開発者】が チケットを作成している 5SP 見積もりがSPといいつつ ただの工数見積になっている 1SPが半日規模と大きすぎる 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ！ テストは 2日半ぐらいだから 5SP！ 10SP
63. 63 さて
64. 64 お気づきの方もいるかも 知れませんが
65. 65 ここまで スプリントプランニング での見積もりの話 ではありませんでした
66. 66 実は全て バックログリファインメント での見積もりの話(PBI)
67. 67 スクラムイベントで 見積もりって実は２回ある
68. 68 スプリント期間中(1週間とか)に やりきりたいこと(PBI)を 作業単位にして見積もり 本当にスプリントに収まるか 計画するイベント バックログリファインメント スプリントプランニング 見積もりして 更に
69. 69 スクラム初心者は 見積もりって一回だと勘違い しちゃう 69
70. 70 バックログリファインメント →POがチケット(PBI)の 優先度を決める →SPでざっくりPBIを見積もって その規模感と顧客価値を元に POが優先度判断する 誤解していた イベントへの認識
71. 71 スプリントプランニング →スプリント期間中に どこまでのPBIができるか計画する →見積もっておいたPBIが 次スプリントに収まるかを開発者が 自分達のために作業アイテムにした上で 具体的な時間で計画する 誤解していた イベントへの認識
72. 72 アプローチのまとめ
73. 73 バックログリファインメント で作るPBIは気をつけよう
74. [1] 見積もりがSPといいつつただの工数見積もりになっている 　→実際に掛かった時間は一切無視！あくまでやってみた感覚の規模感で相対比較してつけること！ [2] やること単位でチケット(PBI)を切ってしまっている 　→単体でリリースされたとしてもプロダクトとして価値を提供できる単位でPBIを作成すること！ [3] 1SPが半日規模と大きすぎる 　→SPの最小単位を見直そう！ユーザーに価値提供できるPBIで一番小さいものを原基として基準にしよう！ [4] 見積もった結果、SPが大きかったのに分割していない 　→スプリントに収まらない大きさのPBIは分割しよう！分割する時も価値を与える単位でできるだけ小さく！ [5] PBIなのに【開発者】がチケットを作成している 　→PBIを管理するのはプロダクトオーナー！ただし開発者も意見などを出して改善しよう! バックログリファインメント&PBIの注意点まとめ 74
75. 75 注意点を踏まえた バックログリファインメント はこんなイメージ
76. 開発者 76 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている ↓PBI(プロダクトバックログアイテム） プロダクトオーナー バックログリファインメントを開始 します。 PBIを3件追加しました まず直近取り掛かる PBIの見積 もりをお願いします。 スクラムマスター 暖かく見守る 3SP 2SP 注意点を踏まえたバックログリファインメント
77. 開発者 77 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 3SP 2SP スクラムマスター 暖かく見守る 了解しました！ えーと、 これまで消化したPBIを元に相 対的に見積もると・・・ 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている 注意点を踏まえたバックログリファインメント
78. 開発者 78 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 3SP 2SP 5SP 2SP 1SP こんな感じですかねー スクラムマスター 暖かく見守る ナ イ ス 見 積 も り ！ 注意点を踏まえたバックログリファインメント
79. 開発者 79 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 3SP 2SP 5SP 2SP 1SP ありがとう！ でも5SPとなると少し大きいね、 PBIを分割できないかな？ スクラムマスター 暖かく見守る 小 さ く し た い ね ！ 注意点を踏まえたバックログリファインメント
80. 開発者 80 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 3SP 2SP 5SP 2SP 1SP そうですね！ ではこのPBIを分割すると…… スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント
81. 開発者 81 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 2SP 1SP [送られてきたコンタクト申請を 許可と拒否することができる] を [送られてきたコンタクト申請を 許可できる] [送られてきたコンタクト申請を 拒否できる] に分割できました！ こんな感じでいかがですか？ スクラムマスター 暖かく見守る ナ イ ス 分 割 ！ 注意点を踏まえたバックログリファインメント
82. 開発者 82 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 2SP 1SP いいね！ それでいこう！ じゃあ改めて見積もってくれるか な？ スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント
83. 開発者 83 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 3SP 2SP 2SP 1SP あらためて見積もったらこんな 感じになりました！ スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント
84. 開発者 84 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 3SP 2SP 2SP 1SP 見積もった結果を見た上で、改 めて優先度を変更しなくても大 丈夫ですか？ スクラムマスター 暖かく見守る ナ イ ス 確 認 ！ 注意点を踏まえたバックログリファインメント
85. そうだね、じゃあ 【送られてきたコンタクト申請を 一覧で確認できる】 より 【送られてきたコンタクト申請を 許可できる】 のほうが優先度高くしようか 開発者 85 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 3SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント
86. この順番ですね！ これで大丈夫でしょうか？ 開発者 86 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る ナ イ ス 変 更 ！ 注意点を踏まえたバックログリファインメント
87. いいね！ じゃあ現時点ではこの優先度で よろしく〜 開発者 87 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム） プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント
88. 88 これが理想の バックログリファインメント （ベストエフォート）
89. 89 ここまで バックログにあるPBIの 見積もり方について見てきました
90. 90 今の状態(PBI)では 粒度が大きく 開発者が作業できる状態ではない
91. 91 具体的な実装も ブレイクダウンしてないから 見積もりの精度もかなり低い
92. 92 実際にやることを洗い出し 実際の時間に換算し 本当に収まるかを確認したい
93. 93 (今度こそ) ここから スプリントプランニング での見積もりの話
94. 94 あらためて スプリントプランニング ってなにしてるの？
95. 95 スクラムチーム全体で 今回のスプリントによってどのようなプロダクト価値を向上させ るかを決める。 1 なぜ価値があるかを ステークホルダーに伝えられるよう に スプリントゴールを決める 2 POがスプリントゴールを達成するため に必要なPBIを選ぶ （必要に応じてPBIのリファインメントもする） 3 PBIごとに、具体的な作業内容を表す小さな作業アイテム にわけ、 実際にやるとした場合の 作業時間に換算してかかりそうな時間を 見積もる。 4 スプリント中の作業時間と突き合わせ 、本当にスプリント内に収まるか チェックする（収まらないと判明した場合は スプリントゴールを調整する ） 5 スプリントプランニングってなにしてるの？
96. 96 そもそも スプリントバックログ ってなに？
97. 97 超簡単に言うと スプリントで達成したい PBI&スプリントゴールと 達成のためのやることリスト
98. プロダクトバックログアイテム(PBI) →POが作成する ユーザーに価値を届けられる単位で用意された ユーザーストーリー スプリントバックログの作業アイテム →開発者が作成する 実際のスプリント期間中の時間に対し 作業が収まるかを見積もるためのやること 98 おさらい
99. 99 ※余談 スクラムガイド2020年版において、 【スプリントバックログアイテム】という名称は存在しません 開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメン トを作成するために必要な作業を計画する。 これは多くの場合、プロダクトバックログアイテムを 1日以内の小さな作業アイテムに分解することに よって行われる。これをどのように行うかは、開発者だけの裁量とする。 プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない。 スプリントゴール、スプリント向けに選択した プロダクトバックログアイテム 、およびそれら を提供するための計画をまとめて スプリントバックログ と呼ぶ。 ※スクラムガイド2020年版より抜粋
100. 100 スプリントプランニングでは 具体的にどんなことしてるの？
101. 101 以前まで 【Jira上でPBI&作業アイテムの進捗を管理】 ↓ 現在 【Jira上でPBIの進捗管理】 【作業アイテムの進捗はConfluenceで管理】 私達のチームの場合
102. 102 私達のチームでは スプリントプランニングは こんな感じにしてます。
103. 開発者 103 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る スプリントプランニングを 始めます！ まず今回のスプリントはどうしましょう か？ ↑PBI(プロダクトバックログアイテム） スプリントゴール 「　　　　　　　　　　　　　　　　　　　　　　　　　　　」 私達のチームの スプリントプランニング
104. 開発者 104 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 次のスプリントでは 「ユーザーがコンタクト申請機能を使っ てコンタクトが繋がる 」 っていう価値は提供したいなぁ ↑PBI(プロダクトバックログアイテム） スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる 」 私達のチームの スプリントプランニング
105. 開発者 105 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↑PBI(プロダクトバックログアイテム） プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 直近の5回の平均ベロシティは 8SPだったので この 「送られてきたコンタクト申請を 許可する」まで、 次のスプリントで消化できそうで す！ スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 私達のチームの スプリントプランニング
106. 開発者 106 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↑PBI(プロダクトバックログアイテム） プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 了解です〜 ではこのPBIの作業アイテムへ 分割と見積もりお願いします スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 私達のチームの スプリントプランニング
107. 開発者 107 プロダクトオーナー スクラムマスター 暖かく見守る 今スプリント期間中で MTGなどを除 いた、純粋に開発ができる時間 は 16時間ぐらいでした。 では作業アイテムにして 見積もっていきます！ スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 作業アイテムリスト 別のユーザーに対してコンタクト申請を送ることができる ◦ 送られてきたコンタクト申請を許可できる ◦ 送られてきたコンタクト申請を一覧で確認できる ◦ 今回のPBIの作業アイテムの合計時間 ◦h 次回スプリントでチーム活動に使える時間 16h 私達のチームの スプリントプランニング
108. 開発者 108 プロダクトオーナー スクラムマスター 暖かく見守る 今スプリント期間中で MTGなどを除 いた、純粋に開発ができる時間 は 16時間ぐらいでした。 では作業アイテムにして 見積もっていきます！ スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 作業アイテムリスト 別のユーザーに対してコンタクト申請を送ることができる ◦ 送られてきたコンタクト申請を許可できる ◦ 送られてきたコンタクト申請を一覧で確認できる ◦ 今回のPBIの作業アイテムの合計時間 ◦h 次回スプリントでチーム活動に使える時間 16h 〜開発者見積もり中〜
 私達のチームの スプリントプランニング
109. 開発者 109 プロダクトオーナー スクラムマスター 暖かく見守る PBIと対になる作業アイテムと それにかかる時間の見込みを出しま した！ スプリントの作業時間と突き合わせ たところ、(16h-15h = 1h余り) スプリントゴールの達成もできそう で す！ スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 作業アイテムリスト 別のユーザーに対してコンタクト申請を送ることができる 5h ◦ ◦◦を✕✕する ◦ ~~~~~ ◦ リリースする 送られてきたコンタクト申請を許可できる 7h ◦ ◦◦を✕✕する ◦ ~~~~~ ◦ リリースする 送られてきたコンタクト申請を一覧で確認できる 3h ◦ ◦◦を✕✕する ◦ ~~~~ ◦ リリースする 今回のPBIの作業アイテムの合計時間 15h 次回スプリントでチーム活動に使える時間 16h 私達のチームの スプリントプランニング
110. 開発者 110 プロダクトオーナー スクラムマスター 暖かく見守る 大丈夫そうだね！ じゃあ今回のスプリントも 頑張っていこう！ スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 作業アイテムリスト 別のユーザーに対してコンタクト申請を送ることができる 5h ◦ ◦◦を✕✕する ◦ ~~~~~ ◦ リリースする 送られてきたコンタクト申請を許可できる 7h ◦ ◦◦を✕✕する ◦ ~~~~~ ◦ リリースする 送られてきたコンタクト申請を一覧で確認できる 3h ◦ ◦◦を✕✕する ◦ ~~~~ ◦ リリースする 今回のPBIの作業アイテムの合計時間 15h 次回スプリントでチーム活動に使える時間 16h 私達のチームの スプリントプランニング
111. 111 これが理想の スプリントプランニング （ベストエフォート）
112. 最後に 5
113. 113 忘れてはいけないこと
114. 114 我々はアジャイルな開発を通して ユーザーに価値を届けたいだけで スクラムをしたい訳じゃない
115. 115 なので先程の スクラムイベントの例も 見積もり方法も 全て正しいわけじゃないし 間違ってるわけでもない
116. 116 アジャイルコーチは原理原則を 伝えてくれるが、 自分たちのチームに適応させる ことはチームでやるしかない
117. 117 スクラムイベントも 自分たちのチームも アジャイルに少しずつ カイゼンしていこう！
119. 働くをもっと楽しく、創造的に