目次スクラムガイドの目的... 3 スクラムの定義... 3 スクラムの理論... 3 スクラムの価値基準... 4 スクラムチーム... 5 プロダクトオーナー... 5 開発チーム... 5 スクラムマスター... 6 スクラムイベント... 7 スプリント... 7 スプリントプランニング.

Size: px

Start display at page:

Download "目次スクラムガイドの目的... 3 スクラムの定義... 3 スクラムの理論... 3 スクラムの価値基準... 4 スクラムチーム... 5 プロダクトオーナー... 5 開発チーム... 5 スクラムマスター... 6 スクラムイベント... 7 スプリント... 7 スプリントプランニング."

いとはえいさか
5 years ago
Views:

1 スクラムガイドスクラム完全ガイド : ゲームのルール 2016 年 7 月 Developed and sustained by Ken Schwaber and Jeff Sutherland

2 目次スクラムガイドの目的... 3 スクラムの定義... 3 スクラムの理論... 3 スクラムの価値基準... 4 スクラムチーム... 5 プロダクトオーナー... 5 開発チーム... 5 スクラムマスター... 6 スクラムイベント... 7 スプリント... 7 スプリントプランニング... 8 デイリースクラムスプリントレビュースプリントレトロスペクティブスクラムの作成物プロダクトバックログスプリントバックログインクリメント作成物の透明性完成(Done) の定義最後に謝辞人々歴史翻訳 Page 2

3 スクラムガイドの目的スクラムは複雑なプロダクトを開発維持するためのフレームワークである本ガイドではスクラムの定義を説明するスクラムの定義にはスクラムの役割イベント作成物とそれらをまとめるルールが含まれるスクラムは Ken SchwaberとJeff Sutherlandが開発したものでありスクラムガイドはこの2 人が執筆提供する両者は共にスクラムガイドを支援しているスクラムの定義スクラム ( 名詞 ): 複雑で変化の激しい問題に対応するためのフレームワークであり可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものであるスクラムとは以下のようなものである軽量理解が容易習得は困難スクラムは 1990 年代初頭から複雑なプロダクト開発の管理に使用されてきたプロセスフレームワークであるプロダクトを構築するプロセスや技法ではなくさまざまなプロセスや技法を取り入れることのできるフレームワークであるこれらのプロダクト管理や開発プラクティスの相対的な有効性を明確にし改善を可能にするのであるスクラムフレームワークはスクラムチームとその役割イベント作成物ルールで構成されているそれぞれに目的がありスクラムの成功や利用に欠かせないスクラムのルールは役割イベント作成物をまとめそれらの関係性や相互作用を統括するものであるスクラムのルールについては本稿全体で説明するスクラムフレームワークを使用する戦略にはさまざまなものがありそれらについては本稿では触れないスクラムの理論スクラムは経験的プロセス制御の理論 ( 経験主義 ) を基本にしている経験主義とは実際の経験と既知に基づく判断によって知識が獲得できるというものであるスクラムでは反復的かつ漸進的な手法を用いて予測可能性の最適化とリスクの管理を行う経験的プロセス制御の実現は透明性検査適応の3 本柱に支えられている透明性経験的プロセスで重要なのは結果責任を持つ者に対して見える化されていることである透明性とはこうしたことが標準化され見ている人が共通理解を持つことである Page 3

4 例 : プロセスの用語を参加者全員で共有している作業をする人とその作成物を受け取る人が完成の定義を共有している検査スクラムのユーザーはスクラムの作成物や進捗を頻繁に検査し変化を検知するただし検査を頻繁にやりすぎて作業の妨げになってはいけない熟練の検査人が念入りに行えば検査は最大の効果をもたらす適応プロセスの不備が許容値を超え成果となるプロダクトを受け入れられないと検査人が判断した場合はプロセスやその構成要素を調整する必要がある調整はできるだけ早く行いこれ以上の逸脱を防がなければいけないスクラムでは検査と適応のための4つの正式なイベントを規定している詳しくはスクラムイベントの節で説明するスプリントプランニングデイリースクラムスプリントレビュースプリントレトロスペクティブスクラムの価値基準スクラムチームが確約 (commitment) 勇気(courage) 集中(focus) 公開 (openness) 尊敬(respect) の価値基準を取り入れそれらを実践するときスクラムの柱 ( 透明性検査適応 ) は現実のものとなりあらゆる人に対する信頼が築かれるスクラムチームのメンバーはスクラムのイベント役割作成物に触れて仕事を進めるなかでこれらの価値基準を学習探索するスクラムを活用するにはこれらの 5 つの価値基準を上手に実践しなければいけない個人はスクラムチームのゴールの達成を確約しなければいけないスクラムチームのメンバーは正しいことをする勇気を持ち困難な問題に取り組まなければいけない全員がスプリントの作業とスクラムチームのゴールに集中しなければいけないスクラムチームとステークホルダーは仕事や課題とその遂行の様子を公開することに合意しなければいけないスクラムチームのメンバーはお互いを能力のある独立した個人として尊敬しなければいけない Page 4

5 スクラムチームスクラムチームはプロダクトオーナー開発チームスクラムマスターで構成されるスクラムチームは自己組織化されており機能横断的である自己組織化チームは作業を成し遂げるための最善の策をチーム外からの指示ではなく自分たちで選択する機能横断的チームはチーム以外に頼らずに作業を成し遂げる能力を持っているスクラムにおけるチームのモデルは柔軟性創造性生産性を最適化するように設計されているスクラムチームはプロダクトを反復的漸進的に届けるこれはフィードバックの機会を最大化するためである完成したプロダクトを漸進的に届けることで動作するプロダクトを常に利用可能な状態にするプロダクトオーナープロダクトオーナーは開発チームの作業とプロダクトの価値の最大化に責任を持つその作業は組織スクラムチーム個人によって大きく異なるプロダクトオーナーはプロダクトバックログの管理に責任を持つ1 人の人間であるプロダクトバックログの管理には以下のようなものがあるプロダクトバックログアイテムを明確に表現するゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える開発チームが行う作業の価値を最適化するプロダクトバックログを全員に見える化透明化明確化しスクラムチームが次に行う作業を示す必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう上記の作業はプロダクトオーナーが行う場合もあれば開発チームが行う場合もあるいずれの場合も最終的な責任はプロダクトオーナーが持つプロダクトオーナーは1 人の人間であり委員会ではない委員会の要求をプロダクトバックログに反映することもあるだろうがプロダクトバックログアイテムの優先順位の変更についてはプロダクトオーナーと相談しなければいけないプロダクトオーナーをうまく機能させるには組織全体でプロダクトオーナーの決定を尊重しなければいけないプロダクトオーナーの決定はプロダクトバックログの内容や並び順という形で見える化されている開発チームに作業を依頼できるのはプロダクトオーナーだけである開発チームもプロダクトオーナー以外から作業依頼を受け付けてはいけない開発チーム開発チームは各スプリントの終わりにリリース判断可能な完成したプロダクトインクリメントを届けることのできる専門家で構成されているインクリメントを作成できるのは開発チームのメンバーだけである Page 5

6 開発チームは自分たちの作業を構成管理するそのことは組織からも認められているその相乗効果によって開発チーム全体の効率と効果が最適化される開発チームには以下のような特徴がある自己組織化されているプロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は誰も ( スクラムマスターでさえも ) 教えてくれない機能横断的であるインクリメントを作成するスキルをチームとしてすべて備えているある人にしかできない作業があったとしてもメンバーの肩書きは開発者だけであるこのルールに例外はないテスティングやビジネス分析のような領域であってもスクラムは開発チームのサブチームを認めていないこのルールに例外はない開発チームのメンバーに専門能力や専門分野があったとしても最終的な責任は開発チーム全体が持つ開発チームの規模開発チームに最適な人数は小回りが利く程度に少なく 1 つのスプリントで重要な作業が成し遂げられる程度に多い人数である開発チームのメンバーが 3 人未満の場合は相互作用が少なく生産性の向上につながらないまた開発チームの規模が小さいとスキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もあるメンバーが 9 人を超えた場合は調整の機会が多くなってしまうまたチームの規模が大きいと経験的プロセスの管理が複雑になってしまうスプリントバックログの作業に携わらないのであればプロダクトオーナーとスクラムマスターはこの人数に含まないスクラムマスタースクラムマスターはスクラムの理解と成立に責任を持つそのためにスクラムマスターはスクラムチームにスクラムの理論プラクティスルールを守ってもらうようにするスクラムマスターはスクラムチームのサーバントリーダーである ( 訳注 : メンバーが成果を上げるために支援や奉仕をするリーダーのこと ) スクラムマスターはスクラムチームとやり取りをするときに役に立つこと / 立たないことをスクラムチームの外部の人たちに理解してもらうスクラムマスターはこうしたやり取りに変化をもたらすことでスクラムチームの作る価値を最大化するスクラムマスターはプロダクトオーナーを支援するスクラムマスターはさまざまな形でプロダクトオーナーを支援する効果的なプロダクトバックログの管理方法を探す明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう経験主義におけるプロダクトプランニングについて理解する価値を最大化するためにプロダクトバックログを調整する方法を知っている Page 6

7 アジャイルを理解実践している必要に応じてスクラムイベントをファシリテートするスクラムマスターは開発チームを支援するスクラムマスターはさまざまな形で開発チームを支援する自己組織化機能横断的な開発チームをコーチする開発チームが価値の高いプロダクトを作れるように支援する開発チームの進捗を妨げるものを排除する必要に応じてスクラムイベントをファシリテートするスクラムがまだ完全に適用理解されていない組織環境で開発チームをコーチするスクラムマスターは組織を支援するスクラムマスターはさまざまな形で組織を支援する組織へのスクラムの導入を指導コーチする組織へのスクラムの導入方法を計画するスクラムや経験的プロダクト開発を社員や関係者に理解実施してもらうスクラムチームの生産性を高めるような変化を促す他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高めるスクラムイベントスクラムで規定されたイベントは規則性を作り出しスクラムで定義されていないミーティングの必要性を最小化するすべてのイベントは時間に上限のあるタイムボックス化されたイベントであるスプリントを開始するとその期間は固定化され増減することはできないスプリント以外のイベントについては目的が達成されたときに終了することもあるプロセスでムダなことをせずに必要な分だけ時間を使うためであるスプリント以外のスクラムイベントは何かを検査適応するための正式な機会である ( スプリントはその他のイベントの入れ物である ) これらのイベントは重要な透明性や検査が実現できるように設計されているこれらのイベントがなければ透明性は低下し検査適応の多くの機会を失うスプリントスクラムの中心はスプリントであるこれは完成した利用可能なリリース判断可能なプロダクトインクリメントを作るための 1 か月以下のタイムボックスであるスプリントは開発作業を行う連続した期間であるスプリントが終了すると新しいスプリントが開始されるスプリントはスプリントプランニングデイリースクラム開発作業スプリントレビュースプリントレトロスペクティブで構成される Page 7

8 スプリントでは以下のようなことを行うスプリントゴールに悪影響を及ぼすような変更を加えない品質目標を下げない学習が進むにつれてスコープが明確化されプロダクトオーナーと開発チームの交渉が必要になる可能性があるスプリントは 1 か月以内のプロジェクトと考えることができるプロジェクトと同様にスプリントは何かを成し遂げるために使うものであるスプリントには開発対象の定義開発のための設計や柔軟な計画開発作業成果となるプロダクトが含まれるスプリントの期間は 1 か月以内に制限されているスプリントが長すぎると開発対象の定義が変更されたり複雑になったりリスクが増大したりする可能性があるゴールに対する進捗を少なくとも 1 か月ごとに検査適応することで予測可能性が高まるのであるまたリスクも 1 か月分のコストに収まるようになるスプリントの中止スプリントはタイムボックスの終了前に中止できるスプリントを中止する権限があるのはプロダクトオーナーだけであるこのときに関係者開発チームスクラムマスターの意見を参考にすることもできるスプリントゴールが古くなった場合はスプリントを中止することになるだろう会社の方向性や市場技術の状況が変化するとスプリントゴールは古くなってしまう状況を考慮して意味がなくなったと思えばスプリントを中止すべきであるただしスプリントの期間は短いので中止したからといってさほど意味をなすことはないスプリントを中止した場合はプロダクトバックログの完成したアイテムをレビューする部分的にリリース判断可能なものがあればプロダクトオーナーが受け入れることになる未完成のプロダクトバックログアイテムは再見積りをしてからプロダクトバックログに戻すそこにかかった作業の価値は急速に低下するため頻繁に再見積りが必要になる ( 訳注 : 作りかけの機能や設計については時間が経つと状況が変わってしまうためその価値が失われてしまうことが多いそうすると最初から見積りをやり直す必要が出てくる ) スプリントを中止すると新しいスプリントのスプリントプランニングが必要となりそのためのリソースを消費してしまうそれからスプリントの中止がチームのトラウマになってしまうこともあるとはいえスプリントの中止はめったに発生しないスプリントプランニングスプリントの作業はスプリントプランニングで計画するこれはスクラムチームの共同作業だスプリントが 1 か月の場合スプリントプランニングのタイムボックスは最大で 8 時間であるスプリントの期間が短ければスプリントプランニングの時間も短くすることが多いスクラムマスタ Page 8

9 ーは参加者に目的を理解してもらうようにするスクラムマスターはスクラムチームにタイムボックスを守るように伝えるスプリントプランニングでは以下の質問に答えるスプリントの成果であるインクリメントで何を届けることができるか? インクリメントを届けるために必要な作業をどのように成し遂げるか? トピック 1: スプリントで何ができるか? 開発チームはスプリントで開発する機能を予想するプロダクトオーナーはスプリントで達成すべき目的と完成後にスプリントゴールを達成するプロダクトバックログアイテムについて検討するスクラムチームはみんなで協力してスプリントの作業を理解するスプリントプランニングのインプットはプロダクトバックログ最新のプロダクトインクリメント開発チームの予想キャパシティと実績であるプロダクトバックログから選択するアイテム数については開発チームが責任を持つスプリントで何が達成できるかを評価できるのは開発チームだけである開発チームがスプリントで届けるプロダクトバックログアイテムを予想したあとにスクラムチームでスプリントゴールを設定するスプリントゴールとはプロダクトバックログを実装することで実現するスプリントの目的であり開発チームがインクリメントを開発する指針となるものであるトピック 2: 選択した作業をどのように成し遂げるのか? プロダクトバックログアイテムを選択しスプリントゴールを設定したら開発チームはそれらの機能をスプリントで完成プロダクトインクリメントにする方法を決める選択したプロダクトバックログアイテムとそれらを届ける計画を合わせてスプリントバックログと呼ぶ開発チームはプロダクトバックログを動作するプロダクトインクリメントに変えるために必要なシステムと作業の設計から着手する作業の規模や工数はバラバラであっても構わないが作業の計画については開発チームがスプリントで達成できそうなものにする開発チームがスプリントの最初の数日間で行う作業についてはスプリントプランニングで作業に分解する作業の単位は 1 日以下にすることが多い開発チームは自己組織化してスプリントバックログの作業を引き受けるこれはスプリントプランニングだけでなく必要であればスプリントでも行うプロダクトオーナーは選択したプロダクトバックログアイテムの明確化やトレードオフを支援する開発チームの作業が多すぎたり少なすぎたりした場合は選択されたプロダクトバックログアイテムについて開発チームとプロダクトオーナーで話し合うあるいは技術やドメインに詳しい人にアドバイスを求めることもできるスプリントプランニングが終了するまでに開発チームは自己組織化したチームとしてどのようにスプリントゴールを達成しどのように期待されるインクリメントを作成するかをプロダクトオーナーとスクラムマスターに説明できなければいけない Page 9

10 スプリントゴールスプリントゴールはスプリントの目標セットでありプロダクトバックログの実装によって実現するものであるこれは開発チームがインクリメントを構築する理由を知る指針となるスプリントゴールはスプリントプランニングで作成するスプリントゴールを設定することで開発チームがスプリント終了までに実装する機能を柔軟にできる選択したプロダクトバックログアイテムは一貫性のある機能として届けられるそれがスプリントゴールになることもあるスプリントゴールがあれば開発チームは一致団結して作業ができる開発チームが計画するときにはスプリントゴールを念頭に置くスプリントゴールを達成するためにそれらの機能や技術を実装する開発チームの予想よりも難しいと判明した場合はプロダクトオーナーと交渉してスプリントバックログのスコープを調整するデイリースクラムデイリースクラムとは開発チームが活動の速度を合わせ次の 24 時間の計画を作る 15 分間のタイムボックスのイベントである前回のデイリースクラムから行った作業の検査と次回のデイリースクラムまでに行う作業の予想を行うデイリースクラムは毎日同じ時間場所で開催するこれは複雑にならないようにするためであるデイリースクラムでは開発チームのメンバーが以下のことを説明する開発チームがスプリントゴールを達成するために私が昨日やったことは何か? 開発チームがスプリントゴールを達成するために私が今日やることは何か? 私や開発チームがスプリントゴールを達成するときの障害物を目撃したか? 開発チームはデイリースクラムを使ってスプリントゴールとスプリントバックログの作業の進捗を検査するデイリースクラムは開発チームがスプリントゴールを達成する可能性を最適化する開発チームは自己組織化チームとしてスプリントゴールを達成しスプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない開発チームまたは一部のチームメンバーはデイリースクラムの終了直後に集まりスプリントの残作業について詳細な議論適応再計画を行うこともあるスクラムマスターは開発チームにデイリースクラムを開催してもらうようにするただしデイリースクラムを開催する責任は開発チームにあるスクラムマスターはデイリースクラムを 15 分間のタイムボックスで終わらせるように開発チームに伝えるスクラムマスターはデイリースクラムには開発チームのメンバーしか参加できないというルールを遵守するデイリースクラムはコミュニケーションを改善しその他のミーティングを取り除き開発の障害物を特定排除し迅速な意思決定を強調助長して開発チームのプロジェクト知識のレベルを向上させるものであるこれは検査と適応の重要なイベントである Page 10

11 スプリントレビュースプリントレビューとはスプリントの終わりにインクリメントの検査と必要であればプロダクトバックログの適応を行うものであるスプリントレビューではスクラムチームと関係者がスプリントの成果をレビューするスプリントの成果とプロダクトバックログの変更を参考にして価値を最適化するために次に何ができるかを参加者全員で話し合うこれはステータスミーティングではなく非公式のミーティングであるインクリメントを提示することでフィードバックやさらなる協力を引き出すことを目的とするスプリントが 1 か月の場合スプリントレビューのタイムボックスは 4 時間であるスプリントの期間が短ければスプリントレビューの時間も短くすることが多いスクラムマスターは参加者に目的を理解してもらうようにするスクラムマスターはスクラムチームにタイムボックスを守るように伝えるスプリントレビューには以下の要素が含まれる参加者 ( スクラムチームと重要な関係者 ) はプロダクトオーナーが招待するプロダクトオーナーはプロダクトバックログアイテムの完成したものと完成していないものについて説明する開発チームはスプリントでうまくいったこと直面した問題点それをどのように解決したかを議論する開発チームは完成したものをデモしてインクリメントに対する質問に答えるプロダクトオーナーは現在のプロダクトバックログを審議する ( 必要であれば ) 現在の進捗から完了日を予測するグループ全体で次に何をするかを議論し次のスプリントプランニングに価値のあるインプットを提供できるようにするプロダクトの市場や今後の利用状況についてレビューした場合次に行う最も価値の高いことが変更されることもあるプロダクトの次のリリースに対するスケジュール予算性能市場をレビューするスプリントレビューの成果は次のスプリントで使用するプロダクトバックログアイテムが含まれた改訂版のプロダクトバックログである新たな機会に見合うようにプロダクトバックログを全体的に調整することもあるスプリントレトロスペクティブスプリントレトロスペクティブはスクラムチームの検査と次のスプリントの改善計画を作成する機会であるスプリントレトロスペクティブはスプリントレビューが終わって次のスプリントプランニングが始まる前に行うスプリントが 1 か月の場合スプリントレトロスペクティブのタイムボックスは 3 時間であるスプリントの期間が短ければスプリントレトロスペクティブの時間も短くすることが多いスクラムマスターはこのイベントが確実に開催されるようにするまた参加者に目的を理 Page 11

12 解してもらうようにするスクラムマスターはスクラムチームにタイムボックスを守るように伝えるスクラムマスターはスクラムプロセスを説明するためにチームメンバーとしてイベントに参加するスプリントレトロスペクティブには以下の目的がある人関係プロセスツールの観点から今回のスプリントを検査するうまくいった項目や今後の改善が必要な項目を特定整理するスクラムチームの作業の改善実施計画を作成するスクラムマスターは次のスプリントが効果的で楽しいものになるように開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらうスクラムチームは完成の定義を適切に調整してプロダクトの品質を向上させる方法を計画するスプリントレトロスペクティブが終わるまでにスクラムチームは次のスプリントで実施する改善策を特定しなければいけないこれらの改善策の実施は開発チーム自体の検査の適応になる改善はいつでも実施可能だがスプリントレトロスペクティブは検査と適応に集中するための正式な機会であるスクラムの作成物スクラムの作成物は作業や価値を表したものであり透明性や検査適応の機会を提供するものであるスクラムで定義された作成物は全員が共通理解を得るために必要な情報の透明性を最大化するように設計されているプロダクトバックログプロダクトバックログはプロダクトに必要なものがすべて並べられた一覧でありプロダクトに対する変更要求の唯一の情報源であるプロダクトオーナーはプロダクトバックログの内容可用性並び順に責任を持つプロダクトバックログは決して完成しない開発の初期段階には最初から明確でよく理解できた要求が並べられているプロダクトバックログはプロダクトや使用環境に合わせて進化するプロダクトバックログは動的であり適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化するプロダクトが存在する限りプロダクトバックログは不滅であるプロダクトバックログは今後のリリースで実装するプロダクトのフィーチャ機能要求要望修正をすべて一覧にしているプロダクトバックログアイテムには詳細並び順見積り価値の属性があるプロダクトが使用されて価値が増加し市場からフィードバックを得られるとプロダクトバックログは巨大で包括的な一覧になる要求の変更は止まらないプロダクトバックログは生きた作成物であるビジネス要求市場の状態技術の変化がプロダクトバックログの変化につながる Page 12

13 複数のスクラムチームが同じプロダクトの作業をすることがよくあるそうした場合プロダクトの作業は1つのプロダクトバックログに記述するまたアイテムをグループにまとめる属性をプロダクトバックログに追加するプロダクトバックログアイテムに詳細見積り並び順を追加することをプロダクトバックログのリファインメントと呼ぶこれはプロダクトオーナーと開発チームが協力して行う継続的なプロセスであるプロダクトバックログのリファインメントによってアイテムのレビューと改訂が行われるいつどのようにリファインメントをするかはスクラムチームが決定するリファインメントは開発チームの作業の10% 以下にすることが多いただしプロダクトバックログアイテムはプロダクトオーナーの判断によっていつでも更新できる並び順が上のアイテムほど明確で詳細である明確で詳細であれば見積りも正確になる並び順が下のアイテムほど不正確で詳細ではない今後のスプリントで開発チームが従事するプロダクトバックログアイテムはスプリントのタイムボックスで完成できるようにうまく細分化する開発チームが1つのスプリントで完成できそうなプロダクトバックログアイテムはスプリントプランニングで選択できる準備完了 (Ready) の状態になったと見なせるプロダクトバックログアイテムは上記のリファインメントによって透明性を獲得することが多い開発チームは見積りに対して責任を持つプロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが最終的な見積りは実際に作業をする人が行うゴールへの進捗を監視するいずれかの時点で開発ゴールに対する残作業を合計するプロダクトオーナーは少なくともスプリントレビューにおいてこの残作業の合計を追跡するプロダクトオーナーは前回のスプリントレビューのときの残作業の合計と比較して希望する時間までにゴールに到達できるかどうかを評価するこの情報は関係者全員に明らかにされる進捗の見通しを立てるためにバーンダウンやバーンアップなどのさまざまなプラクティスが使用されているこれらは有用ではあるが経験主義の重要性を置き換えるものではない複雑な環境下では何が起きるかわからないすでに起きたものだけがこれから先の意思決定に使用できるスプリントバックログスプリントバックログはスプリントで選択したプロダクトバックログアイテムとそれらのアイテムをプロダクトインクリメントにして届けスプリントゴールを達成するための計画を合わせたものであるスプリントバックログは開発チームが作成するインクリメントに含まれる機能とその機能を完成インクリメントにして届けるために必要な作業の予想であるスプリントバックログによって開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている Page 13

14 スプリントバックログは十分に詳細であり今後も変更される可能性のある計画であるそれはデイリースクラムで理解できる程度のものである開発チームはスプリントでスプリントバックログを修正するスプリントバックログはスプリントで創発されるこうした創発が発生するのは開発チームが計画を実行するなかでスプリントゴールの達成に必要な作業を学習するからである新しい作業が必要になれば開発チームがスプリントバックログに作業を追加する作業が完了すれば残作業の見積りを更新する計画の要素が不要になれば削除するスプリントでスプリントバックログを変更できるのは開発チームだけであるスプリントバックログには開発チームがスプリントで行う作業がリアルタイムに反映されるスプリントバックログは開発チームのものであるスプリントの進捗を監視するスプリントのいずれかの時点でスプリントバックログの残作業を合計する開発チームは少なくともデイリースクラムにおいてこの残作業の合計を追跡しスプリントゴールの達成に見通しを立てる開発チームはスプリントで残作業を追跡し自分たちの進捗を管理するインクリメントインクリメントとはこれまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを合わせたものであるスプリントの終わりには新しいインクリメントが完成していなければいけないつまりインクリメントが動作する状態でありスクラムチームの完成の定義に合っていることを意味するプロダクトオーナーがリリースを決定する / しないにかかわらずインクリメントは常に動作する状態にしておかなければいけない作成物の透明性スクラムは透明性に依存している作成物の状態を把握することで価値の最適化やリスクの制御に関する決定を行う透明性が確保されている限りこうした決定には信頼できる根拠が存在する作成物が不完全に透明化されていればこうした決定には不備があり価値は低減しリスクが高まる可能性があるスクラムマスターはプロダクトオーナー開発チームその他の関係者と一緒になって作成物が完全に透明化されているかを理解する不完全な透明性に対処するにはいくつかのプラクティスが存在するスクラムマスターはそのなかから最適なプラクティスの選択してもらえるように支援するスクラムマスターは作成物の検査パターンの察知言説の傾聴期待値と実際値の違いを把握することで不完全な透明性を検知できるスクラムマスターの仕事はスクラムチームや組織と一緒になって作成物の透明性を向上させることであるこの仕事には学習説得変化を伴うことが多い透明性は一夜にしてならず透明性とは長い道のりなのである Page 14

15 完成 (Done) の定義プロダクトバックログアイテムやインクリメントの完成を決めるときには全員がその完成の意味を理解しておかなければいけないスクラムチームによってその意味は大きく異なるが作業の完了についてメンバーが共通の理解を持ち透明性を確保しなければいけないこれはスクラムチームの完成の定義と呼ばれプロダクトインクリメントの作業が完了したかどうかの評価に使われるこの定義は開発チームがスプリントプランニングでプロダクトバックログアイテムをいくつ選択するかの指針にもなる各スプリントの目的はそのときの完成の定義に合ったリリース判断可能な機能のインクリメントを届けることである開発チームはスプリントごとにプロダクトインクリメントを届けるインクリメントは実際に利用可能なものでありプロダクトオーナーがすぐにリリースすることもできるインクリメントの完成の定義に関して開発組織の慣例標準ガイドラインが存在する場合はスクラムチームは最低でもそれを守らなければいけないインクリメントの完成の定義が開発組織に存在しない場合はスクラムチームの開発チームはプロダクトに適した完成を定義しなければいけない複数のスクラムチームがシステムやプロダクトのリリース作業をする場合はすべてのスクラムチームの開発チームが共通の完成の定義を使用しなければいけないインクリメントはそれまでのインクリメントに追加されたものでありすべてが正常に動くように十分にテストされたものであるスクラムチームが成熟していくと完成の定義にさらに厳しい品質条件を追加することもあるプロダクトやシステムは完成の定義を備えるべきであるそれがあらゆる作業の完了基準となる最後にスクラムは無料であり本ガイドで提供されるものであるスクラムの役割作成物イベントルールは不変であるスクラムの一部だけを導入することも可能だがそれはスクラムとは言えないすべてをまとめたものがスクラムでありその他の技法方法論プラクティスのコンテナとして機能する Page 15

16 謝辞人々スクラムに貢献してくれた非常に多くの人たちのなかでも最初の10 年間に貢献してくれた人の名前を挙げたいまず Jeff Sutherlandと一緒に働いてくれたJeff McKenna それから Ken Schwaberと一緒に働いてくれたMike SmithとChris Martin 翌年からはその他にも多くの人たちが貢献してくれた彼らの助けがなければスクラムは今日のように洗練されていなかっただろう歴史 1995 年のOOPSLAカンファレンスにおいて Ken SchwaberとJeff Sutherlandがスクラムを共同発表したこの発表は KenとJeffがスクラムを数年間適用した経験から学んだことを文書化したものであるスクラムの歴史は長い最初の試行錯誤の場であるIndividual, Inc. Fidelity Investments IDX ( 現 GE Medical) に感謝したいスクラムガイドは Jeff SutherlandとKen Schwaberが20 年以上かけて開発保守してきたスクラムを文書化したものであるその他の情報源ではスクラムフレームワークを補完するパターンプロセスインサイトなどが提供されているこれらは生産性価値創造性プライドを最適化するものである翻訳本ガイドは Ken SchwaberとJeff Sutherlandによる英語バージョンを日本語に翻訳したものである日本語訳は角征典 ( ワイクル株式会社 )<kdmsnr@gmail.com> が担当した翻訳レビューは守田憲司 (@wsfjp) さんむらはしけんいち (@sanemat) さん角谷信太郎 (@kakutani) @kawagutiさんにビューにご協力いただいた Page 16

17 変更履歴 2013 年から 2016 年にかけてのスクラムガイドの変更点 1. スクラムの価値基準のセクションを追加スクラムチームが確約 (commitment) 勇気(courage) 集中(focus) 公開 (openness) 尊敬(respect) の価値基準を取り入れそれらを実践するときスクラムの柱 ( 透明性検査適応 ) は現実のものとなりあらゆる人に対する信頼が築かれるスクラムチームのメンバーはスクラムのイベント役割作成物に触れて仕事を進めるなかでこれらの価値基準を学習探索するスクラムを活用するにはこれらの 5 つの価値基準を上手に実践しなければいけない個人はスクラムチームのゴールの達成を確約しなければいけないスクラムチームのメンバーは正しいことをする勇気を持ち困難な問題に取り組まなければいけない全員がスプリントの作業とスクラムチームのゴールに集中しなければいけないスクラムチームとステークホルダーは仕事や課題とその遂行の様子を公開することに合意しなければいけないスクラムチームのメンバーはお互いを能力のある独立した個人として尊敬しなければいけない 2011 年から 2013 年にかけてのスクラムガイドの変更点 1. 作成物の透明性の節を追加したスクラムは透明性に依存している作成物の状態を把握することで価値の最適化やリスクの制御に関する決定を行う透明性が確保されている限りこうした決定には信頼できる根拠が存在する作成物が不完全に透明化されていればこうした決定には不備があり価値は低減しリスクが高まる可能性がある 2. スプリントプランニングが 1 つのイベントになったそのなかでスプリントで何ができるか? と選択した作業をどのように成し遂げるのか? の 2 つのトピックを扱う開発チームがスプリントで届けるプロダクトバックログアイテムを予想したあとにスクラムチームでスプリントゴールを設定するスプリントゴールは開発チームの作業に一貫性を持たせるものであるそれは共通のゴールがないバラバラのチームでは成し遂げられなかった作業であるこのスプリントゴールを正式に追加した 3. プロダクトバックログはグルーミングではなくリファインメントするリファインメントされたプロダクトバックログアイテムは透明化されスプリントプランニングのインプットとして十分に理解可能であり適切な粒度となっているこのように透明化されたプロダクトバックログアイテムのことを準備完了 (Ready) であるという準備完了(Ready) と完成(Done) は透明性を補強する 2 つの状態である 4. スクラムで規定されたイベントは規則性を作り出しスクラムで定義されていないミーティングの必要性を最小化するすべてのイベントはタイムボックス化されていて時間に上限があるスプリント ( 他のイベントのコンテナ ) は期間が固定化され増減すること Page 17

18 はできないスプリント以外のイベントについては目的が達成されたときに終了することもあるプロセスでムダなことをせずに必要な分だけ時間を使うためだ 5. プランニングイベントとしてのデイリースクラムの重要性を強調したステータス確認のイベントになっているのをよく見かける開発チームは自己組織化チームとしてスプリントゴールを達成しスプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけないこのイベントのインプットはスプリントゴールに向かってチームがどのように活動しているかでありアウトプットはスプリントゴールを達成するためにチームの作業を最適化する新しいあるいは改訂した計画であるしたがって個人ではなくチームを強調するために 3 つの質問を再構成した a. 開発チームがスプリントゴールを達成するために私が昨日やったことは何か? b. 開発チームがスプリントゴールを達成するために私が今日やることは何か? c. 私や開発チームがスプリントゴールを達成するときの障害物を目撃したか? 価値の概念をスプリントレビューで使うために強化したスプリントレビューではスプリントの成果についてスクラムチームと関係者が一緒に議論するスプリントの成果とスプリントで変更したプロダクトバックログを参考にして参加者全員は価値を最適化するために次に何ができるかを一緒に考える Page 18

Scrum Basics

Scrum Basics スクラムガイドスクラム完全ガイド : ゲームのルール 2011 年 10 月 Developed and sustained by Ken Schwaber and Jeff Sutherland 目次スクラムガイドの目的... 3 スクラムの概要... 3 スクラムフレームワーク... 3 スクラムの理論... 4 スクラム... 5 スクラムチーム... 5 プロダクトオーナー... 5 開発チーム...