スクラムチームのワーキングアグリーメントとコンセンサス（合意）

ずっと考え続けていた。

 

認定スクラムマスター研修にて、研修全体のワーキングアグリーメントを決める際、「決め方を決めてくれ」という話が出ていた。

そこにいた大勢の研修生は、多数決という方式をとった。

 

講師の江端（@ebacky）さんが言った。

「あなたたちは設計上の重要な課題を解決する際にも、多数決で決めるのですか？」

確かに、設計上の重要な課題を解決する場合、多数決では決めない。

 

ただ、研修はそのまま進んでしまった。多くの決定を多数決で決めていた。

認定スクラムマスター研修は、研修自体を生徒たちが作っていく形式だったため、生徒たちが決めたルールで進める。ルール自体に、もやもや感があっても、全員をうまく説得できないと、そのルールを変えられない。

 

民主主義云々という話もチラホラ聞こえたが、「そんなんじゃない。多数決は変だ。」と個人的にずっと考え続けていた。

（イギリスのEU脱退でホットな話題でもある。）

 

研修を受けたのは2015/08で、今日は2016/6/29だから、実に１年ぐらいずっと悩んでいたのだが、やっと答えがでた。

答えは身近なところにあった。

スクラムには、プロダクト・オーナーという役割がある。

プロダクト・オーナーは製品に関するあらゆることを決断できる役割だ。

 

つまり、プロダクト・オーナーを決めればよかったのだ。

 

プロダクト・オーナーがYESと言えば、YES。プロダクト・オーナーにYESと言わせる説得力を持った題材があればいい。スクラムにおけるチームはその役割だ。

多数決ではダメなのだ。民衆が誤っていると、誤った方向に流れてしまう。これは民主主義のデメリットだ。とくにマスコミ・メディアによって洗脳されてしまうと、大衆は違った方へ進む。

（テレビをつけっぱなしにしている家庭は洗脳されている可能性が高い）

（もちろん、マスコミもメディアも洗脳しようとしている訳ではないが、結果的にそうなっているから質が悪い）

もちろん、プロダクト・オーナーが狂っている場合は、ナチス・ドイツのような悲惨なことになるだろう。

プロダクト・オーナーとチームの健全な関係性は非常に重要だ。

 

この考えに至るには、

「トヨタ式A３プロセスで仕事改革」

トヨタ式A3プロセスで仕事改革―A3用紙1枚で人を育て、組織を動かす

を読んでp88にある下記のセンテンスから着想した。

 

コンセンサス（合意）

やるべきこと：　

　オーナーを認識する

　オーナーとは合理的アプローチを提示するもの。合理的アプローチは、

　　ー関係者全員の考え方と合理的な懸念を反映し、

　　ー関係者はオーナーの成果獲得への協力に合意する

 

やってはいけないこと：

　・無暗に一致団結を目指す

　・多数決、あるいは「私がやろうと思っていたやり方だから賛成する」という態度

 

考え抜け、ということだと思う。

個人的な、１年がかりの疑問も解消できた。

幸せの条件とアジャイル

人間の幸福は、人間関係で決まるという研究結果が出たようです。
友達がたくさんいてもダメで、深い人間関係にあり、信頼できる人がそばにいると、肉体的に苦痛でも精神的には幸せになれる。

50、60代でリタイアしてからも自分の外に人脈を作って、常に他の人間と関わっていくことが幸せの条件のようです。

やはり自分たちはなんでもすぐに手に入ってすぐに利用できるものを好みます。
しかし、人間関係というのはそうではない。
泥臭かったり、面倒臭かったりするわけですが、それでも人間関係が私達に幸せをもたらしてくれるというのは、非常に興味深いです。

人間同士のつながりを常に改善しつづける、アジャイルであることは、人間を幸福にする上でも大切な手法なのかも知れません。
…と無理やりアジャイルと結びつけてみました（笑

ZERO to ONE

Agile Japan 2016でSORACOMの玉川氏が薦めていた本を読んでみた。

AgileJapan2016

ZERO to ONE

ゼロ・トゥ・ワン　君はゼロから何を生み出せるか

スタートアップとは、君が世界を変えられると、君自身が説得できた人たちの集まりだ。

• 競争するな、独占せよ。競争は資本主義の対極にある。
• 独占するには、隠れた真実を見つけよ

隠れた真実には2種類ある。自然についての隠れた真実と人間についての隠れた真実だ。自然についての隠れた真実はいたるところに存在する。

最高のスタートアップは、究極よりも少しマイルドなカルトと言っていい。

コンピュータは人間を補完するものであって、人間に替わるものじゃない。

どんなビジネスにも答えを出すべき７つの質問。

1. エンジニアリング
2. タイミング
3. 独占
4. 人材
5. 販売
6. 永続性
7. 隠れた真実

5つか6つ答えられるだけでも大丈夫だろう。

所感

逆張り的な発想で、やはり成功する人は考え方が凡人と違う。競争するな、独占せよ、なんてなかなか思いつかないが、たしかに独占できるような 市場、技術力、営業力がないんなら成功なんて出来ない。言われると納得するが、言われるまで気づかない。それこそが隠れた真実。

NHKクリエイティブライブラリー

www1.nhk.or.jp

これ切ったり貼ったりしてつかっていいなんて、すごい宝の山のような気がする・・・！
受信料払っていて良かった・・・（笑

スクラムでプロジェクトを始める前にするべきこと

スクラムはじめようって何からはじめればいいの？

スクラムやりたい！
いきなりスプリント開始～！
なんてうまくいくはずがありません。
走りながらにも限界があると思いますし、途中で疲れちゃいます。
スクラムは、実は事前の準備が本当に大切です。スクラムガイドなどには謳われていませんが…。

ここでは、今までスクラムを導入したことが無い組織でスクラムを導入するための道標を記載してみました。
真っ白な状態からスクラムをやりたいのであれば、一番最初に スクラム・マスターが必要だと思います。 スクラム・マスターが、「スクラムやろうぜ」の発起人になっていないとうまく回らない可能性が高いです。 チームとプロダクト・オーナーをうまく導けないからです。

今までスクラムを導入したことが無い組織の場合、スプリントの開始までに、２～３週間ぐらい必要です。
ここで述べるのはあくまで私個人の経験・学習の結果からくるものですので、すべてマストではありません。
スプリントを始めてしまって、１スプリント目で様々な整合を取りつつ行う手法もあるとは思います。（大変だと思いますが…）

以下、おおまかなTODOリストになります。

1. プロダクト・オーナーとスクラムマスターを決める
2. マネージャー（経営層）を味方につけ、共有する。
3. チームメンバーを集め、スクラムの説明をする。チームがやりたがらない場合は、ここで終了。
4. ステークホルダーを味方につけ、共有する。
5. プロダクト・バックログ作成
6. ぼんやりとでもアーキテクチャを決める(後から変更可能）
7. リリースプランニングとリリース計画作成と共有
8. 想定される成果物を洗い出し、必要かどうかを確認する
9. チームは、完了の定義(Done of Definition)を検討し、プロダクト・オーナーと合意を取る。
10. スプリント計画作成（時間と場所の確保、集計方法検討）
11. スプリントの開始！

プロダクト・オーナーとスクラムマスターを決める

特にスクラムマスターはプロダクト・オーナーにスクラムとはこうゆうもんだと説明し、納得頂く。
プロダクト・オーナーがすでにスクラムに詳しい場合は割愛可能。
アンチパターンとしては、同一人物が兼任してしまうパターン。うまくいかないと思います。
そんなに甘くないです。スクラムマスターもやることは山積みです。

マネージャー（経営層）を味方につけ、共有する。

味方にできるかどうかは、マネージャーの性格や、組織文化にも依存しますので、非常に難しいとは思いますが、経営層の誰かを味方につけたほうがいいです。
理由は、優秀なチームメンバーや物資リソースを集めやすくなるからです。
ホワイトボードや付箋の調達や、どの壁を使っていいかなども相談する必要が出てきます。
また、困ったときに相談できる偉い人がいると非常に安心です。
Fearless Changeの経営層の支持者パターン(28)ですね。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

チームメンバーを集め、スクラムの説明をする。チームがやりたがらない場合は、ここで終了。

マネージャーを味方につけたら、こんなメンバーが欲しいと相談します。
チームメンバーの素養としては、

• 選択肢を与える力（代替案の提案）
• 実現力
• ちょっとした社交性

が必要かと思います。上２つは認定スクラムマスター研修で習いました。
スプリントレビュー等ではチームがプロダクト・オーナー含めステークホルダーにインクリメントを説明しますので、少し話せる人が必要かと考えています。

説明をした結果、チームがやりたがらない場合は、ここで終了です。
無理強いはよくないと考えます。結局うまくいかないです。
チームをやる気にできるかどうかはスクラムマスターにかかっています。

ステークホルダーを味方につけ、共有する。

これも非常に大切です。特にプロダクト・バックログ作成とスプリント毎のスプリント・レビューには出席して頂いたほうが価値のあるものが出来上がりやすいです。
海外ではどうか知りませんが、プロダクト・オーナーが全て一人で何でも決められるっていうのは日本だと考えづらいです。特に企業が大きくなればなるほどその傾向は強いと考えます。
プロダクト・オーナーに全責任を背負わせてしまい、病んでしまう可能性もあるので…。
もちろん、最終決定権はプロダクト・オーナーにありますが、プロダクト・オーナー自身が間違っていることに気づくためには、ステークホルダーの意見も大切だと思います。
なので、プロダクト・バックログ作成とスプリント毎のスプリント・レビューにはステークホルダーに出てもらって、ちょっとした議論も入り交えつつ
本当の「セレモニー」という形で華々しくやっていくと良いと思います。特別感を出しましょう。

また、ここで大切なのが、ステークホルダーにスクラムの価値をわかっていただくことです。
計画はあくまで計画です、とか、やるべきことはどんどん変化します、ということは腹を割って話したほうがいいと思います。

プロダクト・バックログ作成

プロダクト・バックログを作成します。
ペルソナを決めて、ユーザーストーリー・マッピング手法を使うと、ストーリーの全体像が見えます。

qiita.com

なるべく、ステークホルダーにも参加してもらいます。もちろん、チームとプロダクト・オーナーも一緒にやるのが良いです。
丸１～２日缶詰になれる場所で、大きな壁に向かってストーリーを貼っていきます。

ユーザーストーリーマッピングも非常に効果的ですが、巨大なストーリーの場合は、スクラム現場ガイドの２９章「巨大なバックログの見積もりと優先順位付け」に参考になる手法が書かれています。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

ストーリーのサイズと優先順位を４象限マトリクスにしてプロダクト・バックログを作成します。

プロダクト・オーナーは、受け入れ条件を作成し、チームと共有する。

プロダクト・バックログを作成したら、プロダクト・オーナーは、各ストーリーもしくはストーリーの束において、受け入れ条件を作成します。
ただ、この段階で詳細まで書いてしまうとあとからストーリーが変わったりすると意味がなくなるので、
優先順位が高く、ストーリーが小さいもの（近いスプリントで行うもの）の受け入れ条件を作成したほうが良いと思います。

ぼんやりとでもアーキテクチャを決める(後から変更可能）

この段階で優先順位が高く、細かいストーリーが揃っているはずです。
全体像から、ソフトウェアのアーキテクチャをチームと一緒にぼんやりと決めておいたほうがいいです。
もちろん後から変更可能ではありますが、スプリントが開始した時点でアーキテクチャどうしよう？となると
スプリントプランニング時に正確なタスク分割もできないので、スプリント内で動くものが出来る確率は非常に低くなります。
データベースが必要なのか、WEBなのか、ネイティブアプリなのか、ネイティブの場合はOSはMacなのかWindowsなのか…など。

リリースプランニングとリリース計画作成と共有

プロダクト・バックログが出来上がると現時点での総ストーリーポイントがわかります。
総ストーリーポイントと、１スプリントでどれくらいのベロシティが出せるかを仮定で良いのでチームと話してみましょう。
最低のベロシティと最大のベロシティが出ると、全部でどれくらいのスプリント回数が必要か、どのストーリーがいつごろ出来上がるかというリリース計画が立てられます。
（あくまで変わるという前提付きですが）
リリース計画に関しては以下に書きました。

kshimizu.hatenadiary.jp

想定される成果物を洗い出し、必要かどうかを確認する

組織の文化や、法規制等によって、必要な成果物があらかじめ決められているケースもあります。
その場合には、単に「動くソフトウェア(Potentially Shippable Product Increment )」以外にも成果物が必要な場合があります。
その辺りを洗い出しておいて、スプリントプランニング時にチームにインプットします。プランニングのタスクの一つになるので、ここで抜け漏れは結構厳しいです。厳密に行きましょう。（チームにどやされる（汗

チームは、完了の定義(Done of Definition)を検討し、プロダクト・オーナーと合意を取る。

成果物と似ていますが、スプリントプランニングで洗い出されるタスクの完了の定義を、プロダクト・オーナーと合意を取ります。
例えば、Unit Testの作成は必須、コードレビューは必ず行う、
定量的にいうと、コードカバレッジが80%以上とか、Unit Test Failが0件であるとか、テストケースが何件以上あるとか、
各ストーリーのユーザマニュアルの作成が完了しているとか、（必要であれば）設計書を記載している、そのレビューが終わっている、など各タスクやスプリントの完了の定義をプロダクト・オーナーと合意を取ります。
完了の定義はプロダクト・オーナーとの合意が必須です。

スプリント計画作成（場所と時間等、バーンダウン集計をどうするか。Excelのテンプレート探し）

スプリントを1～4週間どの単位で行うのかをチームと議論をして決めます。議論した結果プロダクト・オーナーとも合意します。
また、各セレモニーをいつどこで行うかを決めます。
例えば、2週間1スプリントであれば、以下の様なチャートを作るといいと思います。

スプリントプランニングは丸１日かけますが、１日で終わらないことも多々あります。予備枠を設けておくと安心です。

バーンダウンチャートはスクラムの必須要素ではありませんが、チームの進捗を見る上では便利なツールです。
作り方等は予め考えていたほうが良いと思います。
バーンダウンやチケットはいきなり電子化しないことをお薦めします。
スプリントの振り返りでチームメンバーから電子化が必要だと出てくるまで待ったほうがいいと思います。
世界のスクラムマスターたちのディスカッションをまとめてくれたサイトがありました。
JIRAやTFSが優勢ですが、チームが必要だと思ったら、チームが導入するというスタンスで。

daipresents.com

さぁ、スプリントの開始です！

ここまでくるとやっとスクラムを開始できる土台が揃いました！あとは透明性・検査・適応を維持し、山あり谷あり、楽しくも厳しい旅の幕開けです！！

スクラムにおけるリリース計画

スクラム現場ガイドの第11章は全てを引用して載せたいぐらい良いことが書かれています。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

プロジェクトにおいて、よく聞かれる質問「いつ終わる？」「この日までにできる？」

どんなプロジェクトでも、一番よく聞かれる質問は「いつ終わる？」「この日までにできる？」じゃないだろうか。誰でも、プロジェクトが予想通りに進まずひどい目にあった経験があるはずだ。

スクラム現場ガイド 第11章より引用

確かに頻繁に聞かれます。そしてステークホルダー（お金を出す側）にとってみれば最大の関心事はこれです。

伝統的な開発手法の場合、わかりやすく回答しやすい

ウォーターフォールなどの開発プロセスだと、要件が全て決まっていると仮定して、長いガントチャートを書きます。
長いガントチャートを書くために要件から機能をリストし、各機能を見積もります。この見積もりは仮定です。
ガントチャートを書き上げたら、その計画どおりに事が進むと仮定され、プロジェクトは開始されます。
ガントチャートがありますから、いつ何が完成するかは、チャートを見ればわかります。わかりやすいです。
そして報告では、計画通り事が進んでいないことが問題とされ、その問題（遅れ）を取り戻すための施策を検討せよ、ということになり、さらにプロジェクトは遅れます。
「数値上は、あと4人メンバーを追加すれば、計画通り進みます。」
と報告され、メンバーが4人追加され、さらにプロジェクトは遅れます。もう挽回は不可能です。
ただの「数合わせゲーム」と化します。
要件を削るか、期間を延ばすかです。
でもそれは不可能で、さらに人を追加します・・・。デスマーチです。

frontline.fm 言いたいことをいってくれている感がある（笑

スクラムの場合、何の準備もしていないと回答しづらい

逆にスクラムだとどうなるのでしょうか。
スクラムガイドラインにはこの手の回答はありませんので、自ら考える必要があります。

スクラムではガントチャートは基本的には引かないです。引いてもいいですけど頻繁に変わることを前提とするため、メンテナンスコストが多くかかります。
ガントチャートを引かない代わりに、以下の３つのインプットからリリースプランニングをします。

• 見積もり、順序付け、優先順位付けができているプロダクト・バックログ
• チームのベロシティ（チームと相談した上での、予測値。）
• スプリントのタイムライン

プロダクト・バックログのストーリーポイントが合計で200だったとして、チームと相談した仮のベロシティが20だとしたら、単純計算で10スプリントあれば完了です。
ただ、ストーリーポイントはスプリント毎に常に見直され、チームのベロシティもだんだんと安定してくることをステークホルダーと共有しましょう。
プロダクト・バックログの上から順に何がいつごろ出来そうかをプランニングします。

リリースプランニングの成果物は、以下の様な図になります。これがリリース計画になります。


リリース計画はプロジェクトのロードマップになります。
おおよそどのようなストーリーがいつごろ出来上がるかを視覚的にわかりやすく表現できています。

上記の例では、チームのベロシティは１つだけでしたが、チームの自信や経験を踏まえ、
最低・最大のベロシティにて計算すると良いと思います。（最低水位・最高水位と呼ばれています。）

さきほどの図に最低ベロシティの場合と最高ベロシティの場合を付けます。

表現を変えるだけですが、ストーリーポイントのバーンダウンに最低ベロシティだった場合の着地点と最大ベロシティの着地点を表現しても良いと考えます。

そして、このリリース計画をスプリント毎に必ず見直しましょう。
プロダクト・バックログ・リファインメント時が一番適していると思います。

この手法にて、スクラムにおいても「いつ終わる？」「この日までにできる？」に回答することができます。

何度も言いますが、このアプローチの場合に重要なのは、
リリース計画は毎回変わるものだということをステークホルダーと共有することです。

「計画は変わらないもの」「計画は死守するもの」として受け取られてしまうと「何が何でもスプリント１ではこのベロシティを出さなくてはならない」ということに成りかねません。
持続可能性が保持できません。

アジャイルとは、常に改善し続ける状態であること、です。
継続ができないということは、アジャイルではありません。

箱モノであろうが何であろうが、現在は明らかにサービスの時代です。エンドユーザに寄り添って、常により良いものを作り続ける必要があります。
エンドユーザとともに成長ができる、本当のWin-Winの関係が築けるのがアジャイルです。

リリース計画は初期のロードマップとして有効です。 計画は計画に過ぎないと、関係者の皆様が理解していないといけません。計画は変わるのです。私たちは最善を尽くしてプロダクトバックログを見積もりまますが、それでもプロジェクト完了までの実際の距離が予想より増えたり、減ったりいたします。
スクラム現場ガイド 第11章より引用

スクラム スクラムガイドとスクラムの奴隷

スクラムは、理解は容易ですが、習得が困難です。
習得または実行と言い換えてもいいかも知れません。「きっちりした」スクラムを実行することはものすごいエネルギーが必要です。

スクラムガイドにも書いてあります。
「 スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。」

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf

これは非常に厳しい言葉です。
おそらくですが、完璧なスクラムを実践している職場は非常に少ないのではないでしょうか。
スクラムは企業文化や組織風土、メンバーのスキルに依存する部分も多々あるため、スクラムを自身の企業や組織に適用するために”一部変えてしまう”ことがあると思います。

一方で、「スクラムの奴隷になるな」という言葉もあります。
出典はわかりませんが、スクラムの実践者たちが講演しているセミナー等ではよく聞く言葉です。
この真意はわかりませんが、「スクラムをスクラムガイドのまま進めすぎようと躍起になると痛い目に会うよ」ということだと認識しています。（違ったらごめんなさい）
「ミイラ取りがミイラになる」、と似ているのかなと感じました。（違うか（汗

ガイドでは、スクラムというものをきっちりと定義し、それから逸脱してはスクラムとは言えないと謳い、
実践者たちは「スクラムの奴隷になるな」と謳っています。
どちらを信じれば良いのでしょうか？

私は、「どちらも信じる」だと思います。

スクラムガイドは非常に軽量です。もしスクラムを実践しようとするなら、すべてを暗記して、ソラで説明できるぐらい真剣にスクラムを理解するべきです。
スクラムには19の要素があると言われています。以下の19の要素が散りばめていないと、スクラムではないということになります。

要素	日本語	説明
Transparency	透明性	“経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。 例： プロセスの用語を参加者全員で共有している。 作業をする人とその作成物を受け取る人が「完成」の定義を共有している。RDBの世界にあるOne Fact In One Placeもこれに近いです。共有すべき情報は１箇所にあること。それが全員に周知できている状態であることが大切です。
Inspection	検査	スクラムのユーザーは、スクラムの作成物や進捗を頻繁に検査し、変化を検知する。ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。熟練の検査人が念入りに行えば、検査は最大の効果をもたらす。
Adaptation	適応	プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査人が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
Prodcut Owner	プロダクトオーナー	プロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。
Development Team	開発チーム	開発チームは、各スプリントの終わりにリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。インクリメントを作成できるのは、開発チームのメンバーだけである。 開発チームは、自分たちの作業を構成・管理する。そのことは組織からも認められている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。
Scrum Maser	スクラムマスター	スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。 スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。
Sprint	スプリント	スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックスである。スプリントは、開発作業を行う連続した期間である。スプリントが終了すると、新しいスプリントが開始される。
Sprint Planning	スプリントプランニング	スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業だ。 スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。スクラムマスターは、参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。"
Daily Scrum	デイリースクラム	デイリースクラムとは、開発チームが活動の速度を合わせ、次の24時間の計画を作る15分間のタイムボックスのイベントである。前回のデイリースクラムから行った作業の検査と、次回のデイリースクラムまでに行う作業の予想を行う。デイリースクラムは毎日、同じ時間・場所で開催する。これは、複雑にならないようにするためである。
Sprint Review	スプリントレビュー	スプリントレビューとは、スプリントの終わりにインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。
Sprint Retrospective	スプリントレトロスペクティブ	スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
Sprint Stop	スプリントストップ	スプリントを中止する
Product Back Log Refinement	プロダクトバックログリファインメント	中・長期のProduct Back Logを考える。 次のSprint以降の話をする。今のSprintは変えない。 （スクラムをやると未来が見えなくなると言う人がいるが、大抵これをやっていない）
Product Back Log	プロダクトバックログ	プロダクトバックログは、プロダクトに必要なものがすべて並べられた一覧であり、プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。
Sprint Back Log	スプリントバックログ	スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。スプリントバックログは、開発チームが作成するインクリメントに含まれる機能と、その機能を「完成」インクリメントにして届けるために必要な作業の予想である。
Potentially Shippable Increment	出荷判断可能インクリメント	インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを組み合わせたものである。スプリントの終わりには、新しいインクリメントが「完成」していなければならない。つまりインクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。
Impediment List	インペディメントリスト	“スクラムからみた課題・障害・リスクを管理するリスト。 例：セレモニーが長い チームが安定してきたが、出荷できない
Acceptance Criteria	受け入れ条件	プロダクトオーナーがスプリントレビュー時にプロダクトを受け入れる条件を明記したもの。Prodcut Back Logに記載する。
Definition of Done	完了の定義	プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。

その上で「スクラムの奴隷になるな」だと思います。
ただ、私が思うに、上記19の要素は全て必須だと思いますし、透明性・検査・適応という原則を守ろうとすると必然的についてまわる要素だと考えます。

スクラムは、非常に楽しいですが、反面、非常に大変です。
１スプリント２週間の場合、
まるで隔週連載のマンガ家になった気分だとチーム内から声が上がったことがあります。うーん、確かに。
２週間で動くものを作りこむプレッシャーたるや相当のものだと思います。
ただそれが、チーム、人間の限界ギリギリの能力を発揮してくれるのかも知れません。締め切り効果というやつです。

スクラムは適切に運用されればチームの力をかなり向上させ、顧客、チーム内においても透明性を確保し、コミュニケーションを増大させてくれると確信しています。
そして、それは非常に楽しく、厳しいです。
チームのメンバーの素養としては、Mでないとやっていけないかも知れません。（嘘