Slide 1

Slide 1 text

       © Chatwork 2022年10月01日 やまごん(Yamagoshi Tomonori) XP祭り2022 初心者スクラムチームが陥っていた 間違ったスクラムの見積もり方法と それに対するカイゼン

Slide 2

Slide 2 text

まず だれやねん 2 2020年 8月             にJoin 2020年 8月末 Team SuperNovaを結成 (なんちゃってスクラム開始) 2021年 1月 チームメンバーが3人→2人に (スクラムマスター不在) 2022年 3月 メンバー再編のタイミングで スクラムマスターをすることに(兼任) 2022年4月 認定スクラムマスター取得 やまごん (Yamagoshi Tomonori) Chatwork株式会社 サーバーサイド開発部(PHP) Team SuperNova スクラムマスター 兼 開発者

Slide 3

Slide 3 text

スクラムにおける見積もりって? スクラム初心者のやりがちな見積もり 間違った見積もり方法とカイゼン点 スプリントプランニング 最後に 1 2 3 4 5 AGENDA アジェンダ

Slide 4

Slide 4 text

本編 1

Slide 5

Slide 5 text

5 さて

Slide 6

Slide 6 text

6 今回の発表内容

Slide 7

Slide 7 text

7 間違ったスクラムの 見積もり方法と それに対するカイゼン

Slide 8

Slide 8 text

8 に入る前に

Slide 9

Slide 9 text

9 スクラムを知らない方 向けに スクラムについて軽く説明

Slide 10

Slide 10 text

スクラム開発とは 10 プロダクト開発におけるスクラム(英: Scrum)は複雑な問題への適応型ソリューションをチームで開発し価値を生み出すた めの軽量級フレームワークである ○概要 複雑な問題に対する完璧なソリューションを1度で実現することは難しい。異なるアプローチとして、不完全なソリューショ ンを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従う べき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その 目的は開発したソリューションを介して価値を生み出すことである。 スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰 り返し」を実現できる環境を生み出すシンプルなアプローチである[2]。スクラムのカギとなる基本原則は、プロジェクト開 発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処 することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定 義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプロー チである。 スクラムはチームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメン バーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケー ションをとり、プロジェクトにおける規律を守ることである。 ○背景 複雑な問題と適応型ソリューション 複雑な問題は難しい。もし1回で問題への完璧な解決策/ソリューションを提供できれば大きな価値を提供できる。しかし「完 璧に計画されたソリューション」は往々にして不完全に終わる。そうでないやり方の1つが適応型ソリューション(英: adaptive solutions)である。すなわち最初は不完全だが段階的に学び改善されていくソリューションである。 ソリューション開発と目的 wikipedia から引用

Slide 11

Slide 11 text

11 ❓

Slide 12

Slide 12 text

12 つまりは

Slide 13

Slide 13 text

13 最近イケてる アジャイル開発の方法

Slide 14

Slide 14 text

14 現在Chatwork社が 全社的に”推し”進めている 開発手法でもある

Slide 15

Slide 15 text

15 そのスクラムをやるために 必要な役割について説明

Slide 16

Slide 16 text

16 【スクラムチーム】 開発者 プロダクトオーナー スクラムマスター で構成される ざっくり説明

Slide 17

Slide 17 text

【開発者】 実際に使える成果物を作ることに 責任を持つ 17 ざっくり説明 実際に開発してモノをつくるよ 作る予定をしているモノの 見積もりもするよ

Slide 18

Slide 18 text

18 【プロダクトオーナー】 スクラムチームから生み出される モノの価値の最大化に責任 ざっくり説明 どんな価値を提供するか考える よ プロダクトゴールを見据えて、 作るモノの優先度も考える よ

Slide 19

Slide 19 text

19 【スクラムマスター】 スクラムの理解と実践を推進し、 プロジェクトを円滑に進めることに 責任を持つ ざっくり説明 スクラムチームがスクラムでの 開発に集中できるように障害を取り除く よ チームをコーチングしたりする よ

Slide 20

Slide 20 text

20 スクラムはいくつかの スクラムイベントで 構成されるフレームワーク

Slide 21

Slide 21 text

21 スクラムイベントの1つで 作業の見積もりをするのが スプリントプランニング

Slide 22

Slide 22 text

22 スプリントプランニングに ついても軽く説明

Slide 23

Slide 23 text

スプリントプランニングとは 23 スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計 画を⽴てる。結果としてできる 計画は、スクラムチーム全体の共同作業によって作成される。 プロダクトオーナーは参加者に対して、最も重要なプロダクト バックログアイテムと、それら とプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチ ームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよ い。 スプリントプランニング は次のトピックに対応する: トピック 1:このスプリントはなぜ価値があるのか? プロダクトオーナーは、プロダクトの価 値と有⽤性を今回のスプリントでどのように⾼めるこ とができるかを提案する。次に、スクラムチーム全体が協⼒して、その スプリントになぜ価値 があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、ス プリン トプランニングの終了までに確定する必要がある。 トピック 2:このスプリントで何ができるのか? 開発者は、プロダクト オーナーとの話し合いを通じて、プロダクトバックログからアイテムを 選択し、今回のスプリントに含める。スクラムチーム は、このプロセスの中でプロダクトバッ クログアイテムのリファインメントをする場合がある。それによって、チームの理解 と⾃信が ⾼まる。 10 スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、 開発者が 過去の⾃分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を 深めていけば、スプリントの予測に⾃信 が持てるようになる。 トピック 3:選択した作業をどのように成し遂げるのか? 開発者は、選択したプロダクトバックログ アイテムごとに、完成の定義を満たすインクリメン トを作成するために必要な作業を計画する。これは多くの場合、プロダク トバックログアイテ ムを 1 ⽇以内の⼩さな作業アイテムに分解することによって⾏われる。これをどのように⾏う かは、開 発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変 換する⽅法は誰も教えてくれない。 ス スクラムガイド2020より引用

Slide 24

Slide 24 text

24 ❓

Slide 25

Slide 25 text

25 つまりは part2

Slide 26

Slide 26 text

26 スプリント期間中(1週間とか)に やりきりたいこと(PBI)を 作業単位にして見積もり 本当にスプリントに収まるか 計画するイベント

Slide 27

Slide 27 text

プロダクトバックログアイテム(PBI) →ユーザーに価値を届けられる単位で用意された ユーザーストーリー(チケット) 27 用語の補足

Slide 28

Slide 28 text

28 なるほど! スプリント内でやることを 見積もればいいのか! 当時のぼくたちのちーむ

Slide 29

Slide 29 text

29 スクラムの見積もりを 早速やってみよう!

Slide 30

Slide 30 text

30 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする まず見積もるために やらなきゃいけないチケッ トを切って・・・ これでプロダクトバックロ グアイテム(PBI)とやらが できたぞ! 開発者 ↓PBI(プロダクトバックログアイテム)

Slide 31

Slide 31 text

31 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする ふむふむ スクラムのPBIは SP(ストーリーポイント) っていう相対見積もりを使 うらしい ?SP 開発者 ↓PBI(プロダクトバックログアイテム) ?SP ?SP ?SP ?SP

Slide 32

Slide 32 text

32 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする 最初は比較に使う実績が あるPBIがないから、 一番小さいのと大きそうな PBIにSPを決め打ちするら しい・・・ ?SP 開発者 ↓PBI(プロダクトバックログアイテム) ?SP ?SP ?SP ?SP

Slide 33

Slide 33 text

33 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする よし!それぞれ 5SP 1SP ってつけてみたぞ! 5SP 1SP 開発者 ↓PBI(プロダクトバックログアイテム)

Slide 34

Slide 34 text

34 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする 相対的に見て こんな感じかな? 5SP 1SP 1SP 3SP 4SP 開発者 ↓PBI

Slide 35

Slide 35 text

35 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする よし! スプリントやってくぞ! 5SP 1SP 1SP 3SP 4SP 開発者 ↓PBI

Slide 36

Slide 36 text

36 Aの設計をする バックログ スプリント1 Aの実装する Aのテストする Aのドキュメントを更新 Aのリリースする 相対的に見て こんな感じかな? 5SP 1SP 1SP 3SP 4SP 開発者 ↓PBI 〜何スプリントか経過した後〜


Slide 37

Slide 37 text

37 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする 次のスプリントだ! スプリントプランニングを するぞ! Aの実装する Aのドキュメントを更新 1SP 4SP 開発者 ↓PBI

Slide 38

Slide 38 text

38 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする この前実装したAのときは 4SPは2日ぐらいかかって、 1SPは半日ぐらいかかった から・・・ Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI

Slide 39

Slide 39 text

39 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ! テストは 2日半ぐらいかかりそうだから 5SP! Aの実装する Aのドキュメントを更新 1SP 4SP 10SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI 5SP

Slide 40

Slide 40 text

40 Bの設計をする バックログ スプリント2 Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP スクラムな見積もりじゃない 開発者 2日ぐらいかかった 半日ぐらいかかった ↓PBI 10SP 5SP 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ! テストは 2日半ぐらいかかりそうだから 5SP!

Slide 41

Slide 41 text

41 どこがスクラムな見積もり じゃない?

Slide 42

Slide 42 text

42 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ! テストは 2日半ぐらいだから 5SP! Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 どこが問題でしょうか? ↓PBI 10SP 5SP

Slide 43

Slide 43 text

43 パッと見ただけで わかる問題が5つ

Slide 44

Slide 44 text

44 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ! テストは 2日半ぐらいだから 5SP! 10SP 5SP 見積もりがSPといいつつ ただの工数見積になっている

Slide 45

Slide 45 text

45 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 5SP 見積もりがSPといいつつ ただの工数見積になっている 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ! テストは 2日半ぐらいだから 5SP! 10SP

Slide 46

Slide 46 text

46 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 5SP 見積もりがSPといいつつ ただの工数見積になっている 1SPが半日規模と大きすぎる 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ! テストは 2日半ぐらいだから 5SP! 10SP

Slide 47

Slide 47 text

47 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする Aの実装する Aのドキュメントを更新 1SP 4SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 見積もった結果、SPが大きかっ たのに分割していない 5SP 見積もりがSPといいつつ ただの工数見積になっている 今回のBの実装は 5日ぐらいかかりそうだから 10SPだ! テストは 2日半ぐらいだから 5SP! 10SP 1SPが半日規模と大きすぎる

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

49 これらの5つの問題があった

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

51 Bの設計をする バックログ スプリントX Bの実装する Bのテストする Bのドキュメントを更新 Bのリリースする 今回のBの実装は 3日ぐらいかかりそうだから 6SPだ! テストは 2日半ぐらいだから 5SP! Aの実装する Aのドキュメントを更新 1SP 4SP 6SP 2日ぐらいかかった 半日ぐらいかかった 開発者 ↓PBI やること単位でチケット (PBI)を 切ってしまっている 見積もった結果、SPが大きかっ たのに分割していない PBIなのに【開発者】が チケットを作成している 見積もりがSPといいつつ ただの工数見積になっている 1SPが半日規模と大きすぎる それぞれにどうやって
 アプローチすべき?


Slide 52

Slide 52 text

○なぜ問題なのか? SP(ストーリーポイント)は他のPBIとの相対見積もりをすることでPBIの大まかな規模感 を【バックログリファインメント】で見積もるためのもの それなのに 0.5日 = 1SP という工数をもとにした計算方法で見積もってしまっているこ とが問題である。 ①見積もりがSPといいつつただの工数見積になっている 52

Slide 53

Slide 53 text

①見積もりがSPといいつつただの工数見積になっている 53  改善のためのアプローチ 実際に達成したPBIに掛かった時間にとらわれず、規模感・大きさでPBIを比較して ざっくりで見積もることが大事。 SP(ストーリーポイント)は多少実績とずれても別に問題ないゆるい見積もりだと思うこと。 他の意見を聞くと流されたり影響を受けてしまうため、 【プランニングポーカー】という決定方法で、一斉に各メンバーが思った数字をあげ、最低点 と最高点の人がなぜそうおもったか発表して、再び数字を上げる、といった方式を取ることが 多いとされる。 選ぶ数字はフィボナッチ数列(1,2,3,5,8,13…)の値から選ぶ場合が多い 参考: Q. プロダクトバックログの見積りについて、規模や工数を算出する時にどんな方法を使えばいいですか?

Slide 54

Slide 54 text

○なぜ問題なのか? PBI(プロダクトバックログアイテム) とは、 プロダクトの価値を向上させるためのユーザーストー リーであるため、 PBIが一つ達成された時にプロダクトの価値が向上し ているようなものでなければならない 現在のチケットは 作業レイヤーでチケットが別れてしまっているため、 ウォーターフォール的な区切り方になっていることが 問題となっている。 ②やること単位でチケット(PBI)を切ってしまっている 54

Slide 55

Slide 55 text

 改善のためのアプローチ ユーザーストーリーとして、単体で価値提供できる粒度でチ ケット(PBI)を作成をする。 例えばコンタクト追加機能を提供したい場合 ①別のユーザーに対してコンタクト申請を送ることができる ②送られてきたコンタクト申請を申請中の一覧として確認できる ③送られてきたコンタクト申請を拒否できる ④別のユーザーに対して送ったコンタクト申請をキャンセルできる ⑤送られてきたコンタクト申請を許可する ⑥申請を許可したユーザーがコンタクト一覧で確認できる といった様に、単体で価値が提供できる単位になっているとよい ②やること単位でチケット(PBI)を切ってしまっている 55 参考:Q. プロダクトバックログアイテムの分割の指針について教えてください

Slide 56

Slide 56 text

③1SPが半日規模と大きすぎる 56 ○なぜ問題なのか? 1SPが大きすぎると、SPで見積もった場合の誤差が発生しやすくなってしまうため、 相対比較の精度がかなり低下してしまうため 今回の例でいうと、SPの最小単位が半日規模だと 見積もった時に 0.2SP などが生まれてしまう可能性があったり、同じ[2SP]とつけたPBI の中でも、[1SPよりの2SP]と[3SPよりの2SP]などで誤差が大きくなってしまう

Slide 57

Slide 57 text

③1SPが半日規模と大きすぎる 57  改善のためのアプローチ 前提として 1SP が何時間などとSPを具体的な時間などは照らし合わせてはいけない そして半日よりもっと少ない規模感で終わったPBIを1SPとして、 新たにSPを見積もる前に基準を修正してから見積もる。 そうすることで、ベロシティの制度や見積もりの精度も高まり、見積もった時にSPが大 きくなった場合分割しよう、という動きに繋がりやすくなる。

Slide 58

Slide 58 text

○なぜ問題なのか? 何度かスプリントを回すことで、1スプリントで一体いくつのSPが達成できるかが ベロシティという形で見えてくる そのベロシティが例えば 8SPだった場合 このBの実装をするというPBIは絶対に1ス プリントでは完了しない そうなるとそもそもスプリントに組み込むことができないことになってしまう ④見積もった結果、SPが大きかったのに分割していない 58

Slide 59

Slide 59 text

 改善のためのアプローチ PBIの大きさは細かくできるのであれば細かいほどよいとされているが、 最大でも1スプリント内で終わるサイズにすべきなので、見積もった結果大きいPBIだと判明した場合 は分割する必要がある。 例として【①別のユーザーに対してコンタクト申請を送ることができる】が2スプリントにまたいで しまうサイズだった場合、以下のように分割することが可能 1. コンタクト申請を送信するユーザーを検索、指定ができる 2. 選択したユーザーがコンタクト申請が可能であることを確認した上でコンタクト申請メールを送信する 3. コンタクト済み・申請済みのアカウントが表示・指定出来ないようにする ..etc ④見積もった結果、SPが大きかったのに分割していない 59 参考1:Q. プロダクトバックログアイテムの分割の指針について教えてください 参考2:Q. 1つのプロダクトバックログアイテムが大きくて1スプリントでは作れません。複数スプリントにまたいで開発していいですか?

Slide 60

Slide 60 text

⑤PBIなのに【開発者】がチケットを作成している 60 ○なぜ問題なのか? PBI(プロダクトバックログアイテム)はPOの持ち物なので、 勝手に開発者が作成したり変更してはいけないため

Slide 61

Slide 61 text

⑤PBIなのに【開発者】がチケットを作成している 61  改善のためのアプローチ PBIはPOが管理しているので、開発者はPOとの合意がない場合は勝手に作成・並び替えしたりしな いこと バックログリファインメントでPOの合意の上で操作するのは問題ない。また、スクラムメンバーと してPBIへの意見や提案を行うのはより良いインクリメントを出す上で効果があるので、POと開発者 は積極的に話し合うとよいでしょう Q : POがいない場合 → POがいないとスクラムではないので、POを連れてきましょう Q2 : POが忙しい場合 → 忙しくてバックログリファインメントやPBIを作れない人はPOじゃないのでPOを連れてきましょう

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

63 さて

Slide 64

Slide 64 text

64 お気づきの方もいるかも 知れませんが

Slide 65

Slide 65 text

65 ここまで スプリントプランニング での見積もりの話 ではありませんでした

Slide 66

Slide 66 text

66 実は全て バックログリファインメント での見積もりの話(PBI)

Slide 67

Slide 67 text

67 スクラムイベントで 見積もりって実は2回ある

Slide 68

Slide 68 text

68 スプリント期間中(1週間とか)に やりきりたいこと(PBI)を 作業単位にして見積もり 本当にスプリントに収まるか 計画するイベント バックログリファインメント スプリントプランニング 見積もりして 更に

Slide 69

Slide 69 text

69 スクラム初心者は 見積もりって一回だと勘違い しちゃう 69

Slide 70

Slide 70 text

70 バックログリファインメント →POがチケット(PBI)の 優先度を決める →SPでざっくりPBIを見積もって その規模感と顧客価値を元に POが優先度判断する 誤解していた イベントへの認識

Slide 71

Slide 71 text

71 スプリントプランニング →スプリント期間中に どこまでのPBIができるか計画する →見積もっておいたPBIが 次スプリントに収まるかを開発者が 自分達のために作業アイテムにした上で 具体的な時間で計画する 誤解していた イベントへの認識

Slide 72

Slide 72 text

72 アプローチのまとめ

Slide 73

Slide 73 text

73 バックログリファインメント で作るPBIは気をつけよう

Slide 74

Slide 74 text

[1] 見積もりがSPといいつつただの工数見積もりになっている  →実際に掛かった時間は一切無視!あくまでやってみた感覚の規模感で相対比較してつけること! [2] やること単位でチケット(PBI)を切ってしまっている  →単体でリリースされたとしてもプロダクトとして価値を提供できる単位でPBIを作成すること! [3] 1SPが半日規模と大きすぎる  →SPの最小単位を見直そう!ユーザーに価値提供できるPBIで一番小さいものを原基として基準にしよう! [4] 見積もった結果、SPが大きかったのに分割していない  →スプリントに収まらない大きさのPBIは分割しよう!分割する時も価値を与える単位でできるだけ小さく! [5] PBIなのに【開発者】がチケットを作成している  →PBIを管理するのはプロダクトオーナー!ただし開発者も意見などを出して改善しよう! バックログリファインメント&PBIの注意点まとめ 74

Slide 75

Slide 75 text

75 注意点を踏まえた バックログリファインメント はこんなイメージ

Slide 76

Slide 76 text

開発者 76 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている ↓PBI(プロダクトバックログアイテム) プロダクトオーナー バックログリファインメントを開始 します。 PBIを3件追加しました まず直近取り掛かる PBIの見積 もりをお願いします。 スクラムマスター 暖かく見守る 3SP 2SP 注意点を踏まえたバックログリファインメント

Slide 77

Slide 77 text

開発者 77 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 3SP 2SP スクラムマスター 暖かく見守る 了解しました! えーと、 これまで消化したPBIを元に相 対的に見積もると・・・ 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている 注意点を踏まえたバックログリファインメント

Slide 78

Slide 78 text

開発者 78 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 3SP 2SP 5SP 2SP 1SP こんな感じですかねー スクラムマスター 暖かく見守る ナ イ ス 見 積 も り ! 注意点を踏まえたバックログリファインメント

Slide 79

Slide 79 text

開発者 79 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 3SP 2SP 5SP 2SP 1SP ありがとう! でも5SPとなると少し大きいね、 PBIを分割できないかな? スクラムマスター 暖かく見守る 小 さ く し た い ね ! 注意点を踏まえたバックログリファインメント

Slide 80

Slide 80 text

開発者 80 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可と拒否す ることができる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる 申請を許可したユーザーがコンタクト一覧に 表示されている ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 3SP 2SP 5SP 2SP 1SP そうですね! ではこのPBIを分割すると…… スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント

Slide 81

Slide 81 text

開発者 81 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 2SP 1SP [送られてきたコンタクト申請を 許可と拒否することができる] を [送られてきたコンタクト申請を 許可できる] [送られてきたコンタクト申請を 拒否できる] に分割できました! こんな感じでいかがですか? スクラムマスター 暖かく見守る ナ イ ス 分 割 ! 注意点を踏まえたバックログリファインメント

Slide 82

Slide 82 text

開発者 82 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 2SP 1SP いいね! それでいこう! じゃあ改めて見積もってくれるか な? スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント

Slide 83

Slide 83 text

開発者 83 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 3SP 2SP 2SP 1SP あらためて見積もったらこんな 感じになりました! スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント

Slide 84

Slide 84 text

開発者 84 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 3SP 2SP 2SP 1SP 見積もった結果を見た上で、改 めて優先度を変更しなくても大 丈夫ですか? スクラムマスター 暖かく見守る ナ イ ス 確 認 ! 注意点を踏まえたバックログリファインメント

Slide 85

Slide 85 text

そうだね、じゃあ 【送られてきたコンタクト申請を 一覧で確認できる】 より 【送られてきたコンタクト申請を 許可できる】 のほうが優先度高くしようか 開発者 85 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 2SP 3SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント

Slide 86

Slide 86 text

この順番ですね! これで大丈夫でしょうか? 開発者 86 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る ナ イ ス 変 更 ! 注意点を踏まえたバックログリファインメント

Slide 87

Slide 87 text

いいね! じゃあ現時点ではこの優先度で よろしく〜 開発者 87 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↓PBI(プロダクトバックログアイテム) プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 注意点を踏まえたバックログリファインメント

Slide 88

Slide 88 text

88 これが理想の バックログリファインメント (ベストエフォート)

Slide 89

Slide 89 text

89 ここまで バックログにあるPBIの 見積もり方について見てきました

Slide 90

Slide 90 text

90 今の状態(PBI)では 粒度が大きく 開発者が作業できる状態ではない

Slide 91

Slide 91 text

91 具体的な実装も ブレイクダウンしてないから 見積もりの精度もかなり低い

Slide 92

Slide 92 text

92 実際にやることを洗い出し 実際の時間に換算し 本当に収まるかを確認したい

Slide 93

Slide 93 text

93 (今度こそ) ここから スプリントプランニング での見積もりの話

Slide 94

Slide 94 text

94 あらためて スプリントプランニング ってなにしてるの?

Slide 95

Slide 95 text

95 スクラムチーム全体で 今回のスプリントによってどのようなプロダクト価値を向上させ るかを決める。 1 なぜ価値があるかを ステークホルダーに伝えられるよう に スプリントゴールを決める 2 POがスプリントゴールを達成するため に必要なPBIを選ぶ (必要に応じてPBIのリファインメントもする) 3 PBIごとに、具体的な作業内容を表す小さな作業アイテム にわけ、 実際にやるとした場合の 作業時間に換算してかかりそうな時間を 見積もる。 4 スプリント中の作業時間と突き合わせ 、本当にスプリント内に収まるか チェックする(収まらないと判明した場合は スプリントゴールを調整する ) 5 スプリントプランニングってなにしてるの?

Slide 96

Slide 96 text

96 そもそも スプリントバックログ ってなに?

Slide 97

Slide 97 text

97 超簡単に言うと スプリントで達成したい PBI&スプリントゴールと 達成のためのやることリスト

Slide 98

Slide 98 text

プロダクトバックログアイテム(PBI) →POが作成する ユーザーに価値を届けられる単位で用意された ユーザーストーリー スプリントバックログの作業アイテム →開発者が作成する 実際のスプリント期間中の時間に対し 作業が収まるかを見積もるためのやること 98 おさらい

Slide 99

Slide 99 text

99 ※余談 スクラムガイド2020年版において、 【スプリントバックログアイテム】という名称は存在しません 開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメン トを作成するために必要な作業を計画する。 これは多くの場合、プロダクトバックログアイテムを 1日以内の小さな作業アイテムに分解することに よって行われる。これをどのように行うかは、開発者だけの裁量とする。 プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない。 スプリントゴール、スプリント向けに選択した プロダクトバックログアイテム 、およびそれら を提供するための計画をまとめて スプリントバックログ と呼ぶ。 ※スクラムガイド2020年版より抜粋

Slide 100

Slide 100 text

100 スプリントプランニングでは 具体的にどんなことしてるの?

Slide 101

Slide 101 text

101 以前まで 【Jira上でPBI&作業アイテムの進捗を管理】 ↓ 現在 【Jira上でPBIの進捗管理】 【作業アイテムの進捗はConfluenceで管理】 私達のチームの場合

Slide 102

Slide 102 text

102 私達のチームでは スプリントプランニングは こんな感じにしてます。

Slide 103

Slide 103 text

開発者 103 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る スプリントプランニングを 始めます! まず今回のスプリントはどうしましょう か? ↑PBI(プロダクトバックログアイテム) スプリントゴール 「                           」 私達のチームの スプリントプランニング

Slide 104

Slide 104 text

開発者 104 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 次のスプリントでは 「ユーザーがコンタクト申請機能を使っ てコンタクトが繋がる 」 っていう価値は提供したいなぁ ↑PBI(プロダクトバックログアイテム) スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる 」 私達のチームの スプリントプランニング

Slide 105

Slide 105 text

開発者 105 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↑PBI(プロダクトバックログアイテム) プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 直近の5回の平均ベロシティは 8SPだったので この 「送られてきたコンタクト申請を 許可する」まで、 次のスプリントで消化できそうで す! スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 私達のチームの スプリントプランニング

Slide 106

Slide 106 text

開発者 106 別のユーザーに対してコンタクト申請を送る ことができる バックログ スプリントX 送られてきたコンタクト申請を許可できる 送られてきたコンタクト申請を一覧で確認で きる 送られてきたコンタクト申請を拒否できる 別のユーザーに対して送ったコンタクト申請 をキャンセルできる ↑PBI(プロダクトバックログアイテム) プロダクトオーナー 申請を許可したユーザーがコンタクト一覧に 表示されている 3SP 3SP 2SP 2SP 2SP 1SP スクラムマスター 暖かく見守る 了解です〜 ではこのPBIの作業アイテムへ 分割と見積もりお願いします スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 私達のチームの スプリントプランニング

Slide 107

Slide 107 text

開発者 107 プロダクトオーナー スクラムマスター 暖かく見守る 今スプリント期間中で MTGなどを除 いた、純粋に開発ができる時間 は 16時間ぐらいでした。 では作業アイテムにして 見積もっていきます! スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 作業アイテムリスト 別のユーザーに対してコンタクト申請を送ることができる ○ 送られてきたコンタクト申請を許可できる ○ 送られてきたコンタクト申請を一覧で確認できる ○ 今回のPBIの作業アイテムの合計時間 ○h 次回スプリントでチーム活動に使える時間 16h 私達のチームの スプリントプランニング

Slide 108

Slide 108 text

開発者 108 プロダクトオーナー スクラムマスター 暖かく見守る 今スプリント期間中で MTGなどを除 いた、純粋に開発ができる時間 は 16時間ぐらいでした。 では作業アイテムにして 見積もっていきます! スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 作業アイテムリスト 別のユーザーに対してコンタクト申請を送ることができる ○ 送られてきたコンタクト申請を許可できる ○ 送られてきたコンタクト申請を一覧で確認できる ○ 今回のPBIの作業アイテムの合計時間 ○h 次回スプリントでチーム活動に使える時間 16h 〜開発者見積もり中〜
 私達のチームの スプリントプランニング

Slide 109

Slide 109 text

開発者 109 プロダクトオーナー スクラムマスター 暖かく見守る PBIと対になる作業アイテムと それにかかる時間の見込みを出しま した! スプリントの作業時間と突き合わせ たところ、(16h-15h = 1h余り) スプリントゴールの達成もできそう で す! スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 作業アイテムリスト 別のユーザーに対してコンタクト申請を送ることができる 5h ○ ○○を✕✕する ○ ~~~~~ ○ リリースする 送られてきたコンタクト申請を許可できる 7h ○ ○○を✕✕する ○ ~~~~~ ○ リリースする 送られてきたコンタクト申請を一覧で確認できる 3h ○ ○○を✕✕する ○ ~~~~ ○ リリースする 今回のPBIの作業アイテムの合計時間 15h 次回スプリントでチーム活動に使える時間 16h 私達のチームの スプリントプランニング

Slide 110

Slide 110 text

開発者 110 プロダクトオーナー スクラムマスター 暖かく見守る 大丈夫そうだね! じゃあ今回のスプリントも 頑張っていこう! スプリントゴール 「ユーザーがコンタクト申請機能を使ってコンタクトが繋がる」 作業アイテムリスト 別のユーザーに対してコンタクト申請を送ることができる 5h ○ ○○を✕✕する ○ ~~~~~ ○ リリースする 送られてきたコンタクト申請を許可できる 7h ○ ○○を✕✕する ○ ~~~~~ ○ リリースする 送られてきたコンタクト申請を一覧で確認できる 3h ○ ○○を✕✕する ○ ~~~~ ○ リリースする 今回のPBIの作業アイテムの合計時間 15h 次回スプリントでチーム活動に使える時間 16h 私達のチームの スプリントプランニング

Slide 111

Slide 111 text

111 これが理想の スプリントプランニング (ベストエフォート)

Slide 112

Slide 112 text

最後に 5

Slide 113

Slide 113 text

113 忘れてはいけないこと

Slide 114

Slide 114 text

114 我々はアジャイルな開発を通して ユーザーに価値を届けたいだけで スクラムをしたい訳じゃない

Slide 115

Slide 115 text

115 なので先程の スクラムイベントの例も 見積もり方法も 全て正しいわけじゃないし 間違ってるわけでもない

Slide 116

Slide 116 text

116 アジャイルコーチは原理原則を 伝えてくれるが、 自分たちのチームに適応させる ことはチームでやるしかない

Slide 117

Slide 117 text

117 スクラムイベントも 自分たちのチームも アジャイルに少しずつ カイゼンしていこう!

Slide 118

Slide 118 text

118

Slide 119

Slide 119 text

働くをもっと楽しく、創造的に