目的
スクラムイベントの役割を理解する
ゴール
スクラムイベントの役割を理解することによりよりイベントの際に集中して取り組めるようになること
前提
チームメンバー向けにイベントの役割をざっと説明した資料になります。多少違う内容もあるかと思います。
スプリント
必須度
◎:スクラムガイドに定義されている
説明
スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わ
る。
一貫性を保つため、スプリントは 1 か月以内の決まった長さとする。前のスプリントが終わり
次第、新しいスプリントが始まる。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペク
ティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行
われる。
スプリントでは、
- スプリントゴールの達成を危険にさらすような変更はしない。
- 品質を低下させない。
- プロダクトバックログを必要に応じてリファインメントする。
- 学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要に
なる場合がある。
スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か月ごとに
確実になり、予測可能性が高まる。スプリントの期間が長すぎると、スプリントゴールが役に
立たなくなり、複雑さが増し、リスクが高まる可能性がある。スプリントの期間を短くすれば、
より多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることができ
る。スプリントは短いプロジェクトと考えることもできる。
進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプ
ラクティスが存在する。これらの有用性は証明されているが、経験主義の重要性を置き換える
ものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、将
来を見据えた意思決定に使用できる。
スプリントゴールがもはや役に立たなくなった場合、スプリントは中止されることになるだろ
う。プロダクトオーナーだけがスプリントを中止する権限を持つ。
スクラムガイドより
超訳
スプリント(短距離走)の通り、走りきるために事前に計画を行いスプリントを行う。
そのスプリントごとにリリースができるのが理想だがそうならないPJも多い。
そのスプリントでできることをチームとしてコミットメントするため、できない場合できなかった理由を説明する必要がある。
スプリント実施のために阻害する要因が多すぎた場合にスプリントを止める場合もある。
スプリントプランニング
必須度
◎:スクラムガイドに定義されている
説明
スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計
画を立てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。
プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それら
とプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチ
ームは、アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよ
い。
スプリントプランニングは次のトピックに対応する：
トピック 1：このスプリントはなぜ価値があるのか？
プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのように高めるこ
とができるかを提案する。次に、スクラムチーム全体が協力して、そのスプリントになぜ価値
があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、ス
プリントプランニングの終了までに確定する必要がある。
トピック 2：このスプリントで何ができるのか？
開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを
選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバッ
クログアイテムのリファインメントをする場合がある。それによって、チームの理解と自信が
高まる。
スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、
開発者が過去の自分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を
深めていけば、スプリントの予測に自信が持てるようになる。
トピック 3：選択した作業をどのように成し遂げるのか？
開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメン
トを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを 1 日以内の小さな作業アイテムに分解することによって行われる。これをどのように行う
かは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変
換する方法は誰も教えてくれない。
スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれら
を提供するための計画をまとめてスプリントバックログと呼ぶ。
スプリントが 1 か月の場合、スプリントプランニングのタイムボックスは最大で 8 時間である。
スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。
スクラムガイドより
超訳
スプリント(短距離走)を走り切るために計画する場。
チームで見積もりを行うことでチームとしてタスクを取り組めるように準備する場でもある。
チームで不明点を解決して、スプリント開始時にタスクに対する不明点は全員ない状態にする。=どんな人でもそのタスクを取り組める状態にする。
チームメンバーの目線はスプリント実施時に自分でもやれる状態にすること、やりきれることを約束できるようにすること
デイリースクラム
必須度
◎:スクラムガイドに定義されている
説明
デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対す
る進捗を検査し、必要に応じてスプリントバックログを適応させることである。
デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。複雑さを低減
するために、スプリント期間中は毎日、同じ時間・場所で開催する。プロダクトオーナーまた
はスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開
発者として参加する。
開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの 1 日の作業
の実行可能な計画を作成する限り、必要な構造とやり方を選択できる。これは集中を生み出し、
自己管理を促進する。
デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進
する。その結果、他の会議を不要にする。
開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの
作業を適応または再計画することについて、より詳細な議論をするために、開発者は一日を通
じて頻繁に話し合う。
スクラムガイドより
超訳
スプリントゴールを達成するためにチームメンバーがその日のタスクをとる。
スプリントゴールが危ぶまれるならその話もしたりする。
チームメンバーとしては日々のタスクを報告する場になりがちだが、目線はあくまでスプリントゴールを達成できるか、が主体で話す必要がある。
スプリントレビュー
必須度
◎:スクラムガイドに定義されている
説明
スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。
スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対す
る進捗について話し合う。
スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成
され、自分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者
は次にやるべきことに協力して取り組む。新たな機会に見合うようにプロダクトバックログを
調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームは
スプリントレビューをプレゼンテーションだけに限定しないようにする。
スプリントレビューは、スプリントの最後から 2 番目のイベントであり、スプリントが 1 か月
の場合、タイムボックスは最大 4 時間である。スプリントの期間が短ければ、スプリントレビ
ューの時間も短くすることが多い。
スクラムガイドより
超訳
ステークホルダーに成果物を見てもらい。修正する場合は次スプリントに入れる。
(が期限が優先度として高い場合はなにを妥協するかもPO,ステークホルダーと話あう。)
スプリントレトロスペクティブ
必須度
◎:スクラムガイドに定義されている
説明
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。
スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリ
ントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。
スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、ス
プリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどの
ように解決されたか（または解決されなかったか）について話し合う。
スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の
大きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加する
こともできる。
スプリントレトロスペクティブをもってスプリントは終了する。スプリントが 1 か月の場合、
スプリントレトロスペクティブは最大 3 時間である。スプリントの期間が短ければ、スプリン
トレトロスペクティブの時間も短くすることが多い。
スクラムガイドより
超訳
ふりかえりを行い。チームの効果を改善するためにもっとも役立つ変更を行う。
チームメンバーの目線はチームの効果の最大化をするためになにをしたらいいかを話し合い。アクションを起こす。
リファインメント
必須度
○:スクラムガイドに定義されていないが割と必要になる事が多い
説明
スプリント開始後、「〇〇の要件が決まっていない」
「△△の場合はどうしたらよい？」など決まりきっていない場合スプリントを走り切ることができない。
そのようなことが起こさないためにスプリント前に、疑問点がないか確認をし、見積もりを出せる状態 にすること
だいたい前スプリントのどこかで話す
超訳
疑問点を洗い出しPOなどに確認をしておいて次スプリントで止まることなく進めれるようにするMTG
チームメンバーの目線は次スプリント実施時にやりきれると確認するために疑問点などをすべて洗い出して返答をもらうこと
リリースプランニング
必須度
△:スクラムガイドに定義されていない
説明
スクラムではスプリントでできるかどうかを決め、それ以外のものはいつできるかできないかというものを決めることをあまりしない。(顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。)が背後の価値としてあるため、いつではなく、より良いものを出すという思想のため
しかしながらそのように運用できている組織は(特に日本では)少なくリリース日固定でのPJが存在している。
その場合にリリースプランニングを行う。
リリースプランニングとは、チームのベロシティから〇〇までに出せそうだという見積もりをだすことである。
方法
(だいたい)リリース対象のプロダクトバックログからプロダクトバックログアイテムに分割してそれぞれに対してポイントで見積もる。
今までチームが実施していたポイントベースのベロシティから何スプリントで終わりそうかを見積もる。
超訳
チームの生産性を顧みて何スプリント後までにリリースできそうかそのプランを出すこと
引用
https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
https://agilemanifesto.org/iso/ja/principles.html