Scrum.orgにおけるScrum基本解説 まとめ

overview

Home | Scrum.org

• Mission: Scrum.org aims to assist individuals and teams in tackling complex problems using Professional Scrum.
• Learning Platform: Offers training courses, certifications, and ongoing learning based on a common competency model.
• Professional Scrum Trainers (PSTs): Provides hands-on learning experiences led by vetted PSTs, with courses updated regularly for relevance and effectiveness.
• Certification Tests: Globally recognized tests assess Professional Scrum knowledge independently of how it was learned.
• Founding Background: Ken Schwaber founded Scrum.org to focus on improving Scrum knowledge and training, addressing issues like "Flaccid Scrum" and ensuring a consistent understanding of Scrum practices.

• Commitment to Advancement: Dedicated to advancing the profession to address the challenges of complex technologies and products through collaboration, creativity, continuous improvement, and community engagement.

• ミッション: Scrum.orgは、プロフェッショナルスクラムを使用して、個人とチームが複雑な問題を解決するのを支援することを目的としています。

• 学習プラットフォーム: 共通の能力モデルに基づいたトレーニングコース、認定資格、および継続的な学習機会を提供します。
• プロフェッショナルスクラムトレーナー（PSTs）: 知識と教育能力で審査されたPSTによる実践的な学習体験を提供し、関連性と効果を保証するためにコースを定期的に更新します。
• 認定テスト: どのように学んだかにかかわらず、プロフェッショナルスクラムの知識を評価するために、全世界で認識されているテスト。
• 創設の背景: ケン・シュワバーは、アジャイル宣言に続くスクラムの急速な普及の中で、スクラムの知識とトレーニングを改善するためのより集中的な取り組みが必要であると気づき、Scrum.orgを設立しました。これは、「フラシッドスクラム」の問題やスクラム実践の理解の不一致に対処するためです。
• 進歩へのコミットメント: 複雑な技術や製品の課題に対処するために、協力、創造性、継続的な改善、およびコミュニティとのエンゲージメントを通じて、職業を前進させることに専念しています。

keywords

• General Terms ⼀般⽤語
  • Scrum スクラム
• Theory 理論
  • Empiricism 経験主義
  • Transparency 透明性
  • Inspection 検査
  • Adaptation 適応
• Events イベント
  • Sprint スプリント
  • Sprint Planning スプリントプランニング
  • Daily Scrum デイリースクラム
  • Sprint Review スプリントレビュー
  • Sprint Retrospective スプリントレトロスペクティブ
• Roles 役割
  • Scrum Team スクラムチーム
  • Scrum Master スクラムマスター
  • Product Owner プロダクトオーナー
  • Developers 開発者
• Artifacts 作成物
  • Product Backlog プロダクトバックログ
  • Sprint Backlog スプリントバックログ
  • Increment インクリメント
• Misc その他
  • Definition of Done 完成の定義

tutorial

1 What is Scrum? | Scrum.org

Title: What is Scrum?

• Agile Framework: Scrum is an agile framework aimed at enhancing team collaboration on complex projects through breaking down work into smaller, manageable pieces.
• Continuous Improvement: It allows for continuous feedback, experimentation, and improvement.
• Incremental Delivery: Encourages incremental delivery of value in a collaborative setting.
• Scrum Framework Components: Includes a Scrum Team (Product Owner, Scrum Master, Developers), five events, and three artifacts for effective progress.
• Empiricism Principles: Based on empiricism, emphasizing transparency, inspection, and adaptation.
• Core Values: Supported by values of courage, focus, commitment, respect, and openness to foster team trust.
• Sprints: Work increments delivered in Sprints, short cycles of one month or less.
• Professional Scrum: Requires a mindset shift and supportive environment for effective Scrum implementation.
• Learning and Community Support: Offers resources like books, presentations, and forums for deeper Scrum practice engagement.

タイトル: スクラムとは何か？

• アジャイルフレームワーク: スクラムは、作業をより小さく管理しやすい部分に分けることにより、複雑なプロジェクトにおけるチーム協力を高めることを目的としたアジャイルフレームワークです。
• 継続的改善: 継続的なフィードバック、実験、改善を可能にします。
• インクリメンタルデリバリー: 協力的な環境で価値の段階的な提供を奨励します。
• スクラムフレームワークの構成要素: スクラムチーム（プロダクトオーナー、スクラムマスター、開発者）、5つのイベント、効果的な進捗のための3つの成果物が含まれます。
• 経験主義の原則: 経験主義に基づき、透明性、検査、適応を強調します。
• 核心価値: 勇気、集中、コミットメント、尊重、開放性の価値を支持し、チーム内の信頼を育成します。
• スプリント: 1ヶ月未満の短いサイクルであるスプリントで、作業のインクリメントが提供されます。
• プロフェッショナルスクラム: 効果的なスクラム実装のために、マインドセットの変化と支援環境が必要です。
• 学習とコミュニティサポート: スクラム実践の深化のための書籍、プレゼンテーション、フォーラムなどのリソースを提供します。

2 The Scrum Team

The Scrum Team

• Composition: One Scrum Master, one Product Owner, and Developers.
• Structure: No sub-teams or hierarchies; a cohesive unit.
• Functionality: Cross-functional and self-managing.
• Size: Typically 10 or fewer people.
• Productivity: Smaller teams communicate better and are more productive.
• Responsibility: Responsible for all product-related activities.
• Accountability: Accountable for creating a valuable, useful Increment every Sprint.
• Specific Accountabilities: Developers, Product Owner, and Scrum Master.

スクラムチーム

• 構成: スクラムマスター1人、プロダクトオーナー1人、開発者。
• 構造: サブチームや階層なし; 一体のユニット。
• 機能性: クロスファンクショナルで自己管理。
• サイズ: 通常10人以下。
• 生産性: 小さいチームはコミュニケーションがよく、より生産的。
• 責任: すべての製品関連の活動に責任を持つ。
• 説明責任: 価値のある、有用なインクリメントを各スプリントごとに作成すること。
• 特定の責任: 開発者、プロダクトオーナー、スクラムマスター。

2.1 What is a Scrum Master?

The Accountabilities of the Scrum Master

• Establishing Scrum: Helping everyone understand Scrum theory and practice.
• Coaching and Mentoring: Utilizing soft skills to guide and support the Scrum Team and organization.
• Facilitating Success: Offering assistance and removing impediments to the team's progress.
• Improving Team Effectiveness: Helping the team improve their collaboration and value creation.

スクラムマスターの責務

• スクラムの確立: スクラム理論と実践を皆が理解するよう助ける。
• コーチングとメンタリング: スクラムチームと組織を導き、支援するためのソフトスキルを活用する。
• 成功の促進: チームの進捗に対する支援と障害の除去を行う。
• チーム効果の向上: チームの協働と価値創造の改善を助ける。

What does a Scrum Master do?

• For the Scrum Team: Coaches on self-management and cross-functionality, helps focus on high-value Increments, influences impediment removal, ensures productive Scrum events.
• For the Product Owner: Assists in defining Product Goals and managing the Product Backlog, facilitates stakeholder collaboration.
• For the Organization: Leads Scrum adoption, coaches on empirical approaches for complex work, removes barriers between stakeholders and Scrum Teams.
• Scrum Master Stances: Adapts roles such as Servant Leader, Facilitator, Coach, Manager, Mentor, Teacher, Impediment Remover, or Change Agent depending on the situation.

スクラムマスターは何をするか？

• スクラムチームのために: 自己管理とクロスファンクショナリティのコーチング、高価値のインクリメントに焦点を当てる、進捗の障害を取り除く影響、生産的なスクラムイベントを保証する。
• プロダクトオーナーのために: プロダクトゴールの定義とプロダクトバックログ管理の技術を見つける、ステークホルダーの協力を促進する。
• 組織のために: スクラムの採用をリードし、複雑な作業に対する経験的アプローチを理解し実施する、ステークホルダーとスクラムチーム間の障壁を取り除く。
• スクラムマスターのスタンス: 状況に応じて、サーバントリーダー、ファシリテーター、コーチ、マネージャー、メンター、教師、障害除去者、変革エージェントなどの役割を適応する。

2.2 What is a Product Owner?

The Accountabilities of the Product Owner

• Maximizing Value: Accountable for maximizing the product's value.
• Providing Clarity: Provides clarity on the product's vision and goal.
• Identifying and Measuring Value: Identifies, measures, and maximizes value throughout the product lifecycle.
• Effective Product Backlog Management: Involves developing the Product Goal, creating Product Backlog Items, ordering them, and ensuring transparency and understanding.

プロダクトオーナーの責務

• 価値の最大化: 製品の価値を最大化することに責任を持つ。
• 明確性の提供: 製品のビジョンと目標についてチームに明確性を提供する。
• 価値の特定と測定: 製品ライフサイクル全体を通じて価値を特定、測定、最大化する。
• 効果的なプロダクトバックログ管理: プロダクトゴールの開発、プロダクトバックログアイテムの作成と整理、透明性と理解の確保を含む。

What does a Product Owner do?

• Product Goal Communication: Develops and communicates the Product Goal.
• Product Backlog Items Creation: Creates and communicates Product Backlog Items.
• Product Backlog Management: Orders Product Backlog Items and ensures their transparency and visibility.
• Decision Making: Makes decisions regarding the product and its backlog.
• Stakeholder Representation: Represents the needs of various stakeholders in the Product Backlog.

プロダクトオーナーは何をするのか？

• プロダクトゴールの伝達: プロダクトゴールを開発し、伝達する。
• プロダクトバックログアイテムの作成: プロダクトバックログアイテムを作成し、伝達する。
• プロダクトバックログの管理: プロダクトバックログアイテムを整理し、その透明性と可視性を確保する。
• 意思決定: 製品及びそのバックログに関する決定を行う。
• ステークホルダーの代表: プロダクトバックログで様々なステークホルダーのニーズを代表する。

Product Owner Stances

• Visionary: Communicates the product vision and strategy.
• Collaborator: Works with the Scrum Team to define goals.
• Customer Representative: Acts as a bridge between the customers and the Scrum Team.
• Decision Maker: Makes daily decisions to guide the product development.
• Experimenter and Influencer: Tests new ideas and influences the direction of the product.

プロダクトオーナーのスタンス

• ビジョナリー: 製品のビジョンと戦略を伝える。
• コラボレーター: スクラムチームと協力して目標を定義する。
• 顧客代表: 顧客とスクラムチームの間の橋渡しを行う。
• 意思決定者: 製品開発を導く日々の決定を行う。
• 実験者および影響力者: 新しいアイデアをテストし、製品の方向性に影響を与える。

2.3 What is a Developer?

The Accountabilities of a Developer

• Sprint Planning: Creating a plan for the Sprint, the Sprint Backlog.
• Quality Assurance: Instilling quality by adhering to a Definition of Done.
• Adapting Plans: Adapting their plan each day toward the Sprint Goal.
• Professional Accountability: Holding each other accountable as professionals.
• Embracing Practices: May include facilitation, mentoring, teaching, and coaching.

デベロッパーの責務

• スプリント計画: スプリントの計画を立てる、スプリントバックログを作成する。
• 品質保証: 定義された完成の基準に従って品質を保証する。
• 計画の適応: 毎日、スプリント目標に向けて計画を適応させる。
• 専門的な説明責任: 互いにプロフェッショナルとして責任を持つ。
• 習慣の受入れ: ファシリテーション、メンタリング、教育、コーチングを含む可能性がある。

What does a Developer do?

• Focus on Product Work: Can involve software or non-software product work.
• Diverse Skills: May include design, build, test, or ship the product.
• Sprint Backlog Management: Creating and managing the Sprint Backlog.
• Quality Control: Ensuring quality through the Definition of Done.
• Daily Adaptation: Adapting plans daily to achieve the Sprint Goal.
• Peer Accountability: Holding each other accountable as professionals.
• Facilitation and Teaching: May involve facilitating events or teaching skills to team members.

デベロッパーは何をするのか？

• 製品作業に焦点を当てる: ソフトウェアまたは非ソフトウェア製品作業を含む可能性がある。
• 多様なスキル: 設計、構築、テスト、または製品の出荷を含む可能性がある。
• スプリントバックログの管理: スプリントバックログの作成と管理。
• 品質管理: 完成の定義を通じて品質を確保する。
• 日々の適応: スプリント目標を達成するために計画を日々適応させる。
• 仲間の説明責任: プロフェッショナルとして互いに責任を持つ。
• ファシリテーションと教育: イベントのファシリテーションやチームメンバーへのスキル教育を含む可能性がある。

3 The Scrum Events

The Scrum Events

• Sprint Container: The Sprint acts as a container for all other events.
• Formal Opportunities: Each event is an opportunity to inspect and adapt Scrum artifacts.
• Transparency Enablement: Events are designed to enable the required transparency.
• Consequences of Failure: Failing to operate events as prescribed results in lost opportunities.
• Regularity and Minimization: Events create regularity and minimize the need for non-Scrum meetings.
• Consistency: Ideally, all events are held at the same time and place to reduce complexity.

スクラムのイベント

• スプリントコンテナ: スプリントは他のすべてのイベントのコンテナとして機能します。
• 公式の機会: 各イベントはスクラムアーティファクトを検査し、適応するための機会です。
• 透明性の促進: イベントは必要な透明性を促進するために特別に設計されています。
• 失敗の結果: 指示された通りにイベントを運用しないと、検査し適応する機会を失います。
• 定期性と最小化: イベントは定期性を生み出し、スクラムに定義されていない会議の必要性を最小限に抑えます。
• 一貫性: 理想的には、すべてのイベントは複雑さを減らすために同じ時間と場所で開催されます。

3.1 What is a Sprint?

What is a Sprint?

• Heartbeat of Scrum: Where ideas are turned into value.
• Fixed Length: Lasts one month or less for consistency and short feedback iterations.
• Comprehensive: Encompasses all other Scrum events including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective.
• Continuous Cycle: A new Sprint starts immediately after the conclusion of the previous one.
• Adaptation and Learning: Enables predictability and continuous improvement towards the Product Goal and Sprint Goal.

スプリントとは何か？

• スクラムの鼓動: アイデアを価値に変える場所。
• 固定期間: 一貫性を確保し、フィードバックの短い反復のために1ヶ月以下。
• 包括的: スプリント計画、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含むすべてのスクラムイベントを包含する。
• 連続するサイクル: 前のスプリントの結論の直後に新しいスプリントが始まる。
• 適応と学習: プロダクトゴールとスプリントゴールに向けての予測可能性と継続的な改善を可能にする。

During the Sprint:

• No Goal Endangerment: No changes made that endanger the Sprint Goal.
• Quality Maintenance: Quality levels are maintained throughout the Sprint.
• Backlog Refinement: The Product Backlog is refined as necessary.
• Scope Clarification: Scope may be renegotiated with the Product Owner as more is learned.

スプリント中において:

• ゴール危険回避: スプリントゴールを危険にさらす変更は行わない。
• 品質維持: スプリントを通じて品質レベルが維持される。
• バックログの洗練: 必要に応じてプロダクトバックログが洗練される。
• スコープの明確化: 学習に応じてプロダクトオーナーとスコープが再交渉されることがある。

Empiricism during the Sprint:

• Learning by Doing: Embracing empiricism for continuous improvement.
• Forward Decisions: Based on experiences and what has already happened.
• Forecasting Practices: Utilizing burn-downs, burn-ups, or cumulative flows without replacing the importance of empiricism.

スプリント中の経験主義:

• 実践による学習: 継続的な改善のための経験主義を受け入れる。
• 前向きな決定: 経験と過去に起こったことに基づく。
• 予測実践: バーンダウン、バーンアップ、累積フローを利用するが、経験主義の重要性を置き換えるものではない。

3.2 What is Sprint Planning?

What is Sprint Planning?

• Initiation of Sprint: Sprint Planning starts the Sprint by outlining the work.
• Collaborative Effort: Involves the entire Scrum Team in creating the plan.
• Product Owner's Role: Prepares the team to discuss key Product Backlog items and their alignment with the Product Goal.
• Invitation for Advice: May include external advisers for additional insights.
• Sprint Goal Definition: Collaboratively defining why the Sprint is valuable.
• Selection of Work: Developers select Product Backlog items for the Sprint, refining them for clarity and confidence.
• Work Planning: Developers plan how to accomplish the selected work, adhering to the Definition of Done.
• Sprint Backlog Creation: The Sprint Goal, selected items, and the delivery plan constitute the Sprint Backlog.
• Timeboxed Event: Max eight hours for a one-month Sprint, shorter for less.

スプリントプランニングとは何か？

• スプリントの開始: スプリントプランニングはスプリントに取り組む作業を概説して開始します。
• 共同の取り組み: スクラムチーム全体が計画作成に関わります。
• プロダクトオーナーの役割: チームがプロダクトゴールに沿った重要なプロダクトバックログアイテムを議論できるよう準備します。
• アドバイスのための招待: 追加の洞察のために外部のアドバイザーを招待することがあります。
• スプリントゴールの定義: スプリントが利害関係者にとってなぜ価値があるのかを共同で定義します。
• 作業の選択: 開発者はスプリントのためのプロダクトバックログアイテムを選択し、それらを明確かつ自信を持って洗練します。
• 作業計画: 開発者は選択した作業を達成するための計画を立て、完成の定義を守ります。
• スプリントバックログの作成: スプリントゴール、選択されたアイテム、およびそれらの配信計画をスプリントバックログとしてまとめます。
• タイムボックスイベント: 1か月のスプリントの場合は最大8時間、それ以下の場合は通常短くなります。

3.3 What is a Daily Scrum?

What is a Daily Scrum?

• Purpose: Inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.
• Duration: A 15-minute event for the Developers.
• Consistency: Held at the same time and place every working day of the Sprint.
• Participants: Developers, with the Product Owner and Scrum Master as Developers if they work on Sprint Backlog items.
• Structure and Techniques: Selected by Developers to focus on progress and plan the next day of work.
• Benefits: Improves communications, identifies impediments, promotes quick decision-making, and eliminates the need for other meetings.
• Continuous Adjustment: Allows for ongoing discussions and re-planning throughout the Sprint.
• Role of the Scrum Master: Ensures the meeting takes place and teaches how to keep it within the 15-minute time-box.

デイリースクラムとは何か？

• 目的: スプリントゴールに向けた進捗を検査し、必要に応じてスプリントバックログを適応させる。
• 期間: 開発者のための15分のイベント。
• 一貫性: スプリントの毎営業日に同じ時間と場所で開催される。
• 参加者: 開発者、スプリントバックログのアイテムに取り組む場合はプロダクトオーナーとスクラムマスターも開発者として参加。
• 構造と技術: 開発者が進捗に焦点を当て、次の日の作業計画を立てるために選択する。
• 利点: コミュニケーションを改善し、障害を特定し、迅速な意思決定を促進し、他の会議の必要性をなくす。
• 継続的な調整: スプリントを通じて継続的な議論と再計画を可能にする。
• スクラムマスターの役割: 会議が行われるようにし、15分のタイムボックス内で保持する方法を教える。

3.4 What is a Sprint Review?

What is a Sprint Review?

• Purpose: To inspect the outcome of the Sprint and determine future adaptations.
• Presentation: The Scrum Team presents their work to stakeholders and discusses progress toward the Product Goal.
• Collaboration: Team and stakeholders review accomplishments and environmental changes to decide next steps.
• Product Backlog Adjustment: May be updated to reflect new opportunities.
• Working Session: Not limited to a presentation; involves active collaboration.
• Timing: Second to last event of the Sprint, timeboxed to a maximum of four hours for a one-month Sprint.
• Attendees: Scrum Team and key stakeholders invited by the Product Owner.
• Discussion: Includes what was done, challenges faced, and problem-solving.
• Demonstration: Developers show completed work and answer questions.
• Planning Input: Provides valuable input for subsequent Sprint Planning.
• Marketplace Review: Discussion on how changes in the marketplace or potential use of the product might influence next steps.
• Outcome: A revised Product Backlog for the next Sprint and adjustments based on new opportunities.

スプリントレビューとは何か？

• 目的: スプリントの結果を検査し、将来の適応を決定する。
• プレゼンテーション: スクラムチームが作業結果を利害関係者に提示し、プロダクトゴールに向けた進捗を議論する。
• 協働: チームと利害関係者が成果と環境の変化をレビューし、次のステップを決定する。
• プロダクトバックログの調整: 新しい機会を反映するように更新されることがある。
• 作業セッション: プレゼンテーションに限定されず、積極的な協働を含む。
• タイミング: スプリントの最後から二番目のイベントで、1か月のスプリントに対して最大4時間まで。
• 出席者: プロダクトオーナーによって招待されたスクラムチームと主要な利害関係者。
• 議論: 完了した作業、直面した課題、問題解決について議論する。
• デモンストレーション: 開発者が完了した作業を示し、質問に答える。
• 計画への入力: 次のスプリント計画に貴重な入力を提供する。
• 市場レビュー: 製品の市場や潜在的な使用法の変化が次のステップにどう影響するかを議論する。
• 結果: 次のスプリントのための見直されたプロダクトバックログと、新しい機会に基づく調整。

3.5 What is a Sprint Retrospective?

What is a Sprint Retrospective?

• Purpose: To plan ways to increase quality and effectiveness.
• Inspection: Evaluates the last Sprint's individuals, interactions, processes, tools, and Definition of Done.
• Discussion: Covers what went well, encountered problems, and solutions.
• Improvement Identification: Identifies helpful changes to improve effectiveness.
• Impactful Improvements: Addressed as soon as possible, potentially added to the next Sprint Backlog.
• Concluding Event: Concludes the Sprint, timeboxed to a maximum of three hours for a one-month Sprint.
• Key Discussions: What went well, what could be improved, and commitments to improvement in the next Sprint.
• Scrum Master's Role: Encourages process and practice improvements for the next Sprint.
• Outcome: Identification of improvements to implement in the next Sprint, focusing on inspection and adaptation.

スプリントレトロスペクティブとは何か？

• 目的: 品質と効果を高める方法を計画する。
• 検査: 前スプリントの個人、相互作用、プロセス、ツール、および完了の定義を評価する。
• 議論: うまくいったこと、遭遇した問題、解決策についての話し合い。
• 改善の特定: 効果を高めるための有益な変更を特定する。
• 影響の大きな改善: 可能な限り早急に対処され、次のスプリントバックログに追加されることもある。
• 終結イベント: スプリントを終了し、1か月のスプリントに対して最大3時間までという時間枠で行われる。
• 主な議論: うまくいったこと、改善できること、次のスプリントでの改善へのコミットメント。
• スクラムマスターの役割: 次のスプリントのためのプロセスと実践の改善を促す。
• 成果: 次のスプリントで実装する改善点の特定、検査と適応に焦点を当てる。

4 The Scrum Artifacts

The Scrum Artifacts

• Transparency and Inspection: Artifacts offer transparency and allow for inspection and adaptation.
• Representation: Represent work or value, designed to maximize key information transparency.
• Commitments:
  • Product Backlog: Committed to the Product Goal.
  • Sprint Backlog: Committed to the Sprint Goal.
  • Increment: Committed to the Definition of Done.
• Purpose: Enhance transparency, focus, and measure progress.
• Empiricism and Values: Commitments reinforce empiricism and Scrum values among the team and stakeholders.

スクラムの成果物

• 透明性と検査: 成果物は透明性を提供し、検査と適応を可能にする。
• 表現: 作業または価値を表し、重要な情報の透明性を最大化するように設計されている。
• コミットメント:
  • プロダクトバックログ: プロダクトゴールに対するコミットメント。
  • スプリントバックログ: スプリントゴールに対するコミットメント。
  • インクリメント: 完成の定義に対するコミットメント。
• 目的: 透明性と焦点を高め、進捗を測定する。
• 経験主義と価値観: コミットメントはチームと利害関係者の間で経験主義とスクラムの価値観を強化する。

4.1 What is a Product Backlog?

What is a Product Backlog?

• Emergent List: An ordered list of what is needed to improve the product.
• Single Source of Work: The only source of work for the Scrum Team.
• Readiness for Sprint: Items ready for Sprint Planning after refining activities.
• Refinement Activity: Ongoing activity to break down items into smaller, more precise items.
• Developer Sizing: Developers are responsible for sizing, with input from the Product Owner.
• Collaboration Across Teams: Multiple Scrum Teams may work on the same product with one Product Backlog.
• Commitment to Product Goal: Describes a future state of the product as a target for planning.

プロダクトバックログとは何か？

• 発展的リスト: 製品の改善に必要な項目の順序付けられたリスト。
• 作業の唯一の源泉: スクラムチームによる作業の唯一の源泉。
• スプリントの準備: 精緻化活動の後、スプリントプランニングで選択される準備ができたアイテム。
• 精緻化活動: 項目をより小さく、より正確な項目に分解し、さらに定義する継続的な活動。
• 開発者によるサイジング: 開発者がサイジングを担当し、プロダクトオーナーからの入力を受ける。
• チーム間の協力: 複数のスクラムチームが同じ製品に取り組む場合、一つのプロダクトバックログを使用する。
• プロダクトゴールへのコミットメント: 計画に対する目標としての製品の将来の状態を記述する。

4.2 What is a Product Goal?

What is a Product Goal?

• Product Goal Commitment: Associated with the Product Backlog as its commitment.
• Context Provider: Gives context to the Product Backlog, describing the future state of the product.
• Long-term Objective: Serves as the long-term target for the Scrum Team.
• Directional Statement: Offers direction and purpose for the Scrum Team and stakeholders.
• Visibility: Made visible through the Product Backlog, with the Product Owner accountable for its creation and communication.
• Evolving Nature: Evolves as the Scrum Team learns and receives feedback.
• Uniqueness: Only one Product Goal for the Product Backlog at a time, clear and concise.
• Incremental Progress: Moves toward the Product Goal through each Sprint Goal.
• Sprint Review Role: Inspected during Sprint Review to evaluate progress and influence future Sprint Planning.

プロダクトゴールとは何か？

• プロダクトゴールのコミットメント: プロダクトバックログに関連付けられたコミットメント。
• コンテキストの提供者: プロダクトバックログにコンテキストを提供し、製品の将来の状態を説明する。
• 長期的な目標: スクラムチームの長期的な目標として機能する。
• 方向性の声明: スクラムチームと利害関係者に方向性と目的を提供する。
• 可視性: プロダクトバックログを通じて可視化され、プロダクトオーナーがその作成とコミュニケーションに責任を持つ。
• 進化する性質: スクラムチームが学習しフィードバックを受け取るにつれて進化する。
• ユニークさ: 一度に一つのプロダクトゴールのみで、明確かつ簡潔である。
• 段階的な進捗: 各スプリントゴールを通じてプロダクトゴールに向かって進む。
• スプリントレビューの役割: スプリントレビュー中にインクリメントとプロダクトゴールに向けた進捗が検査され、将来のスプリントプランニングに影響を与える。

4.3 What is a Sprint Backlog?

What is a Sprint Backlog?

• Composition: Includes the Sprint Goal, selected Product Backlog items, and an actionable plan for the Increment.
• Purpose: A plan by and for the Developers to achieve the Sprint Goal.
• Visibility and Update: Highly visible, updated throughout the Sprint as learning progresses.
• Detail Level: Detailed enough for progress inspection in the Daily Scrum.
• Commitment: Sprint Goal as the single objective, providing focus and coherence.

スプリントバックログとは何か？

• 構成: スプリントゴール、選択されたプロダクトバックログアイテム、インクリメントのための実行可能な計画を含む。
• 目的: スプリントゴールを達成するための開発者による計画。
• 可視性と更新: 学習が進むにつれてスプリント中に更新される高い可視性を持つ。
• 詳細レベル: デイリースクラムでの進捗検査に十分な詳細を持つ。
• コミットメント: 単一の目的としてのスプリントゴールで、焦点と一体感を提供する。

Increment

• Increment: A concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

• Multiple Increments: Within a Sprint, multiple Increments may be created. The sum of the Increments is presented at the Sprint Review, supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should not be considered a gate to releasing value.

• Definition of Done: Work cannot be considered part of an Increment unless it meets the Definition of Done.

Increment (インクリメント)

• Increment: プロダクトゴールに向かう具体的なステップ。各インクリメントは、以前のすべてのインクリメントに加算され、徹底的に検証され、全てのインクリメントが一緒に機能することを保証する。価値を提供するためには、インクリメントは使用可能でなければならない。
• 複数のインクリメント: スプリント内で複数のインクリメントが作成されることがある。インクリメントの合計はスプリントレビューで提示され、経験主義をサポートする。しかし、インクリメントはスプリントの終わり前に利害関係者に提供されることがある。スプリントレビューは価値をリリースするゲートとして考えるべきではない。
• 完了の定義: 完了の定義を満たさない限り、作業はインクリメントの一部とは見なされない。

4.4 What is a Sprint Goal?

What is a Sprint Goal?

• Sprint Goal Commitment: Associated commitment with the Sprint Backlog in the Scrum Guide.
• Single Objective: The single objective for the Sprint, providing flexibility and focus.
• Cohesiveness and Focus: Encourages the Scrum Team to work together.
• Creation: Created during Sprint Planning and added to the Sprint Backlog.
• Adaptability: If work evolves, scope may be negotiated without affecting the Sprint Goal.
• Immutability: The Sprint Goal does not change during the Sprint, except in cases where it's invalidated.
• Characteristics: Should be clear, attainable, and aligned with incremental value delivery.
• Visibility and Inspection: Must be visible and regularly inspected during the Daily Scrum.

スプリントゴールとは何か？

• スプリントゴールのコミットメント: スクラムガイドにおけるスプリントバックログに関連付けられたコミットメント。
• 単一の目的: スプリントのための単一の目的で、柔軟性と焦点を提供する。
• 一体感と焦点: スクラムチームが一緒に働くことを奨励する。
• 作成: スプリントプランニング中にスクラムチームによって作成され、スプリントバックログに追加される。
• 適応性: 作業が進化する場合、スプリントゴールに影響を与えずにスコープを交渉することができる。
• 不変性: スプリントゴールはスプリント中に変更されないが、無効になる場合がある。
• 特性: 明確で達成可能であり、インクリメンタルな価値提供に合わせて作成されるべきである。
• 可視性と検査: デイリースクラムでの進捗の検査を通じて、常に可視化され、焦点を維持する必要がある。

4.5 What is an Increment?

What is an Increment?

• Definition: A concrete stepping stone toward the Product Goal.
• Additive and Verified: Each Increment builds upon previous ones and is thoroughly verified.
• Usability: Must be usable to provide value.
• Multiple Increments: Can be created within a Sprint.
• Presentation: Sum of Increments is presented at the Sprint Review, supporting empiricism.
• Delivery: An Increment may be delivered before the Sprint ends.
• No Gatekeeping: Sprint Review is not a gate to releasing value.
• Definition of Done: Work is part of an Increment only if it meets the Definition of Done.

インクリメントとは何か？

• 定義: プロダクトゴールに向かう具体的なステップ。
• 加算性と検証: 各インクリメントは以前のものに加えられ、徹底的に検証される。
• 使用可能性: 価値を提供するためには使用可能でなければならない。
• 複数のインクリメント: スプリント内で複数作成可能。
• 提示: インクリメントの合計はスプリントレビューで提示され、経験主義を支持する。
• 納品: スプリント終了前に利害関係者にインクリメントを納品できる。
• ゲートキーピングなし: スプリントレビューは価値のリリースのゲートとして考えられるべきではない。
• 完了の定義: 作業は完了の定義を満たした場合にのみインクリメントの一部とみなされる。

4.6 What is a Definition of Done?

What is a Definition of Done?

• Definition: The commitment by the Developers for the Increment, outlining the required characteristics and standards for release.
• Purpose: Ensures transparency and a shared understanding of completion standards.
• Requirement: If a Product Backlog Item does not meet the Definition of Done, it cannot be released.
• Organizational Standards: May include standards of the organization, with teams elaborating on additional needed standards.
• Creation Process: Collaboratively defined by the team, possibly incorporating brainstorming activities.

完了の定義とは何か？

• 定義: インクリメントに対する開発者のコミットメントであり、リリースに必要な特性と基準を概説しています。
• 目的: 透明性を確保し、完了基準に対する共有理解を提供する。
• 要件: プロダクトバックログアイテムが完了の定義を満たさない場合、まだリリースできない。
• 組織の基準: 組織の基準を含む場合があり、チームは製品に必要な追加の基準を詳述する。
• 作成プロセス: チームによって共同で定義され、ブレインストーミング活動を取り入れることもある。

How to Create a Definition of Done

• Creating Transparency: Provides everyone with a shared understanding of the standards required for work as part of the Increment. This can involve the team working collaboratively to document all necessary conditions or employing brainstorming techniques to ensure comprehensive coverage.
• Examples: Below are some examples of what might be included in a Definition of Done:
  • For a Marketing Case Study:
    • Meets featured client branding guidelines.
    • Written in AP style.
    • Reviewed by the featured client and feedback received.
    • Feedback implemented.
    • Final Draft Approved by Client.
  • For a Health-Focused Software Application:
    • All testing completed.
    • No known defects.
    • Code review completed and passed.
    • Meets HIPAA Compliance standards.
    • Meets general security requirements.
• Once all items in the Definition of Done are checked off and complete, the Increment is considered Done. Scrum is used for complex work, so the Definition of Done may include many complex characteristics to make it stringent.

完了の定義の作成方法

• 透明性の創出: インクリメントの一部として要求される作業の基準について、全員に共有理解を提供する。
• 例: 完了の定義に含まれる項目の例を以下に示す。
  • マーケティングケーススタディの書き方に関する完了の定義の例:
    • クライアントのブランドガイドラインを満たす
    • APスタイルで書かれている
    • 特集されたクライアントによってレビューされ、フィードバックが受け取られている
    • フィードバックが実装されている
    • クライアントによって最終草稿が承認されている
  • 健康に焦点を当てたソフトウェアアプリケーションの完了の定義の例:
    • すべてのテストが完了している
    • 既知の欠陥がない
    • コードレビューが完了し、合格している
    • HIPAAコンプライアンス基準を満たしている
    • 一般的なセキュリティ要件を満たしている
• 完了の定義のすべての項目がチェックオフされ、完了している場合、このインクリメントは完了と見なされる。もちろん、スクラムは複雑な作業に使用され、完了の定義に多くの複雑な特性が追加されることがあります。

materials

• Scrum Guide

Scrum Guide | Scrum Guides

• Scrum Guide in Japanese

2020-Scrum-Guide-Japanese.pdf