More than 1 year has passed since last update.

スクラムガイドを整理してみた

Last updated at 2024-03-17Posted at 2024-03-10

背景・目的

スクラムについて、あまり体系立てて理解してないため、あらためて整理してみたいと思います。

まとめ

スクラムガイドの特徴を下記に整理します。

特徴	説明
スクラムガイドの目的	スクラムを理解できるように作成されたもの
スクラムガイドの概要	・スクラムの定義が含まれる
スクラムの概要	・スクラムは、複雑な問題に対するソリューション・スクラムは軽量のフレームワーク・人、チーム、組織が価値を生み出すために役立つ・スクラムは、複雑な問題に対するソリューション・スクラムは軽量のフレームワーク・人、チーム、組織が価値を生み出すために役立つ
スクラムマスターが促進すること	・PO（プロダクトオーナーは、複雑な問題に対する作業をバックログに残す・スクラムチームは、スプリント中にアウトプットを生み出す・スクラムチームと関係者は、結果を検査し、次のスプリントに向けて調整する・上記を繰り返す
スクラムフレームワーク	・スクラムフレームワークは、意図的に不完全にしている・スクラム理論を実装するために、必要な部分のみに定義している・スクラムは、それを使用する人々の集合知によってコツ育される・スクラムのルールは、人々の関係や交流を導く
スクラム理論	・経験主義と、無駄のない考え方に基づく・経験主義・無駄のない考え方
スクラムの柱	透明性と検査、適応がある
スクラムの柱(透明性)	・創発的なプロセスと作業は、作業を行う人、作業を受け取る人にも見える必要がある・透明性の低い成果物は価値を低下させて、リスクを増大させる
スクラムの柱(検査)	・スクラム成果物と合意された目標に向けた進捗は、頻度多く深く検査する必要がある・検査を支援するために、5つのイベントの形式がある
スクラムの柱(適応)	・プロセスが許容範囲外になっている場合、調整を早めに行う・関係者に権限や自己管理能力がない場合、適応は困難になる・検査を通じてなにか新しいことを学んだ瞬間に適応することを期待される
Scrum Values	・スクラムが成功するかは、下記の価値観を実践できるかにかかっている　・コミットメント　・集中力　・寛容さ　・経緯　・勇気・スクラムチームは、目標を達成し、お互いをサポートすることに尽力する・主なフォーカスは、これらの目標に向けて可能な限り最善の進歩を遂げるためのスプリントの作業・5つの価値観は、スクラムチームの仕事、行動、行動に関する方向性を与える
スクラムチーム	・基本単位は、少人数のチームであるスクラムチーム・スクラムチームは、下記で構成される　・スクラムマスタ（1人）　・PO（1人）　・開発者・一度に、1つの目標、製品目標に集中する専門家のまとまったユニット・機敏性を保つために、十分な規模、重要な作業を完了するのに十分な規模で構成される・一般的に小規模のほうがコミュニケーションがうまくいき、生産性が高い・同じ製品目標、製品バックログ、製品所有者を共有する必要がある. - 部門横断型・各スプリントで価値を生み出すために必要なスキルをすべて備えている・自己管理能力を有する・誰が、何を、いつ、どのように行うかを内部で決定する
開発者の責任	・スプリントの計画、バックログの作成・完了の定義の遵守・スプリントの目標に向けて毎日の計画を調整・プロフェッショナルとしてお互いに責任を持つ
POの責任	・POは、スクラムチームの作業から得られる製品の価値を最大化する責任がある. ・下記の責任を追う　・製品目標を策定し、明確にし、伝達する　・プロダクトバックログ項目を作成し、明確に伝達する　・製品バックログ項目へのオーダー　・プロダクトバックログが透明で、可視化され、理解されるようにする
スクラムマスターの責任	・スクラムマスターは、スクラムガイドで定義されているようにスクラムを確立する責任がある・スクラムチームの有効性に対して責任を負う
スクラムイベント	・スプリントは、他のすべてのイベントのコンテナ・各イベントは、スクラム成果物を検査して適応させる正式な機会・スクラムではイベントを使用して、規則性を生み出して、スクラムで定義されていない会議の必要性を最小限に抑える
スプリント	下記が行われる。・Sprint Planning ・Daily Scrum ・Sprint Review ・Sprint Retrospective
Sprint Planning	1.このスプリントに価値があるか明示する 2.スプリントで何ができるか定義する 3.スプリントバックログを1日以下の小さな作業項目に分解する
Daily Scrum	・デイリースクラムの目的は、スプリントの目標に向けた進捗を検査し、必要なスプリントバックログを調整し、今後の計画作業を調整すること・15分間のイベント・営業日ごとに同時間同一の場所で開催される・コミュニケーションを改善し、障害を特定し、迅速な意思決定を促進する
Sprint Review	・スプリントの結果を検査し、将来の適応を決定すること・主要な関係者に作業の結果を提示し、製品目標に向けた進捗について話し合う・スプリントで達成されたこと、環境で何が変わったかをレビューする
Retrospective	・レトロスペクティブの目的は、品質と有効性を向上させる方法を計画する・スプリント中に何がうまくいき、どのような問題が発生したか、どのように解決されたか、解決されなかったか話し合う
スクラムの成果物	スクラムの成果物は、作業または価値を表す
プロダクトバックログ	・プロダクトバックログは、プロダクトを改善するために必要なものを順番にまとめた、緊急のリスト・プロダクトバックログの洗練とは、プロダクトバックログ項目をより小さなより正確な項目に分割し、更に定義する行為・説明、順序、サイズ等詳細を追加する継続的なアクティビティ
スプリントバックログ	下記で構成される・Why:スプリント目標・What:スプリントように選択された一連のプロダクトバックログ項目・How:Incrementsを提供するための実行可能な計画

概要

2020 スクラムガイド™をもとに整理します。

Purpose of the Scrum Guide

私たちは 1990 年代初頭にスクラムを開発しました。私たちは、世界中の人々がスクラムを理解できるようにするために、2010 年にスクラムガイドの最初のバージョンを作成しました。それ以来、私たちは小さな機能アップデートを通じてガイドを進化させてきました。私たちは力を合わせてそれを支えます。

世界中の人がスクラムを理解できるように作成されたのが、スクラムガイドである

スクラムガイドにはスクラムの定義が含まれています。フレームワークの各要素は、スクラムで実現される全体的な価値と結果にとって不可欠な特定の目的を果たします。スクラムの核となる設計やアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限され、場合によっては役に立たなくなってしまうことさえあります。

スクラムガイドとは、スクラムの定義が含まれる
フレームワークの各要素により、スクラムで実現される価値と結果を得るために不可欠な目的を果たす

私たちは、ますます複雑化する世界でスクラムの使用が拡大している様子を追跡します。スクラムのルーツであるソフトウェア製品開発を超えて、本質的に複雑な作業を行う多くの分野でスクラムが採用されているのを見て、私たちは恐縮しています。スクラムの使用が広がるにつれ、開発者、研究者、アナリスト、科学者、その他の専門家がその作業を行うようになりました。スクラムで「開発者」という言葉を使用するのは、除外するためではなく、単純化するためです。スクラムから価値を得ている場合は、自分もスクラムに含まれていると考えてください。

スクラムを使用すると、このドキュメントで説明されているスクラムフレームワークに適合するパターン、プロセス、洞察が見つかり、適用され、考案される場合があります。これらは状況に依存し、スクラムの用途によって大きく異なるため、それらの説明はスクラムガイドの目的を超えています。スクラムフレームワーク内で使用するこのような戦術は多岐にわたるため、別の場所で説明されています。

Scrum Definition

スクラムは、複雑な問題に対する適応的なソリューションを通じて、人々、チーム、組織が価値を生み出すのに役立つ軽量のフレームワークです。
一言で言えば、スクラムでは、スクラムマスターが次のような環境を促進する必要があります。

プロダクトオーナーは、複雑な問題に対する作業をプロダクトバックログに発注します。

スクラムチームは、スプリント中に作業の選択を価値の増分に変えます。

スクラムチームとその関係者は結果を検査し、次のスプリントに向けて調整します。

繰り返す

スクラムは、複雑な問題に対するソリューション
スクラムは軽量のフレームワーク
人、チーム、組織が価値を生み出すために役立つ
スクラムマスターは下記の環境を促進する
- PO（プロダクトオーナーは、複雑な問題に対する作業をバックログに残す
- スクラムチームは、スプリント中にアウトプットを生み出す
- スクラムチームと関係者は、結果を検査し、次のスプリントに向けて調整する
- 上記を繰り返す

スクラムはシンプルです。そのまま試してみて、その哲学、理論、構造が目標の達成や価値の創造に役立つかどうかを判断してください。スクラムフレームワークは意図的に不完全であり、スクラム理論を実装するために必要な部分のみを定義しています。スクラムは、それを使用する人々の集合知によって構築されます。スクラムのルールは、人々に詳細な指示を与えるのではなく、人々の関係や交流を導きます。

スクラムフレームワークは、意図的に不完全にしている
スクラム理論を実装するために、必要な部分のみに定義している
スクラムは、それを使用する人々の集合知によってコツ育される
スクラムのルールは、人々の関係や交流を導く

このフレームワーク内では、さまざまなプロセス、技術、および方法を使用できます。スクラムは既存のプラクティスを包み込むか、不要にしてしまいます。スクラムにより、現在の管理、環境、作業手法の相対的な有効性が可視化され、改善が可能になります。

様々なプロセス、技術、方法を使用できる
既存のプラクティスを包含するか、不要にしている
現在の管理、環境、作業手法の相対的な有効性が可視化される。改善が可能

Scrum Theory

スクラムは経験主義と無駄のない考え方に基づいています。経験主義は、知識は経験と観察されたことに基づいた意思決定から得られると主張します。無駄のない考え方により、無駄が削減され、本質的なものに焦点が当てられます。

経験主義と、無駄のない考え方に基づく
経験主義
- 知識は経験と観察されたことに基づく意思決定から得られる
無駄のない考え方
- 無駄が削減され、本質的ものにフォーカスできる

スクラムは、予測可能性を最適化し、リスクを制御するために、反復的で漸進的なアプローチを採用します。スクラムでは、作業を行うためのすべてのスキルと専門知識を集合的に持ち合わせた人々のグループが関与し、必要に応じてそのようなスキルを共有または取得します。

反復的で漸進的なアプローチにより、予測可能性を最適化し、リスクを制御する
作業を行うための全てのスキルと専門知識を集合知に持ち合わせた人びちのグループが関与し、必要に応じてそのようなスキルを共有または取得する

スクラムは、検査と適応のために 4 つの正式なイベントを 1 つのイベント (スプリント) 内に結合します。これらのイベントが機能するのは、透明性、検査、適応という経験的なスクラムの柱を実装しているためです。

検査と適応のために4つの正式なイベントを1つのイベント＝スプリントに結合する
透明性、検査、適応という経験的なスクラムの柱を実装している

Transparency

創発的なプロセスと作業は、作業を行う人だけでなく、作業を受け取る人にも見える必要があります。スクラムでは、重要な決定は、その 3 つの正式な成果物の認識された状態に基づいて行われます。透明性の低い成果物は、価値を低下させ、リスクを増大させる決定につながる可能性があります。
透明なので検査が可能です。透明性のない検査は誤解を招き、無駄が生じます。

創発的なプロセスと作業は、作業を行う人、作業を受け取る人にも見える必要がある
透明性の低い成果物は価値を低下させて、リスクを増大させる

Inspection

スクラム成果物と合意された目標に向けた進捗状況は、潜在的に望ましくない差異や問題を検出するために、頻繁かつ熱心に検査する必要があります。検査を支援するために、スクラムは 5 つのイベントの形式でリズムを提供します。
検査により適応が可能になります。適応を伴わない検査は無意味であると考えられます。スクラムイベントは変化を引き起こすように設計されています。

スクラム成果物と合意された目標に向けた進捗は、頻度多く深く検査する必要がある
検査を支援するために、5つのイベントの形式がある

Adaptation

プロセスの何らかの側面が許容範囲外に逸脱している場合、または結果として得られる製品が許容できない場合は、適用されているプロセスまたは製造されている材料を調整する必要があります。さらなるずれを最小限に抑えるために、調整はできるだけ早く行う必要があります。
関係者に権限や自己管理能力がない場合、適応はさらに困難になります。スクラムチームは、検査を通じて何か新しいことを学んだ瞬間に適応することが期待されます。

プロセスが許容範囲外になっている場合、調整を早めに行う
関係者に権限や自己管理能力がない場合、適応は困難になる
検査を通じてなにか新しいことを学んだ瞬間に適応することを期待される

Scrum Values

スクラムの使用が成功するかどうかは、人々が次の 5 つの価値観を実践できるようになるかどうかにかかっています。
コミットメント、集中力、寛容さ、敬意、そして勇気

スクラムが成功するかは、下記の価値観を実践できるかにかかっている
- コミットメント
- 集中力
- 寛容さ
- 経緯
- 勇気

スクラムチームは、目標を達成し、お互いをサポートすることに尽力します。彼らの主な焦点は、これらの目標に向けて可能な限り最善の進歩を遂げるためのスプリントの作業です。スクラムチームとその関係者は、作業と課題についてオープンです。スクラムチームのメンバーは、有能で独立した人間としてお互いを尊重しており、一緒に働く人々からもそのように尊敬されています。スクラムチームのメンバーは、正しいことを行い、困難な問題に取り組む勇気を持っています。

スクラムチームは、目標を達成し、お互いをサポートすることに尽力する
主なフォーカスは、これらの目標に向けて可能な限り最善の進歩を遂げるためのスプリントの作業

これらの価値観は、スクラムチームの仕事、行動、行動に関する方向性を与えます。下される決定、実行される手順、およびスクラムの使用方法は、これらの価値を弱めたり損なったりするのではなく、強化する必要があります。スクラムチームのメンバーは、スクラムイベントや成果物を操作しながら、その価値を学び探求します。これらの価値観がスクラムチームと一緒に働く人々によって具体化されると、透明性、検査、適応という経験的なスクラムの柱が生き返り、信頼を構築します。

5つの価値観は、スクラムチームの仕事、行動、行動に関する方向性を与える
価値観がスクラムチームによって具体化されると、透明性、検査、適応という経験的なスクラムの柱を活かせる

Scrum Team

スクラムの基本単位は、少人数のチームであるスクラムチームです。スクラムチームは、1 人のスクラムマスター、1 人のプロダクトオーナー、および開発者で構成されます。スクラムチーム内にはサブチームや階層はありません。これは、一度に 1 つの目標、つまり製品目標に集中する専門家の結束したユニットです。

基本単位は、少人数のチームであるスクラムチーム
スクラムチームは、下記で構成される
- スクラムマスタ（1人）
- PO（1人）
- 開発者
一度に、1つの目標、製品目標に集中する専門家のまとまったユニット

スクラムチームは部門横断型です。つまり、メンバーは各スプリントで価値を生み出すために必要なスキルをすべて備えています。また、自己管理能力も備えています。つまり、誰が、何を、いつ、どのように行うかを内部で決定します。

部門横断型
各スプリントで価値を生み出すために必要なスキルをすべて備えている
自己管理能力を有する
誰が、何を、いつ、どのように行うかを内部で決定する

スクラムチームは、機敏性を保つのに十分な規模と、スプリント内の重要な作業を完了するのに十分な規模 (通常は 10 人以下) です。一般に、小規模なチームの方がコミュニケーションがうまくいき、生産性が高いことがわかりました。スクラムチームが大規模になりすぎる場合は、それぞれが同じ製品に焦点を当てた、まとまりのある複数のスクラムチームに再編成することを検討する必要があります。したがって、同じ製品目標、製品バックログ、および製品所有者を共有する必要があります。

機敏性を保つために、十分な規模、重要な作業を完了するのに十分な規模で構成される
一般的に小規模のほうがコミュニケーションがうまくいき、生産性が高い
同じ製品目標、製品バックログ、製品所有者を共有する必要がある

スクラムチームは、利害関係者のコラボレーション、検証、メンテナンス、運用、実験、研究開発、その他必要とされるすべての製品関連の活動に責任を負います。彼らは組織によって構造化され、自らの仕事を管理する権限を与えられています。持続可能なペースでスプリントに取り組むことで、スクラムチームの集中力と一貫性が向上します。

スクラムチームの責任
- 利害関係者のコラボレーション
- 検証
- メンテナンス
- 運用
- 実験
- 研究開発
- その他必要な全ての製品関連活動
組織によって構造化される
自らの仕事を管理する権限を与えられている

スクラムチーム全体が、スプリントごとに価値のある有益なインクリメントを作成する責任があります。スクラムでは、スクラムチーム内で、開発者、プロダクトオーナー、スクラムマスターという 3 つの具体的な責任を定義します。

価値のある有益なインクリメントを作成する責任がある

Developers

開発者は、各スプリントで使用可能なインクリメントのあらゆる側面を作成することに専念するスクラムチームの人々です。
開発者に必要な具体的なスキルは広範囲にわたることが多く、仕事の分野によって異なります。ただし、開発者には常に以下の責任があります。

スプリントの計画、スプリントバックログを作成する。

完了の定義を遵守することで品質を浸透させます。

スプリント目標に向けて毎日の計画を調整します。そして、

プロフェッショナルとしてお互いに責任を持ちます。

開発者の責任
- スプリントの計画、バックログの作成
- 完了の定義の遵守
- スプリントの目標に向けて毎日の計画を調整
- プロフェッショナルとしてお互いに責任を持つ

Product Owner

プロダクトオーナーは、スクラムチームの作業から得られる製品の価値を最大化する責任があります。これがどのように行われるかは、組織、スクラムチーム、個人によって大きく異なる場合があります。
プロダクトオーナーは、次のような効果的なプロダクトバックログ管理にも責任を負います。

製品目標を策定し、明示的に伝達する。

プロダクトバックログ項目を作成し、明確に伝達する。

製品バックログ項目の注文。そして、

プロダクトバックログが透明で、可視化され、理解されるようにする。

POは、スクラムチームの作業から得られる製品の価値を最大化する責任がある
下記の責任を追う
- 製品目標を策定し、明確にし、伝達する
- プロダクトバックログ項目を作成し、明確に伝達する
- 製品バックログ項目へのオーダー
- プロダクトバックログが透明で、可視化され、理解されるようにする

プロダクト所有者は上記の作業を行うことも、責任を他の人に委任することもできます。いずれにせよ、プロダクトオーナーは引き続き責任を負います。

プロダクトオーナーが成功するには、組織全体が彼らの決定を尊重する必要があります。これらの決定は、プロダクトバックログの内容と順序、およびスプリントレビューでの検査可能なインクリメントを通じて確認できます。

POが成功するには、組織全体が決定を尊重する必要がある
- プロダクトバックログの内容と順序
- スプリントレビューでの検査可能なインクリメントを通じて確認できる

プロダクトオーナーは委員会ではなく、1人の人間です。プロダクトオーナーは、プロダクトバックログの多くの利害関係者のニーズを代表する場合があります。プロダクトバックログを変更したい場合は、プロダクトオーナーを説得することで変更できます。

POは、プロダクトバックログの多くの利害関係者のニーズを代表する必要がある
バックログを変更したい場合、POと交渉する

Scrum Master

スクラムマスターは、スクラムガイドで定義されているようにスクラムを確立する責任があります。これは、スクラムチーム内と組織内の両方で、全員がスクラムの理論と実践を理解できるように支援することによって実現されます。
スクラムマスターは、スクラムチームの有効性に対して責任を負います。これは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで実現されます。
スクラムマスターは、スクラムチームとより大きな組織に奉仕する真のリーダーです。

スクラムマスターは、スクラムガイドで定義されているようにスクラムを確立する責任がある
スクラムチームの有効性に対して責任を負う

スクラムマスターは、次のようなさまざまな方法でスクラムチームに貢献します。

チームメンバーの自己管理と部門横断的な指導。

スクラムチームが完了の定義を満たす高価値のインクリメントの作成に集中できるように支援します。

スクラムチームの進歩に対する障害を除去する。そして、

すべてのスクラムイベントが確実に実施され、前向きかつ生産的であり、期限内に維持されるようにします。

スクラムマスターがスクラムチームへの貢献
- チームメンバーの自己管理と部門横断的な指導
- スクラムチームが完了の定義を満たす高価値のインクリメントの作成に集中できるように支援
- 障害を除去
- スクラムイベントが確実に実施され、前向きかつ生産的、期限内に維持される

スクラムマスターは、次のようなさまざまな方法でプロダクトオーナーにサービスを提供します。

効果的な製品目標の定義と製品バックログ管理のための手法の発見を支援します。

スクラムチームが明確かつ簡潔なプロダクトバックログ項目の必要性を理解できるように支援します。

複雑な環境向けの経験に基づいた製品計画の確立を支援します。そして、

要求または必要に応じて関係者のコラボレーションを促進します。

POへサービスを提供
- 手法の発見の支援
- バックログ項目の必要性を理解できるように支援
- 複雑な環境向けの経験に基づく製品計画の確立の支援
- 要求、必要に応じて関係者のコラボレーションを促進

スクラムマスターは、次のようなさまざまな方法で組織に貢献します。

組織のスクラム導入を主導し、トレーニングし、指導する。

組織内でのスクラム実装の計画とアドバイス。

従業員と利害関係者が複雑な作業に対する経験的アプローチを理解し、実行できるよう支援する。そして、

利害関係者とスクラムチームの間の障壁を取り除く。

組織への貢献
- トレーニングと指導
- スクラム実装の計画とアドバイス

Scrum Events

スプリントは他のすべてのイベントのコンテナです。スクラムの各イベントは、スクラム成果物を検査して適応させる正式な機会です。これらのイベントは、必要な透明性を実現するために特別に設計されています。規定どおりにイベントを運営できないと、検査して適応する機会が失われます。スクラムではイベントを使用して、規則性を生み出し、スクラムで定義されていない会議の必要性を最小限に抑えます。
複雑さを軽減するために、すべてのイベントが同じ時間と場所で開催されるのが最適です。

スプリントは、他のすべてのイベントのコンテナ
各イベントは、スクラム成果物を検査して適応させる正式な機会
スクラムではイベントを使用して、規則性を生み出して、スクラムで定義されていない会議の必要性を最小限に抑える

The Sprint

スプリントはスクラムの心臓部であり、そこでアイデアが価値に変わります。
一貫性を保つために、これらのイベントは 1 か月以内の固定長のイベントです。新しいスプリントは、前のスプリントの終了直後に開始されます。

スプリントはスクラムの心臓部
一貫性を保つ必要がある
一ヶ月以内の固定長
新しいスプリントは、前のスプリントの終了直後に開始

スプリント計画、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブなど、製品目標を達成するために必要なすべての作業はスプリント内で行われます。
スプリント中:

スプリント目標を危険にさらすような変更は行われません。

品質は低下しません。

プロダクトバックログは必要に応じて調整されます。そして、

より多くのことを学ぶにつれて、範囲が明確になり、プロダクトオーナーと再交渉される可能性があります。

Sprint Planning、Daily Scrum、Sprint Review，Sprint RetrospectiveなどSprint内で行われる
スプリント中には
- スプリント目標を危険にさらすような変更は行われない
- 品質は低下しない
- バックログは必要に応じて調整される
- より多くのことを学ぶについて、POと再交渉される可能性がある

スプリントは、少なくとも暦月ごとに製品目標に向けた進捗状況の検査と適応を保証することで、予測可能性を可能にします。スプリントの期間が長すぎると、スプリントの目標が無効になり、複雑さが増し、リスクが増大する可能性があります。より短いスプリントを採用すると、より多くの学習サイクルを生成し、コストと労力のリスクをより短い時間枠に制限できます。各スプリントは短いプロジェクトとみなされる場合があります。

スプリント期間が長くなると、スプリントの目標が無効になり、複雑さが増し、リスクが増大する
短いと、より多くの学習サイクルを生成し、コストトロ右翼のリスクを短い時間枠に制限できる

バーンダウン、バーンアップ、累積フローなど、進行状況を予測するためのさまざまな手法が存在します。これらは有用であることが証明されていますが、経験主義の重要性に代わるものではありません。複雑な環境では何が起こるかわかりません。将来を見据えた意思決定に使用できるのは、すでに起こったことのみです。

バーンダウン、バーナップ、累積フローなど進捗を予測するための手法が存在する

スプリント目標が廃止された場合、スプリントはキャンセルされる可能性があります。プロダクトオーナーのみがスプリントをキャンセルする権限を持っています。

POのみスプリントをキャンセル権限を持つ

Sprint Planning

スプリント計画は、スプリントで実行する作業をレイアウトすることにより、スプリントを開始します。この結果として得られる計画は、スクラムチーム全体の共同作業によって作成されます。

プロダクトオーナーは、参加者が最も重要なプロダクトバックログ項目と、それらがプロダクト目標にどのように関連付けられるかについて話し合う準備ができていることを確認します。スクラムチームは、アドバイスを提供するために他の人をスプリントプランニングに招待することもあります。

スプリント計画では、次のトピックを取り上げます。

トピック 1: このスプリントに価値があるのはなぜですか?
プロダクトオーナーは、現在のスプリントにおいてプロダクトの価値と有用性をどのように高めることができるかを提案します。次に、スクラムチーム全体が協力して、スプリントがステークホルダーにとって価値がある理由を伝えるスプリント目標を定義します。スプリント目標は、スプリント計画が終了する前に確定する必要があります。

このスプリントに価値があるか明示する
- POはプロダクトの価値と有用性をどのように高めるか提案する
- スクラムチーム全体が協力して、スプリントがステークホルダーにとって価値がある理由を伝えるスプリント目標を定義する
- スプリント目標は、スプリント計画が終了する前に確定する

トピック 2: このスプリントで何ができるか?
プロダクトオーナーとの話し合いを通じて、開発者はプロダクトバックログから現在のスプリントに含める項目を選択します。スクラムチームはこのプロセス中にこれらの項目を改良することがあり、それにより理解と自信が高まります。
スプリント内でどれだけ完了できるかを選択するのは難しい場合があります。ただし、開発者が過去のパフォーマンス、今後のキャパシティ、および完了の定義について知れば知るほど、スプリントの予測に自信が持てるようになります。

バックログからスプリントに含める項目を選択する

トピック 3: 選ばれた仕事はどのように行われるのでしょうか?
選択したプロダクトバックログ項目ごとに、開発者は完了の定義を満たす増分を作成するために必要な作業を計画します。これは多くの場合、プロダクトバックログ項目を 1 日以下の小さな作業項目に分解することによって行われます。これをどのように行うかは開発者の独自の裁量に任されています。他の誰も、プロダクトバックログ項目を価値の増分に変える方法を教えてくれません。
スプリント目標、スプリント用に選択されたプロダクトバックログ項目、およびそれらを提供する計画を合わせてスプリントバックログと呼びます。
スプリント計画は、1 か月のスプリントで最大 8 時間にタイムボックス化されます。スプリントが短い場合、イベントは通常より短くなります。

開発者は必要な作業を計画する
プロダクトバックログ項目を1日以下の小さな作業項目に分解することで行われる
どのように行うか開発者の独自の裁量に任される

Daily Scrum

デイリースクラムの目的は、スプリント目標に向けた進捗状況を検査し、必要に応じてスプリントバックログを調整し、今後の計画作業を調整することです。

デイリースクラムの目的は、スプリントの目標に向けた進捗を検査し、必要なスプリントバックログを調整し、今後の計画作業を調整すること

デイリースクラムは、スクラムチームの開発者向けの 15 分間のイベントです。複雑さを軽減するために、スプリントの営業日ごとに同じ時間と場所で開催されます。プロダクトオーナーまたはスクラムマスターがスプリントバックログの項目に積極的に取り組んでいる場合、彼らは開発者として参加します。

15分間のイベント
営業日ごとに同時間同一の場所で開催される

開発者は、デイリースクラムがスプリント目標に向けた進捗に焦点を当て、次の日の作業に向けた実行可能な計画を作成する限り、必要な構造やテクニックを選択できます。これにより集中力が高まり、自己管理が向上します。

デイリースクラムはコミュニケーションを改善し、障害を特定し、迅速な意思決定を促進し、その結果、他の会議の必要性を排除します。

コミュニケーションを改善し、障害を特定し、迅速な意思決定を促進する

開発者が計画を調整できるのはデイリースクラムだけではありません。彼らは、スプリントの残りの作業の適応または再計画について、より詳細な議論を行うために 1 日中会議を行うことがよくあります。

Sprint Review

スプリントレビューの目的は、スプリントの結果を検査し、将来の適応を決定することです。スクラムチームは、主要な関係者に作業の結果を提示し、製品目標に向けた進捗状況について話し合います。

スプリントの結果を検査し、将来の適応を決定すること
主要な関係者に作業の結果を提示し、製品目標に向けた進捗について話し合う

イベント中、スクラムチームと関係者は、スプリントで何が達成されたか、環境で何が変わったかをレビューします。この情報に基づいて、参加者は次に何をすべきかを協力して検討します。新しい機会に合わせて製品バックログを調整することもできます。スプリントレビューは作業セッションであり、スクラムチームはそれをプレゼンテーションに限定することは避けるべきです。

スプリントで達成されたこと、環境で何が変わったかをレビューする

スプリントレビューはスプリントの最後から 2 番目のイベントで、1 か月のスプリントで最大 4 時間のタイムボックスが設定されています。スプリントが短い場合、イベントは通常より短くなります。

Sprint Retrospective

スプリントレトロスペクティブの目的は、品質と有効性を向上させる方法を計画することです。

レトロスペクティブの目的は、品質と有効性を向上させる方法を計画する

スクラムチームは、個人、インタラクション、プロセス、ツール、および完了の定義に関して、最後のスプリントがどのように行われたかを検査します。検査される要素は作業領域によって異なることがよくあります。彼らを迷わせた思い込みが特定され、その起源が探られます。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発生したか、それらの問題がどのように解決された (または解決されなかった) かについて話し合います。

スプリント中に何がうまくいき、どのような問題が発生したか、どのように解決されたか、解決されなかったか話し合う

スクラムチームは、その有効性を向上させるために最も役立つ変更を特定します。最も影響力のある改善にはできるだけ早く対処します。次のスプリントのスプリントバックログに追加されることもあります。

スプリントレトロスペクティブでスプリントは終了します。1 か月のスプリントでは最大 3 時間のタイムボックスが設定されています。スプリントが短い場合、イベントは通常より短くなります。

Scrum Artifacts

スクラムの成果物は作業または価値を表します。これらは、重要な情報の透明性を最大限に高めるように設計されています。したがって、それらを検査する全員が適応のための同じ基礎を持っています。

スクラムの成果物は、作業または価値を表す

各成果物には、進捗状況を測定できる透明性と焦点を高める情報を確実に提供するという取り組みが含まれています。

プロダクトバックログの場合、それはプロダクトの目標です。

スプリントバックログの場合、それはスプリントの目標です。

インクリメントの場合、それは完了の定義です。

各成果物には、進捗状況を測定できる透明性と商店を高める情報を確実に提供する

これらの取り組みは、スクラムチームとその関係者に対する経験主義とスクラムの価値観を強化するために存在します。

Product Backlog

製品バックログは、製品を改善するために必要なものを順番にまとめた、緊急のリストです。これは、スクラムチームが行う作業の唯一のソースです。

プロダクトバックログは、プロダクトを改善するために必要なものを順番にまとめた、緊急のリスト

スクラムチームが 1 つのスプリント内で実行できるプロダクトバックログ項目は、スプリント計画イベントで選択する準備ができているとみなされます。通常、活動を洗練した後にこの程度の透明性を獲得します。プロダクトバックログの洗練とは、プロダクトバックログ項目をより小さなより正確な項目に分割し、さらに定義する行為です。これは、説明、順序、サイズなどの詳細を追加する継続的なアクティビティです。属性は仕事の領域によって異なることがよくあります。

プロダクトバックログの洗練とは、プロダクトバックログ項目をより小さなより正確な項目に分割し、更に定義する行為
説明、順序、サイズ等詳細を追加する継続的なアクティビティ

作業を行う開発者はサイジングの責任を負います。プロダクト所有者は、開発者がトレードオフを理解して選択できるように支援することで、開発者に影響を与えることができます。

作業を行う開発者はサイジングの責任がある

Commitment: Product Goal

製品目標は、スクラムチームが計画を立てる目標として機能する製品の将来の状態を説明します。製品の目標は製品バックログにあります。プロダクトバックログの残りの部分は、プロダクト目標を達成する「内容」を定義するために現れます。

Product Goalは、プロダクトの将来の状態を説明する
製品バックログにある

製品は価値を提供する手段です。明確な境界、既知の利害関係者、明確に定義されたユーザーまたは顧客があります。製品は、サービス、物理的な製品、またはより抽象的なものである可能性があります。

製品目標は、スクラムチームの長期的な目標です。次の目標に取り組む前に、1 つの目標を達成 (または放棄) する必要があります。

Sprint Backlog

スプリントバックログは、スプリント目標 (なぜ)、スプリント用に選択された一連のプロダクトバックログ項目 (何を)、および増分を提供するための実行可能な計画 (方法) で構成されます。

下記で構成される
- Why:スプリント目標
- What:スプリントように選択された一連のプロダクトバックログ項目
- How:Incrementsを提供するための実行可能な計画

スプリントバックログは、開発者による開発者のための計画です。これは、開発者がスプリント目標を達成するためにスプリント中に実行する予定の作業をリアルタイムでわかりやすく表示するものです。その結果、スプリントバックログは、スプリント全体を通じて学習内容が増えるにつれて更新されます。デイリースクラムでの進捗状況を検査できる程度の詳細が含まれている必要があります。

開発者による開発者のための計画
開発者がスプリント目標を達成するためにスプリント中に実行する予定の作業をリアルタイムでわかりやすくする

Commitment: Sprint Goal
スプリント目標は、スプリントの単一の目標です。スプリント目標は開発者によるコミットメントですが、それを達成するために必要な正確な作業の点で柔軟性が得られます。また、スプリント目標は一貫性と焦点を生み出し、スクラムチームが個別の取り組みではなく協力することを奨励します。

スプリントの単一の目標
開発者によるコミットメント

スプリント目標は、スプリント計画イベント中に作成され、スプリントバックログに追加されます。開発者はスプリント中に作業する際、スプリントの目標を念頭に置きます。作業が予想と異なることが判明した場合は、プロダクトオーナーと協力して、スプリントの目標に影響を与えることなく、スプリント内のスプリントバックログの範囲を交渉します。

Sprint Planning中に作成される
スプリントバックログに追加される

Increment

インクリメントは、製品目標に向けた具体的な足がかりです。各増分は以前のすべての増分に追加され、徹底的に検証され、すべての増分が連携して動作することが保証されます。価値を提供するには、Increment が使用可能でなければなりません。

製品目標に向けた足がかり

スプリント内で複数の増分を作成できます。インクリメントの合計はスプリントレビューで提示されるため、経験主義が裏付けられます。ただし、増分はスプリントの終了前に関係者に提供される場合があります。スプリントレビューは、価値をリリースするための入り口と見なされるべきではありません。

作業は、「完了」の定義を満たさない限り、増分の一部とみなされません。

Commitment: Definition of Done

完了の定義は、製品に必要な品質基準を満たした場合のインクリメントの状態を正式に説明するものです。
プロダクトバックログ項目が「完了」の定義を満たした瞬間に、増分が発生します。

完了の定義により、インクリメントの一部としてどのような作業が完了したかを全員が共有して理解できるようになり、透明性が生まれます。プロダクトバックログ項目が完了の定義を満たしていない場合、リリースすることはできず、スプリントレビューで提示することさえできません。代わりに、将来の検討のためにプロダクトバックログに戻ります。

増分の完了の定義が組織の標準の一部である場合、すべてのスクラムチームは少なくともそれに従わなければなりません。それが組織の標準ではない場合、スクラムチームは製品に適した完了の定義を作成する必要があります。

開発者は、「完了」の定義に準拠する必要があります。複数のスクラムチームが製品に協力している場合、同じ「完了」の定義を相互に定義し、それに準拠する必要があります。

考察

普段、スクラムで開発を行っていますが、なんとなくやっていたことを改めて理解する事ができました。
Sprint BacklogやIncrementsはあまり理解ができなかったので、継続して学習していこうと思います。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up