Introduction to Scrum

スクラムの紹介

Recorded by MJ (https://twitter.com/michaeldotjames mj4scrum@gmail.com)

次のテキストはhttp://scrumtrainingseries.com/Intro_to_Scrum/の新しい音声になります。

[slide: Scrum is usually fake]

The fundamental constraint of knowledge work – such as software development – is our ability to discover and create knowledge.  

「知的作業」、例えばソフトウェア開発などの根本的制約は、知識を発見して創造する私たちの能力にあります。

ソフトウェア開発などの「知的創造」においては、知識を発見し創造する私たち人間の能力が根本的な制約条件となります。

But your company is designed for a previous century based on hierarchy and incentives.  

しかし、あなたの会社は20世紀の階層型組織で、インセンティブをベースとした組織設計となっています。

一方、会社組織は、ヒエラルキーとインセンティブに立脚した、一つ前の世代向きの設計となっています。

Scrum is optimized for knowledge creation and collaborative invention.

スクラムは知識創造と共同開発のために最適化されています。

スクラムとは、知的創造及び共同開発に最適化されたものです。

So it contradicts your organization's current policies, habits, and structure.  Those things are hard to change, so most places just rename their current practices to "Scrum."

ですから、スクラムはあなたの組織にある既存の方針、習慣、構造とは相反しています。こういう事を変えるのは難しいので、ただ現行のプラクティスを「スクラム」と名前を変えて呼んでいるだけの場合が多いのです。

したがって、組織の現行の方針や習慣、構造とは相反します。これらは簡単に変えられるものではありません。そこで、現行の慣習を「スクラム」と呼び変えるだけの組織が多いのです。

I made these lessons to help you challenge fake Scrum.

私は、皆さんがこのレッスンを通じて、偽物のスクラムに疑問を投げかけていく手助けとなればと考えています。

こういった偽のスクラムに対して、皆さんが異議を呈する一助として本レッスンを作成しました。

[slide: MJ with pointer]

Welcome to Module 1 of Scrum Training Series: Introduction to Scrum.

スクラムトレーニングのモジュール1、「スクラムの紹介」へようこそ

スクラムトレーニングシリーズ・モジュール1、「スクラム概論」へようこそ。

  This is a brief introduction to topics that are covered in greater depth in the other modules.

このモジュールでは全体像を簡単にご紹介することにして、踏み込んだ内容は他のモジュールで行います。

ここではスクラムの全体像をご紹介し、以降のモジュールで各トピックの内容を更に深めていきます。

 I’m Michael James (MJ). I help organizations do Scrum and related Agile practices.

私はマイケル・ジェームス(MJ)です。組織へのスクラム導入や、それに関連するアジャイル・プラクティスのサポートを行っています。

私はマイケル・ジェームス(MJ)です。様々な組織に対して、スクラムやそれに関連するアジャイルの実践について支援を行っています。

[slide: Thumbnail of Scrum Reference Card, clicks through to online document]

This module is subdivided into three chapters.

このモジュールは3つの章で構成されています。

このモジュールには3つのパートがあります。

At the end you’ll find a challenging quiz that’s been shown to increase scores on certification tests and may be a prerequisite to your certification class.  

各モジュールの最後にはクイズがあります。このクイズは認定テストの点数アップに役立つもので、認定トレーニングで必要なものも含んでいます。

最後にテストがあります。ここでは、認定試験のスコアを上げることができます。また、認定トレーニングを受講する際の必要条件となる場合もあります。

I also recommend downloading the six-page illustrated Scrum Reference Card.

また、6ページにわたるイラスト付きスクラムリファレンスカードもありますので、ぜひダウンロードしてみてください。

http://scrumreferencecard.com/ScrumReferenceCard-jp.pdf 日本版

6ページのイラスト付きスクラムリファレンスカードもありますので、ぜひダウンロードしてみてください。

http://scrumreferencecard.com/ScrumReferenceCard-jp.pdf 日本版

[slide: Scrum Framework]

Scrum is a framework for dealing with complex work such as new product development.

スクラムは新規のプロダクト開発といった複雑な仕事に適したフレームワークです。

スクラムは、新規プロダクト開発などの複雑な業務を取り扱うためのフレームワークです。

It is an alternative to traditional approaches that were more suited to manufacturing and construction. Why do you need an alternative?

これは、製造業や建設業でみられる従来の手法に取って替わる新しい手法ですが、それがなぜ今必要とされているのでしょうか?

これは、製造や建設といった業種に適していた従来型のアプローチを置き換える新しい手法です。では、どうして従来のやり方を変える必要があるのでしょうか。

[existing slide: “OLD” assembly line]

[cue scratchy music from the 1940s or 50s]

In the previous century, most people’s work required more of a focus on execution than innovation.

20世紀、多くの人々が行う仕事は、イノベーションより業務の遂行にフォーカスしていくことが求められていました。

20世紀、大半の仕事では、イノベーションよりも業務の遂行に重きが置かれていました。

People with defined roles used defined models and defined best practices to execute defined plans that didn’t change very quickly.

人々は与えられた役割を担い、与えられたモデル、与えられたベストプラクティス、与えられたプランを実行し、素早い対応は求められていなかったのです。

人々は与えられた役割のもと、定められた型を使い、定められたやり方で、急速に変化することのない、定められた計画を遂行していました。

[new slide: “OLD” assembly line is superimposed on the lower left quadrant of the Stacey diagram, in the “Predictable” zone.]

Life was more predictable because we knew more about what

かつての仕事というのは、予測可能なものでした。なぜなら、私たちは「何」を成し遂げ、

およそ仕事とは、先行きの予想がつくものでした。なぜなら、私たちは、何を

[slide or animation emphasizes “Requirements”]

we were trying to accomplish, and how

「どうやって」それを達成させていくのか

成し遂げようとし、そしてどうやって

[slide or animation emphasizes “Technology”]

we would accomplish it.

よく理解していたからです。

成し遂げようとしているのかを、現代よりも深く理解していたからです。

People like Henry Ford used ideas from Frederick Taylor and H.L Gantt to do predictable or repeatable work.

ヘンリー・フォードのような人々は、フレデリック・テイラーやH.L ガントが提唱した概念を、予測可能な繰り返し作業に適応させました。

予測可能な作業や繰り返し作業を遂行するためのアイディアを、フレデリック・テイラーやH・L・ガントが提唱し、ヘンリー・フォードといった人物がそれを活用しました。

[slide: zoomed out to Stacey diagram]

[scratchy old music stops, or changes to modern music, whatever that is]

Today, a lot of the predictable, repeatable work is done much faster, by machines.

今日では、予測可能で繰り返しの作業の多くは、機械を使うことで、より素早く完了できるようになりました。

今日では、予測可能な繰り返し作業の多くは、機械を用いてもっと迅速に行われています。

 Things change more quickly.

世の中の動きも、より早くなりました。

世の中の動きも、より速くなりました。

To stay competitive, we need to inspect and adapt more quickly, and deal with greater uncertainty.

競争力を維持していくために、私たちは検証と適応を速やかに行い、不確実性が高い状況への対応が求められています。

競争力を高く保つためには、速やかに検証と適応を行い、非常に変化しやすい状況に対応していく必要があります。

 A transparent framework imposing timeboxes and feedback loops can help us master uncertainty.

透明性のあるフレームワークなら、タイムボックスとフィードバックループを活用して、不確実性を攻略していくことができます。

タイムボックスとフィードバックループを伴う透明性のあるフレームワークを用いれば、不確実性の高い状況を乗りこなすことができます。

[new slide: “Only learning organizations will be able to keep up with the future.”]

Only learning organizations will be able to keep up with the future.

これからの未来は、学習し続ける組織しか生き残れないでしょう。

これからの時代は、学び続ける組織だけが生き残れるのです

[return to existing slide: Stacey diagram]

[new slide: Stacey diagram with framework image in the chaotic zone]

Scrum is a framework for learning about work and the processes we use to do it.

スクラムは、仕事で必要なものと、仕事の進め方を学ぶためのフレームワーク。

スクラムとは、作業に必要なものは何か、及び、作業を終わらせるにはどうすればよいかを学ぶためのフレームワークです。

It’s an attempt to put chaos in a box, making the most of uncertainty.

カオスを枠組みに入れて、不確実性を最大限に活用しようという試みです。

混沌を箱に納めてしまって、不確実性を最大限に活用しようという試みです。

While it’s mostly been used for developing new software products, it may be useful for other kinds of complex work.

この手法は、主に新規のソフトウェアプロダクト開発で利用されていますが、他の複雑な仕事においても有効となるでしょう。

ソフトウェアプロダクトの新規開発で主に用いられてきた手法ですが、その他の複雑な作業においても役に立ちます。

[existing slide: blank circuit diagram]

Scrum introduces feedback loops

スクラムはフィードバックループを活用し、

スクラムでは、フィードバックループを用いて

[existing slide: colored circuit diagram]

encouraging us to inspect and adapt the

[new slide: circuit + product measuring instrument only]

product that we’re building and the

開発中のプロダクト及び

[existing slide: circuit + both instruments]

processes we’re using to build that product.

現在作成中のプロダクトと、それを作る開発プロセスの検証や適応を行っていきます。

その開発プロセスについての検証と適応を促します。

[existing slide: balanced Agile Movement]

Scrum is associated with the Agile movement described at

http://agilemanifesto.org/.

スクラムはアジャイルムーブメントと関係があるので、詳しくはこちらをご覧ください。http://agilemanifesto.org/iso/ja/manifesto.htm

スクラムに関連するアジャイルムーブメントについては、こちらをご参照ください。http://agilemanifesto.org/

We value:

• • • •

individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

私たちは、プロセスやツールよりも個人との対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とします。

私たちは、次のことを重視します。

プロセスやツールよりも、個人および対話を。

包括的なドキュメントよりも、動くソフトウェアを。

契約交渉よりも、顧客との協働を。

計画に従うことよりも、変化への対応を。

[existing slide: Agile Movement tips left]

This doesn’t mean that we don’t value the things on the right.

これは、左記のことがらを重視していないという意味ではありません。

左の事柄に価値が無いというのではありません。

[optional animation: balance teeters]

We do value the things on the left more.

私たちは右記のことがらに、より価値を置いているのです。

私たちは、右の事柄により価値を置くということです。

[new slide: Running Tested Features diagram] [slide 12]

Early in our product development cycle, we will want to see some features working, rather than one huge release at the end.

プロダクトの大きなリリースを最後に行うのでなく、プロダクト開発サイクルの初期からフィーチャーが動いていることを確認することに重点を置きます。

大きなリリースを最終段階で一度に行うのではなく、プロダクト開発サイクルの初期から、実際に動くフィーチャーを見たくなるものでしょう。

Ideally, we’d be able to continue incremental improvements indefinitely.  

理想は、インクリメンタルに改善を重ねていくことです。

理想的には、インクリメンタルな改善を無限に重ねることもできます。

Each Sprint we learn more about customer needs and change course a little, or a lot.  

それぞれのスプリントで顧客ニーズを掴み、開発の方向性を少しずつ、場合によっては一気に変更していきます。

スプリント毎に、私たちは顧客ニーズに対する学びを深め、少しずつ、場合によっては一気に、方向性を変えていきます。

Product development is ongoing, with frequent releases, rather than a one-shot “project.”

プロダクト開発は単発のプロジェクトではなく、頻繁にリリースしながら常に進行していきます。

プロダクト開発は単発の「プロジェクト」ではなく、リリースを重ねながら常に進行していくものです。

[old scratchy music comes back]

[existing slide: waterfall diagram]

Here’s what Scrum is NOT: The attempt to use traditional Gantt ideas for developing software was first described by Dr. Winston Royce in 1970.

ここに、スクラムではないものがあります。伝統的なガントの概念をソフトウェア開発に最初に取り入れたのは、1970年に発表されたウィンストン・ロイスの論文でした。

スクラムではないものを見てみましょう。1970年、ウィンストン・ロイスは論文を発表し、伝統的なガントチャートという概念のソフトウェア開発への導入を、初めて試みました。

He drew a picture, a bit like this one, showing a series of phases.

彼はこのような図を描いていますが、ご覧のように、いくつものフェーズに分かれています。

彼はこのような図を描きました。ご覧のように、いくつものフェーズに分かれています。

[cycle through existing slide sequence showing relay-race baton handoffs]

One phase connects to the next phase connects to the next phase and each one has a hand off.  

1つのフェーズから次のフェーズへ、そしてまた次のフェーズへと繋がり、それぞれのフェーズで担当者が変わっていきます。

1つのフェーズから次のフェーズへ、そしてまた次のフェーズへと繋がり、それぞれのフェーズで引き継ぎが生じます。

In theory, you would do all of your analysis in the beginning, get that completely done,

この理論では、最初にすべての分析を行って全てを完了させ、

理論的には、分析作業は始めに全て完了させてしまい、

and then you would start on your design, get that completely done,

設計を始めて全てを完了、

次に設計に取りかかりこれも全て完了させ、

and then start on your code, get that all the way done, and then integrate, etc.

そしてコーディングを始めて全てを完了させ、インテグレーションなどへと移っていきます。

そして次はコーディングに取りかかり全て完了させ、次にインテグレーションに移る、という調子で進みます。

That was a nice theory about how things could work, and we suppose it could work if we had perfect knowledge in the beginning, and never made mistakes along the way.

最初から全ての知識を持ち合わせ、進行中に間違いが起こらないのであれば、この理論は仕事の仕組みとして素晴らしいものでしょう。

これは物事がどう進みうるかを示した素敵な理論でした。もしも我々が、初期段階で完全な知識を持つことができ、進行に際して全くミスを犯さなければ、うまく機能したことでしょう。

The next sentence in Dr Winston Royce’s paper (unfortunately, no one read this far), said

次の文章は、ウィンストン・ロイスの論文の中の一節で(ここまで読む人は、ほとんどいないと思いますが)次のように書かれています。

ウィンストン・ロイス博士の論文にこんな一文があります(残念ながら、ここまで読む人はいませんが)。

[slide: Dr. Royce in the barrel falling down the waterfall]

“I believe in this concept but, the implementation described above is risky and invites failure.”

「私はこのコンセプトを信じてはいるが、実践するにはリスクが高く、失敗を招くだろう。」

「私はこの概念を信じているが、実践するとなるとリスクが高く、うまくいかないだろう」

[slide sequence: blindfolded team members fail to hand off batons to each other]

The reason it fails for complex work: We rarely have perfect knowledge at the beginning.

私たちが複雑な仕事で失敗するのは、初期段階で全ての知識を持ち合わせていないからです。

複雑性の高い作業でこの理論がうまくいかないのは、初期段階で完璧な知識を有することが、ほぼあり得ないからです。

 In fact, we know less about our project when we are starting out then we’re ever going to know in the future.

実際、私たちは仕事の始めたばかりでは、プロジェクトをよくわかっておらず、時が経ってだんだん分かっていくようになります。

実際、始めたばかりの時点では、プロジェクトについての知識は少なく、時を経るにつれてだんだんと分かってくるものです。

Today is the dumbest day of the rest of our project.

今日という日が、プロジェクト全体の中で最も無知な日というわけです。

残りのプロジェクト期間全体で、常に、今日が一番無知な日というわけです。

But a plan-driven approach requires us to make our most important decisions right at the beginning, when we know the least.  

それなのに、計画駆動型アプローチでは、知識の少ない初期段階で、私たちに最も重要な意思決定を迫ってきます。

それなのに、計画駆動型アプローチでは、知識の少ない初期段階で直ちに最も重要なことを決めるよう求められます。

Waterfall projects eventually descend into anarchy, when the actual work finally happens with low quality and too much overtime.

ウォーターフォール・プロジェクトでは、ようやく実際の作業が始まると無秩序な状態に陥ってしまい、品質も悪く、多くの残業時間もかけてしまいます。

ウォーターフォール型プロジェクトでは、最終段階でようやく実際の作業が始まりますが、低品質で過剰な時間がかかり、最終的に無秩序状態へと陥ってしまいます。

[slide: ScrumMaster throws waterfall into blender]

Scrum throws all those phases in the blender. All the ingredients are mixed into every Sprint.

スクラムでは全てのフェーズをブレンダーに入れて混ぜ合わせます。そして混ぜられたすべての要素は、スプリントそれぞれへと移されます。

スクラムは、全てのフェーズをミキサーに放り込むようなものです。全ての材料が混ぜ合わさって全てのスプリントに分けられます。

[slide: ScrumMaster with shot glasses] [slide 18]

Instead of dividing the work into activity-specific phases, we divide it into fixed-length iterations, called Sprints.

作業を特定のアクティビティ単位のフェーズに分けるのではなく、スプリントという固定化された期間のイテレーションに分割するのです。

仕事を、活動を特定されたフェーズに分割するのではなく、決まった期間のイテレーションに分割するのです。これをスプリントと呼びます。

Every Sprint contains some combination of analysis, design, actual implementation, testing, learning about customer needs, and planning for the future.

すべてのスプリントには、分析、設計、実装、テスティング、顧客ニーズの確認、将来のプラニングが含まれます。

どのスプリントも、分析、設計、実装、テスト、顧客ニーズの学習や将来の計画を組み合わせたものを含んでいます。

 Maybe we’ll actually be deploying or shipping more frequently.

システムを実際にデプロイし、より頻繁な出荷ができるようになるでしょう。

デプロイや出荷をより頻繁に行えるようになるでしょう。

[optional future animation: shot glasses turn into rainbow circles, then add the loops on top making Scrum swirls]

[existing slide: Scrum swirl + unicycle, bicycle, tandem bicycle]

Right from the first Sprint, a Scrum team tries to develop a working, tested, potentially-shippable product increment, even if it starts out small.  

スクラムチームはたとえ小規模であっても、最初のスプリントから潜在的に出荷可能なインクリメントを動かしテストを行い、開発します。

最初のスプリントから直ちに、たとえ小さなものでも、実際に動き、テスト済みで、潜在的には出荷可能なプロダクト増分の開発に取り組むのがスクラムチームです。

Every Sprint they demonstrate what little bit of shippable product they have to everyone.  

そして、毎回スプリントの終わりに、少しでも出来上がった出荷可能なプロダクトを全員にデモンストレーションします。

そして各スプリント、ほんの小さなものでも、できあがった出荷可能なプロダクトを全員にデモンストレーションします。

Customers often need to see the wrong product before they can specify what they really need.  

顧客は、自身が本当に望むものを特定する前に、間違ったプロダクトを見せられるというのは、よくあることです。

的外れのプロダクトに触れてはじめて、顧客が自分の真のニーズを特定できるというのは、よくあることです。

With short iterations and more feedback we have a better chance of discovering the right product.  

短いイテレーションと、顧客からの多くのフィードバックによって、私たちが理想のプロダクトを完成させていく可能性はより高くなります。

短期間の繰り返しと顧客からより多くのフィードバックを得ることで、的を得たプロダクトを見つける可能性が高まります。

While the Product Owner doesn’t have to actually ship every Sprint, it’s the team’s job to make it possible.

プロダクトオーナーは、実際スプリントごとに出荷する必要はありません。スプリントごとに出荷可能な状態にするのはチームの仕事です。

スプリント毎にプロダクトオーナーが実際に出荷する必要はありませんが、チームは、それが可能な状態を実現する役割を担っています。

[existing slide: Scrum swirl, etc. + cross-functional team]

To make a shippable product every two weeks, we’re going to want people with skills in testing, in design, in business requirements, in coding, all on one cross-functional, self-organizing team.

2週間ごとにプロダクトを出荷可能な状態にするために、メンバーはクロスファンクショナルな自己組織化チームの中で、テスト、設計、ビジネス要求事項、コーディングといった全てのスキルを備えておくことが求められます。

出荷可能なプロダクトを二週間毎に作り出すためには、クロスファンクショナルで自己組織化されたチーム内に、テスト、設計、ビジネス、コーディングといったスキルを有する人材を全て備えておく必要があります。

Now, instead of waiting for the end to start our testing, we’ll start testing with our very first Sprint.

これで、テストを始めるのにプロダクトの最後まで待つことなく、最初のスプリントからテストを実行できるようになります。

これで、最後まで待たされることなく最初のスプリントからテストを実行できます。

Instead of doing all the design up front, we’ll do a bit of design every Sprint, until it becomes continuous design.  

事前に全ての設計を行うのではなく、継続的な設計ができるよう、スプリント毎に少しづつ設計を作っていきます。

事前に設計を全て行ってしまうのではなく、少しの設計を毎スプリントで行い、継続的な設計を実現していきます。

We’ll do small amounts of continuous redesign and refactoring to avoid technical debt.  Every Sprint combines all aspects of the work.

スプリントでは技術的負債を避けるべく、小さな再設計とリファクタリングを実行します。どのスプリントでも、このすべての作業を含んでいます。

技術的負債が生じないよう、継続的な再設計とリファクタリングを小規模に行っていくことになるでしょう。全てのスプリントが、業務の全ての側面を組み合わせたものなのです。

 A Scrum team should collaborate together instead of working in phases with handoffs.

スクラムチームではフェーズ毎に別々の担当者が行うのではなく、チームで協働しなければなりません。

スクラムチームは、フェーズ毎の引き継ぎにより作業するのではなく、相互に協働します。

[existing slide: Roles, Meetings, Artifacts]

Scrum provides a structure of roles, meetings, rules and artifacts.

スクラムは、役割、ミーティング、ルール、アーチファクトの構造を提供します。

スクラムは、役割、会議、ルール及びアーチファクトの構造を提供します。

Let’s do a quick overview of them now.

それでは、簡単に全体像を見ていきましょう。

では、その全体像をざっと概観しましょう。

[existing slide: 3 roles]

There are only 3 roles defined by Scrum and we’ll go through each one: Product Owner, Scrum Development Team, and ScrumMaster.

スクラムが定義する役割は3つだけ。プロダクトオーナー、スクラム開発チーム、そしてスクラムマスターです。私たちはこの中から一つの役割を担います。

スクラムで定義される役割は3つだけです。プロダクトオーナー、スクラム開発チーム、スクラムマスターです。1つずつ見ていきましょう。

[existing slide: Product Owner] [slide 23]

The Product Owner is the single individual responsible for return on investment (or ROI) of the product development effort.

プロダクトオーナーは、開発にかけた投資効果、つまりROIに唯一責任を持つ人間です。

プロダクトオーナーとは、投資収益率(ROI)についての責任を持つただ1人の人間です。

The Product Owner mostly exerts that influence through the prioritization of the product backlog.

プロダクトオーナーは、プロダクトバックログの優先順位を決定します。

主に、プロダクトバックログの優先順位を決定することを通じて、その影響力を行使します。

The Product Owner is the final arbiter of requirements questions.

そして、要求に関して問題が起こった時に、最終的な決定権を持ちます。

要求に関する問題が生じた場合、プロダクトオーナーが最終的な決定権を持ちます。

That doesn’t mean that he or she will give you all of the detailed requirements up front, or even all the details at the beginning of each Sprint.

ただし、これは事前に細かな要求をすべて与えるという意味ではなく、各スプリントを始める時点で、すべての詳細を与えることすらありません。

これは要求事項の詳細を事前に全て与えるという意味ではなく、各スプリントの始めに詳細を伝えるということですらありません。

 But the Product Owner does make the final call about those things.

そうではなく、プロダクトオーナーはこうした事柄について、最終判断を決定します。

プロダクトオーナーが、こういった事柄の最終決定権をもつという意味です。

[same slide: Product Owner has a thought bubble with a light bulb in it.]

The Product Owner must have the vision behind the product development.  

プロダクトオーナーはプロダクト開発の元となるビジョンを持ち合わせていなければなりません。

プロダクトオーナーには、プロダクト開発の裏にあるビジョンがなければなりません。

Given high uncertainty, it often doesn’t make sense to have a detailed roadmap, but a vision is important.

不確実性が高い状態で、細かなロードマップはあまり意味がありませんが、ビジョンは重要です。

不確実性の高い状況では詳細なロードマップはあまり役に立ちませんが、ビジョンは重要です。

[new slide: stakeholders funnel concerns through the Product Owner] [slide 24]

 If anyone else wants anything from the team, they need to work through the Product Owner to get what they want.

もし誰かがチームに何らかの仕事を依頼したい場合は、プロダクトオーナーを通して要求する必要があります。

他の誰かがチームに何かを依頼したいときは、プロダクトオーナーを通す必要があります。

 He or she is the one person making the prioritization decisions. The Product Owner  makes the business decisions, focused more on the what than on the how.

プロダクトオーナーだけが、唯一、優先順位を決定する人間です。そしてビジネス上の意思決定を行うにあたり、どう進めていくかよりも、何をやるかにフォーカスしていきます。

プロダクトオーナーは、唯一、優先事項を決定する人間です。そして、どう行うかよりも何を行うかに着目して、ビジネス上の意思決定を行います。

In Large Scale Scrum, there is only one Product Owner for multiple development teams.

大規模スクラム(LeSS)では開発チームが複数になりますが、プロダクトオーナーは1人だけです。

大規模スクラム(LeSS)では開発チームが複数になりますが、プロダクトオーナーは一人だけです。

[slide: Scrum Development Team]

Now we have the Scrum Development Team.

続いて、スクラム開発チームです。

次に、スクラム開発チームです。

The Scrum Development Team is a cross functional group responsible for self organizing to develop a shippable product every Sprint.

スクラム開発チームはクロスファンクショナルなグループで、スプリント毎に出荷可能なプロダクト開発を自分たちで行う責任を持っています。

LESSスクラム開発チームはクロスファンクショナルな集まりであり、自己組織化して、スプリントごとに出荷可能なプロダクトを開発する責任を負っています。

This is hard to do in the beginning, and today more and more teams are learning how to do it. You don’t want to be the last team that learns how to do this!  

最初からこの状態にするのは難しいかもしれませんが、

今日、より多くのチームがこのやり方を学んでいます。あなたのチームも乗り遅れないよう習得してみましょう!

はじめは難しいものですが、現在、多くのチームがこの手法を学んでいます。あなたのチームも取り残されないよう習得していきましょう。

Organizations use the word “team” lightly.  

組織というのは「チーム」という言葉を軽く扱っています。

組織は「チーム」という言葉を軽く扱いがちです。

Think back to a time in your life you were on a real team, where you could all count on each other.  

信頼できる仲間がいた本物のチームにいた時のことを思い出してみてください。

これまでの経験のなかで、全員が互いに信頼できる本物のチームにいたときを思い出してください。

That’s the kind of Scrum team I want you to create.

そういうチームを、皆さんに作って欲しいのです。

そういうチームを、皆さんに作っていただきたいのです。

 If we keep the same team together in the right environment full time, with effective Retrospectives, Sprint after Sprint, they’ll probably get better at working with each other.  

もし良い環境の中で、同じチームが一日中協働し、レストロペクティブを効果的に行っていけば、スプリントをこなしていくたびに、おそらく上手く協働が進んでいくでしょう。

効果的なレトロスペクティブを備えた良い環境をチームに与えてフルタイムでスプリントを次々にこなさせれば、お互いにうまく協働できるようになっていくでしょう。

They may become a learning team, the building block of a learning organization.

組織の礎となるべく、学びを続けるチームへと成長できるかもしれません。

学び続ける組織の要素である、学び続けるチームへと成長できるかもしれません。外部からチームにヒエラルキーや役職を押しつけられることはありません。

There are no externally imposed hierarchy or job titles on this team. We leave openings for leadership to emerge naturally, and for control to flow from person to person.

このチームには、対外向けに与えられた地位や役職はありません。リーダーシップが自然と表れ、業務が人から人へスムーズに流れていきます。

リーダーシップが自然に生まれ、コントロールが人から人へと自然に流れていくに委ねるのです。

[new slide: derive from small_vs_large_team_illustration]

The Scrum Development Team is a small group, no more than 9 people. We have millions of years of practice dealing with groups about the size of a family.

スクラム開発チームは9人以下という小さなグループです。私たちは数百万年前から家族サイズのグループで仕事をすることに慣れています。

スクラム開発チームは、9人を超えない小さなグループです。人間にとって、家族規模のグループは、何百万年も前から馴染みのある存在です。

Large groups don’t self organize effectively until they divide into smaller teams.  

大きなグループは小さなチームに分割しなければ、効果的に自己組織化できません。

大規模なグループが効果的に自己組織化するためには、小グループへの分割が必要です。

In Large Scale Scrum, full stack feature teams pull their work from one Product Backlog and integrate their work every Sprint.

大規模なスクラムでは、フルスタックのフィーチャーチームがプロダクトバックログから仕事を選び、スプリント完了後に統合させます。

大規模スクラムでは、フルスタックのフィーチャーチームが一つのプロダクトバックログから業務を選び、スプリント毎に成果を統合します。

[slide: Team Room]

Team collaboration emerges most naturally in a team room.  

チームによる共同作業は、チームルームの中で最も自然な形で作り出されていきます。

チームの協働が最も自然な形で生まれるのは、チームルームの中です。

[slide: planet-sized impediment]

If your organization is spread around the world, you’re probably already suffering poor collaboration and coordination; Scrum will quickly bring this problem to the surface.

あなたの組織がグローバル展開しているなら、もしかしたら既に連携や協調の悪さで苦しんでいるのではないでしょうか。こうした表面上あらわれた問題でも、スクラムなら即座に解決できます。

あなたの組織が世界展開していれば、連携や協調のなさには、既に苦しめられているのではないでしょうか。スクラムでは、こういった問題は直ちに表面化します。

 You may experience breakthroughs by getting your remote people into one room for one or two Sprints in the beginning, and then every few months after that.

離れた場所にいるスタッフを1つの部屋に集め、最初の1つか2つのスプリントを一緒に行い、その後、数か月ごとに集まれば、問題を解決できるかもしれません。

リモートで勤務していたメンバーを一つの部屋に集めて、始めの1~2スプリントはずっと一緒に、その後は数ヶ月に一度この状態で作業することで、ブレークスルーが生じるかもしれません。

 Information sharing tools by themselves don’t transform organizations ... and often make things worse.

情報共有ツールの使用は組織変革の妨げとなり、状況を悪化させることもよくあります。

情報共有ツールを使っても、それだけで組織変革が生じはしません。状況が悪くなるることすらよくあります。

[slide: ScrumMaster]

The ScrumMaster is the most misunderstood role in Scrum.

スクラムマスターの役割は、スクラムの中で最も誤解されています。

スクラムマスターは、スクラムで一番誤解されている役割です。

 If I’m your ScrumMaster, you’re not my ScrumSlave.

もし私があなたのスクラムマスターなら、あなたは私の奴隷ではありません。

例えば、私があなたのスクラムマスターだとしても、あなたはスクラム奴隷になるわけではありません。

It's the opposite. The ScrumMaster has no management authority over the team.  

その逆です。スクラムマスターにはチームに対するマネージメント権限がありません。

むしろ逆です。スクラムマスターは、チームに対してマネジメント権限を持ちません。

If you are the project manager or line manager of the team, by definition you are not the ScrumMaster.

この定義によると、もし今あなたがチームのプロジェクトマネージャー、或いはラインマネージャーなら、あなたはスクラムマスターではありません。

つまりプロジェクトマネジャーやラインマネジャーは、定義上、スクラムマスターではないことになります。

 Scrum intentionally leaves out the project manager role.

スクラムでは意図的にプロジェクトマネージャーの役割をなくしています。

スクラムでは、あえてプロジェクトマネジャーの役割を設けていません。

[slide: ScrumMaster + PO + Team]

The responsibilities of project management are split up among the Product Owner and the Team, with the ScrumMaster acting as a kind of facilitator.

プロジェクトマネージメントの責任は、プロダクトオーナーとチームに分散され、スクラムマスターはファシリテーター的な役割を担います。

プロジェクトマネジメントの責任はプロダクトオーナーとチームが分かれて担い、スクラムマスターがファシリテータ役を担います。

[slide: ScrumMaster protects the team from wolves.] [slide 31]

The ScrumMaster protects the team from distractions and interruptions, gets things out of the way of natural team self-organization,

スクラムマスターは、様々な邪魔や妨害からチームを守る、チームを自然に自己組織化させる、

スクラムマスターは、気を散らせることや割り込みからチームを守り、自然にチームが自己組織化するやり方から物事を引き出します。

removes impediments affecting the team, facilitates the process, helps teach people how to use Scrum,

チームに悪影響を与える障害を取り除く、プロセスをファシリテートする、人々にスクラムの使い方を教える、

チームに影響する障害を取り除き、プロセスをファシリテートし、スクラムの実践方法を教え、

promotes improved engineering practices, timeboxes, provides visibility, and somehow does all this without any management power.

改良されたエンジニアリングプラクティスやタイムボックスを促進する、可視性を提供するなど、これら全てをマネージメントという権力を使わず行います。

質の良いエンジニアリングプラクティスやタイムボックスを促し、ビジビリティを提供します。そして、マネジメント権力を行使せずに以上の全てを成し遂げるのです。

 It turns out “power” isn’t the most powerful type of influence.

「権力」が最も強い影響を与えるものではないことは明らかなのです。

最も強い影響力は「権力」ではないことがわかります。

[slide: Scrum Master focus over time.][slide 32]

Eventually the Team and Product Owner don't need as much of the ScrumMaster's attention.

最終的には、チームとプロダクトオーナーによるスクラムマスターへの依存は減少していくでしょう。

やがては、スクラムマスターはチームとプロダクトオーナーにそれほど注意を払わなくても良くなるでしょう。

 A good Scrum Master does not "make the team do Scrum." Good developers already want to learn and collaborate instead of being directly managed.

良いスクラムマスターはチームにスクラムを強要しません。良い開発者は直接管理されるのではなく、学習し協働したいという考えをすでに持っています。

「チームにスクラムを行わせる」ことをしないのが、良いスクラムマスターです。直接管理されるのではなく、既に学び協働する意欲を備えているのが良い開発者です。

  A good Scrum Master makes it possible for teams to do Scrum by influencing the organization's policies and structure.  

良いスクラムマスターは、組織の方針や構造に影響を与えることで、スクラムの実践を可能にしていきます。

組織のポリシーや構造に対する影響力を行使することによってチームがスクラムを行えるようにするのが、良いスクラムマスターです。

[new slide: manager]

[new slide: illustrate the ScrumMaster checklist]

For further information on the elusive ScrumMaster role, see the “Example ScrumMaster’s Checklist” , an example list of things the ScrumMaster would be concerned with fixing.

捉えどころの無いスクラムマスターの役割の詳細については、「スクラムマスター・チェックリスト」を参照してください。これはスクラムマスターが調整する内容を含んだ実例リストです。

スクラムマスターの役割は把握しづらいものです。更なる情報は「スクラムマスターチェックリスト」をご参照ください。スクラムマスターが調整する事項の実例リストです。

[existing slide: artifacts]

two important artifacts in Scrum are the Product Backlog and the Sprint Backlog.

スクラムの重要なアーチファクトに、プロダクトバックログとスプリントバックログの2つがあります。

プロダクトバックログ及びスプリントバックログの二つが、スクラムで重要なアーティファクトです。

[existing slide: Product Backlog]

The Product Backlog is a one-dimensional, force ranked list of customer-centric features, prioritized by the Product Owner.

プロダクトバックログは、顧客中心のフィーチャーを一次元レベルで順位付けしたリストのことで、優先順位を決定するのはプロダクトオーナーです。

プロダクトバックログとは、顧客中心の機能直線的に順位付けした強制力のあるリストで、プロダクトオーナーがその順位を決定します。

 It’s a list of everything we might ever do. If it’s not in the backlog, it doesn’t exist.

これは、私たちがやろうとする全てを含んだリストです。バックログにない仕事は存在しないとお考え下さい。

行う可能性のあることは全てこのリストに含まれています。バックログになければ、存在しないとお考えください。

Anyone can add items to the Product Backlog, but the Product Owner has got to prioritize them, and the ScrumMaster’s got to make it visible.

プロダクトバックログには誰でもアイテムを追加できます。しかし、優先順位を付けるのはプロダクトオーナーで、それを可視化させるのがスクラムマスターです。

プロダクトバックログには誰もがアイテムを追加できますが、それらに対してプロダクトオーナーが優先順位をつける責任を持ち、スクラムマスターはそれを可視化させる責任を持ちます。

A well formed Product Backlog does not contain tasks, only well-formed Product Backlog Items (or PBIs) which might be written in user story form, or maybe use case scenarios.

しっかり作られたプロダクトバックログにはタスクが含まれていません。あるのは、ユーザーストーリー・フォームやユースケースシナリオで書かれているようなプロダクトバックログアイテム(通称、PBI)だけです。

しっかり作られたプロダクトバックログにはタスクが含まれません。あるのは、ユーザーストーリー・フォームやユースケースシナリオなどの形で表現された、しっかり作られたプロダクトバックログアイテム(PBI)だけです。

[slide: Force Ranked]

Force ranked means there is only one thing in the top position. Getting organizations to do this is usually a breakthrough.

順位を付けるというのは、最重要項目は1つだけであることを意味します。これを行っていくことが、組織の変革へと繋がります。

順位に強制力があるというのは、最重要項目はただ一つであることを意味します。組織がこれを実践するのは、多くの場合ブレークスルーをもたらします。

[slide: multiple teams, one Product Backlog]

When multiple teams work on the Product, there's still only one Product Backlog.

複数チームでプロダクト開発する場合、プロダクトバックログは必ず1つ。

複数チームで一つのプロダクトを開発する場合にも、プロダクトバックログはただ一つだけです。

[slide: Sprint Backlog]

The Sprint Backlog is what we’re planning to do right now to meet our current Sprint Goal.

スプリントバックログは、現在のスプリントゴールを達成させるために計画されたものです。

スプリントバックログとは、現在のスプリントゴールを達成するために計画されたやるべき事項です。

It has an end date. It has a subset of Product Backlog Items selected for the Sprint, and a plan for how to do them, such as a list of Sprint Tasks.

これには期限があります。スプリントのために抜き出されたプロダクトバックログアイテムの集合で、どうやってそれを実行していくかというプランも含み、スプリントタスクのリストのようなものです。

ここでは期限があります。本スプリントのために抜き出されたプロダクトバックログのアイテム及びその実行計画を含みます。例えばスプリントタスクリスト等です。

[slide: Multiple Sprint Backlogs]

Multiple teams maintain their own separate Sprint Backlogs even if they work on the same Product.

たとえ複数のチームが同じプロダクトの開発をしていたとしても、それぞれ分けられたスプリントバックログを使います。

複数チームの場合は、たとえ同一のプロダクトを開発している場合であっても、スプリントバックログは別々です。

[slide: Meetings]

Now, let’s have an overview of the meetings in Scrum.

続いて、スクラムにおけるミーティングの全体像を見てみましょう。

では、次にスクラムにおける会議の概要を説明しましょう。

[existing slide: Meetings flowchart]

There are four meetings defined by Scrum and a fifth one that just about everyone has found useful to do.

スクラムは4つのミーティングを定義していますが、5つ目のミーティングは皆さんとって重要なものとなるでしょう。

スクラムが定義づけをする4つの会議のほかに、皆さんが有用だと考える5番目の会議があります。

The four meetings defined by Scrum:

スクラムで定義された4つのミーティングは、

スクラムが定義づける4つの会議とは、

The Sprint Planning Meeting, The Daily Scrum, The Sprint Review Meeting, and the Sprint Retrospective Meeting

スプリントプランニング、ディリースクラム、スプリントレビュー、スプリントレトロスペクティブです。

スプリントプランニング、ディリースクラム、スプリントレビュー、スプリントレトロスペクティブです。

The fifth one has no official name so we’ll call it the Backlog Refinement Meeting.

5つ目のミーティングには正式な名称がないので、バックログリファインメントと呼ぶことにしましょう。

5番目の会議は正式名称はありませんので、バックログリファインメント会議と呼ぶことにしましょう。

[calendar]

Here’s an example of how those meetings might fit into a two-week Sprint.  I personally like to end the Sprint on a Friday so we don’t work over the weekend.

ここでは、これらのミーティングが2週間のスプリントでどのように行われるかについて、一例をご紹介します。私は個人的に週末仕事をしたくないので、スプリントの終わりは金曜日になるよう設定します。

2週間のスプリントにおいてこれらの会議がどのように行われるか一例をご紹介します。私は個人的には、週末に働かずに済むようスプリントを金曜日に終えるのが好きです。

[existing slide: Sprint Planning Meeting]

At the Planning Meeting, the Team and the Product Owner choose which items to attempt in the sprint.

スプリントプランニングでは、チームとプロダクトオーナーがスプリントで実行しようとするアイテムを選択します。

プランニング会議では、チームとプロダクトオーナーが当該スプリントで実行すべきアイテムを選びます。

[existing slide: Sprint Planning Meeting with Sprint Backlog]

The team pulls selected items into the Sprint Backlog, plans how they will do them, and decides whether it’s the right amount of work for them to do. They plan one Sprint.

チームは選択したアイテムをスプリントバックログに移し、それをどのように実現させるか計画を立てます。そして1回のスプリントで対応可能な作業量であるかを判断します。

チームは、選ばれたアイテムをスプリントバックログに移し、どのように実行するかを計画対応するとともに、作業量が適切かを判断します。ここでは、一つのスプリントについて計画します。

[new slide: LeSS Sprint Planning Meeting][slide 46]

In Large Scale Scrum, multiple dev teams pull work from the same Product Backlog into multiple Sprint Backlogs.  

大規模スクラムでは、複数の開発チームが同一のプロダクトバックログから各チームそれぞれのスプリントバックログにアイテムを移していきます。

大規模スクラムにおいては、複数の開発チームが、同一のプロダクトバックログから各チームのスプリングバックログにアイテムを移します。

They plan to collaborate as a team of teams without intermediate coordinators.

チームは調整役を介さずに、チームの集合体として他チームと協働していくよう計画を立てます。

コーティネータの仲介なしで、複数チームが集まった一つのチームとして協働するよう計画を立てます。

[existing slide: Daily Scrum]

[@VJ: add 15-minute timer]

During Sprint Execution the Team meets once per day for a 15 minute Daily Scrum.

スプリントを実行している間、チームは毎日1回、15分間のデイリースクラムを実施します。

スプリントの実行期間中、チームは一日に一度、15分間のデイリースクラムで集まります。

If we’re collaborating we’re meeting all the time of course, but this one official meeting is defined where we stand up and find ways to help  each other.

もちろん一緒に仕事をしているなら、ずっと顔を合わせているわけですが、この公式なミーティングは立ったままで、お互いに協働していく方法を探っていきます。

一緒に仕事をしているのですから、もちろんずっと顔を合わせているのですが、この公式会議では、立ったまま、お互いに助け合うための方法を模索します。

We talk to each other. Not to the Scrum Master, not to the Product Owner, not to any kind of boss but to the Team.

チームはお互いに話し合います。スクラムマスター、プロダクトオーナー、上司といった人へ報告する場ではありません。

チームは相互に対話します。スクラムマスター、プロダクトオーナーや上司などに対して報告するのではなく、チームと話し合うのです。

I talk to the six other people that are my team members. I look them in the eye and I tell them what I did yesterday (“here’s what I did yesterday”), and I tell them what I’m going to do today, and I tell them what impedes me, what are my blockers. Then I toss the ball to someone else on my team and they talk to the rest of the team.

私は6人いるチームメンバーと話し合います。相手の目を見て、昨日は何をしたのか、(ここに昨日私がやったものがあります)、今日は何に取り組むのか、仕事を進める上で何が阻害要因なのかを報告します。そして、他のチームメンバーにボールを渡し、渡された人はチーム全員に向けて発言します。

例えば、私がチームメンバー6人に話をするとします。しっかりと相手の目を見て、自分が昨日やったこと(「昨日の作業報告」)、今日やる予定のこと、作業が進まない理由、自分にとっての阻害要因について話をします。そして他のチームメンバーに会話のボールを渡し、今度は彼らがチームに対して話をします。

[new slide: LeSS Sprint Execution][slide 49]

In Large Scale Scrum, each team has it's own Daily Scrum and uses various other collaboration patterns to work with the other teams.

大規模スクラムでは、各チームがそれぞれデイリースクラムを実施しつつ、他チームと協働する様々なコラボレーション・パターンを実行していきます。

大規模スクラムにおいては、各チームでデイリースクラムを行うほか、他のチームと協働するための様々なコラボレーションパターンを行います。

 All coordination responsibility belongs to self organizing teams, so there's no "release train engineer" or other management-assigned coordination role.

自己組織化したチームでは、コーディネーションの責任はすべて自分たちにあり、「リリース・トレイン・エンジニア」や、その他マネージメントを任命された調整役などはいません。

コーディネーションの責任はすべて、自己組織化したチームにあります。「リリース・トレイン・エンジニア」や、マネジメント役が割り当てた調整役などは存在しません。

 The Scrum Master tries to enable self-managing teams, so a good Scrum Master would never do the actual coordination.

スクラムマスターは、チームが自己組織化できるように支援します。したがって、良いスクラムマスターは、決して実際の調整役になることはありません。

スクラムマスターは自らマネジメントを行えるチームの能力を引き出します。ですから、良いスクラムマスターであれば、決して実際のコーティネート業務を行うことはありません。

[slide: SM teaches development skills]

The Scrum Master should help Teams learn f integration on the trunk, test-driven development, and other modern development practices.

スクラムマスターは、チームが開発主要部で継続的インテグレーション、テスト駆動開発、その他最新の開発プラクティスを学んでいけるよう支援します。

スクラムマスターは、チームが主要部での継続的インテグレーション、テスト駆動開発、その他の現代的な開発実践を学べるように支援を行います。

[existing slide: Sprint Review Meeting]

The purpose of the Sprint Review is to inspect and adapt the Product.

スプリントレビューの目的は、プロダクトの検証と適応です。

スプリントレビューでは、プロダクトを検証し適応することが目的です。

  The team demonstrates a potentially shippable product increment to anyone who’s interested — ideally customers and end users.

チームは、興味を持っている相手、理想的には顧客やエンドユーザーに対して、潜在的に出荷可能なインクリメントのデモンストレーションを行います。

チームは、潜在的に出荷可能なプロダクトの増分のデモンストレーションを、興味を抱いてくれている相手ー理想的には顧客やエンドユーザーーに対して行います。

We get feedback from stakeholders allowing us to inspect and adapt our future development.

そして、ステークホルダーからのフィードバックを得ることで、検証と適応を行い将来の開発に繋げていくことができます。

ステークホルダーからフィードバックを得ることで、今後の開発の検証と適応を行えます。

A lot of times the feedback is “Hey you did what you said you’d do, but now that we see it we realize that we need something else. And we couldn’t have known that until we saw the wrong product.”

フィードバックの中には、「みなさん、作ると言った通りの物を作ってくれたんだけど、実際見てみると、何か物足りないことに気が付いた。間違ったプロダクトを見るまで、気が付かなかった。」というものも、よく見受けられます。

時には、「約束通りのものを作ってくれたけど、実際に見てみると欲しいものとは違うことに気づいたよ。間違ったプロダクトを見るまでは気づくはずもなかった。」というフィードバックもよくあります。

People seem to need a functioning piece of software to react against before they can specify what they really want.

どうやら人々は本当に欲しいものを特定するまでに、実際動くソフトウェアが必要なようです。

どうやら人は、自分が本当に欲しいものを理解するには、実際に動くソフトウェアの一端が必要なようです。

In Large Scale Scrum, there's one Sprint Review of the multi-team integrated product.

大規模スクラムでは、複数チームが集まり、統合された1つのプロダクトのスプリントレビューを実施します。

大規模スクラムにおいては、複数チームの統合した1つのプロダクトについて、スプリントレビューを一回行います。

[Repeat existing slide: Product feedback loop]

Regular Sprint Review Meetings provide feedback about the product and its emerging requirements.

毎回行うスプリントレビューでは、プロダクトへのフィードバックと新たに生まれた要求が提示されます。

定期的なスプリントレビュー会議では、プロダクト及び明らかになった要求事項についてフィードバックを提供します。

[new slide: Sprint Retrospective Meeting]

Every Sprint ends with a Sprint Retrospective Meeting for the team to inspect and adapt their own process.

スプリントが終わるごとに、スプリントレストロスペクティブを実施し、プロセスの検証と適応を行います。

各スプリントの最後に、チームでスプリントレトロスペクティヴ会議を行い、自らのプロセスについて検証と適応を行います。

We inspect and adapt the way we worked together during the last iteration.

直近のイテレーションでの働き方に対する検証と適応です。

直近の回での協働の仕方について検証及び適応を行います。

We typically talk about what went well, what could be improved, what we learned and what still puzzles us. We give feedback to each other.

一般的に、私たちはうまくいったこと、改善が必要なこと、学んだこと、迷っていることを報告します。そしてお互いフィードバックを共有します。

典型的には、うまくいったこと、さらに改善できること、学んだこと、困惑していることについて話します。お互いにフィードバックを行います。

These kinds of things will come up in the Retrospective.  

このようなことが、レトロスペクティブで報告されるのです。

このようなことがレトロスペクティブでは行われます。

Some practical techniques for doing this well are covered in Module 6. This is really the key of the whole thing: the Team eventually takes ownership of their own process.

モジュール6の動画では、具体的な実践的方法について説明しています。最も重要なことは、チームが自分たちの開発プロセスに対してオーナーシップを持てるようになることです。

具体的な実践方法について、モジュール6で説明しています。最終的にチームが自分たちの開発プロセスに自分自身でオーナーシップを持つようになること。これが、全ての鍵となります。

In Large Scale Scrum, teams also have their own retrospectives.  

大規模スクラムでも、チームはそれぞれのレトロスペクティブを実施します。

大規模スクラムにおいても、チームはそれぞれのレトロスペクティブを実践します。

Afterwards, they conduct an overall retrospective with each other, the Product Owner, Scrum Masters, and managers (if there are any).

その後、プロダクトオーナー、スクラムマスター、もしいるならマネージャー達と、オーバーオール・レトロスペクティブを実施します。

その後、包括的レトロスペクティブをチーム相互、およびプロダクトオーナー、スクラムマスター、もしいればマネジャーとの間で行います。

 The Overall Retrospective explores systemic and organizational issues affecting multiple teams.

オーバーオール・レトロスペクティブでは複数チームに悪影響を及ぼすシステム的かつ組織的な課題を探します。

包括的レトロスペクティブでは、複数のチームに影響を及ぼす、システム的かつ組織的課題を探します。

[repeat existing slide: feedback loops with instrument measuring “Process”]

Regular Sprint Retrospectives provide feedback about the process the team uses to build the product.  

毎回のスプリントレトロスペクティブでは、チームのプロダクト作りのプロセスに関するフィードバックが示されます。

定期的なスプリントレトロスペクティブでは、チームのプロダクト開発に用いているプロセスへのフィードバックを示します。

Remember: Scrum is a framework for learning about products and the processes we use to build them.

覚えておいてほしいことは、スクラムは私たちが作るプロダクトと、その作成プロセスを学ぶためのフレームワークであるということです。

思い出していただきたいのは、スクラムとは、プロダクト及びそれを開発するにつき私たちが用いるプロセスについて学習することを目的としたフレームワークであるということです。

[new slide: Backlog Refinement Meeting]

During Backlog Refinement, the Team and the Product Owner get together and they look ahead a little bit into the next few items in the Product Backlog, the items that are candidates for the next couple Sprints.

バックログ・リファインメントでは、チームとプロダクトオーナーが協力し、次の複数回のスプリントで候補にあがっている、プロダクトバックログのいくつかのアイテムについて検討します。

バックログリファインメントにおいては、チームとプロダクトオーナーが集まって、プロダクトバックログ上で次に来るアイテム、つまり次の数回のスプリントで行うであろうアイテムをいくつか取り上げて、少し先のことを検討します。

 They clarify them, break the big Product Backlog Items (or epics) into small Product Backlog Items (for example: user stories) so they could imagine doing a few of them in a Sprint, get some input about prioritization, consider dependencies, etc.

そのアイテムを明確化し、大きなプロダクトバックログアイテム(あるいはエピック)を、(例えばユーザーストーリといった)小さなプロダクトバックログアイテムに分割することで、1つのスプリントで実行するアイテムの幾つかが想像でき、優先順位の情報が集められます。

そして、それらアイテムを明確化し、いちスプリントで実行する様子をイメージできるようにプロダクトバックログ上の巨大なアイテム(エピックとも言う)をプロダクトバックログ上の小さなアイテム(例:ユーザーストーリー)へと分解し、優先順位についてのインプットを得ます

While this work could also be done in the Sprint Planning Meeting, through experience, people have found it preferable to do it in a separate meeting on a different day.

この作業はスプリントプランニングでも行われますが、別の日に、別のミーティングでこれを行う方がいいということを経験の中で気付きました。

以上の作業はスプリントプランニング会議でも行えますが、経験を積む中で、別の会議で別の日に行う方が好ましいと気づきました。

[new slide: conclusion]

That was a brief overview of Scrum.

これが簡単なスクラム全体像となります。

スクラムの概要は以上です。

To learn a little more about Scrum, download the Scrum Reference Card and the ScrumMaster’s Checklist.

スクラムについてもう少し学ぶには、スクラムリファレンスカードとスクラムマスターチェックリストをダウンロードしてください。

スクラムに関してもう少し知りたい方のために、スクラムリファレンスカード及びスクラムマスターチェックリストをダウンロードできます。

To learn a lot more about Scrum, attend one of our Scrum classes, or try our other training modules that go into more depth.  

さらに深くスクラムを学びたいという方は、私たちが開催するスクラムトレーニングを受講すしてください、または、より深く踏み込んだ他のトレーニングモジュールをご覧ください。

更に深く学びたいという方は、当社のスクラム講義に参加するか、他のモジュールで更に踏み込んだ解説をご覧いただけます。

To get coaching in Scrum give us a call.  Also drop us a line to give feedback on this training module.

スクラムのコーチングが必要な場合は、ご連絡ください。また、このトレーニングモジュール動画に対するフィードバックもお待ちしております。

スクラムに関するコーチングが必要な場合はどうぞ当社へお電話ください。また、本トレーニングモジュール動画に対するご意見ご感想もお待ちしております。