Core Scrum
コアスクラム
What is Scrum?
スクラムとはなにか？
Scrum is the leading Agile product development framework.
It provides a foundation and path to delivering business goals in a collaborative, sane, and enjoyable manner.
スクラムはアジャイルな製品開発に導くためのフレームワークです。
活発で楽しく、より協調しながらビジネス目標を実現するための基礎と道筋を示すものです。
When was the last time you put "collaborative, sane, and enjoyable" in the same sentence with "business goals"?
あなたが「ビジネス目標」を宣言し、「協調的で、元気で楽しい」と最後に感じた時間はいつのことですか？
You may not remember unless you already use Scrum, but with Scrum you can, indeed, enjoy your work again!
まだスクラムを使っていないのなら覚えていないかもしれませんが、スクラムを使うと再び楽しみながら仕事することができます！
Scrum was created with software development in mind, but many other industries apply this framework to their own worlds. In fact, education, marketing, operations, and more are adopting Scrum and enjoying the benefits it brings them.
スクラムはソフトウェア開発の心得が元ですが、多くの他の業界でもこのフレームワークは採用されています。 実際、教育やマーケティング、運用業務などにもスクラムは採用され親しまれています。
How did Scrum originate?
スクラムの由来とは？
The concept that would become Scrum was first introduced to the world in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the "New New Product Development Game" (Harvard Business Review, January/February 1986).
スクラムのコンセプトは1986年に「より新しい商品開発ゲーム」（ハーバード・ビジネス・レビュー、1986年1月/ 2月）で、竹内 弘高と野中 郁次郎によって初めて世界に発信されました。
They defined their approach as a "flexible, holistic product development strategy" and proposed it would result in fast, flexible product development.
彼らはそのアプローチを「柔軟で総合的な製品開発戦略」と定義し、迅速で柔軟な製品開発をもたらすと提唱しました。
They called it the holistic or "rugby" approach because, much like in a rugby match, one cross-functional team passes the "ball" back and forth on the way to the "goal line."
彼らは、ラグビーの試合のように1つの機能横断的なチームが「ゴールライン」への道のりの中で「ボール」を前後にパスすることから、総合的な「ラグビー」アプローチと呼びました。
This was, and continues to be, in stark contrast to approaches that progress in a rigid, linear fashion.
これは、厳密に線形的な方法で進歩させるアプローチとは明らかに対照的でした。
Scrum Principles
スクラムの原則
The Agile Manifesto
アジャイルマニュフェスト
In 2001, 17 individuals gathered in the Wasatch mountains of Utah to find common ground around Agile.
2001年、アジャイルの共通の価値を見出そうとする17人がユタのワサッチ山脈に集まりました。
After much skiing, talking, relaxing, and eating, they arrived at four common values that led to the development of the Agile Manifesto.
多くのスキー、会話、リラックスしながら、そして食事の後、彼らはアジャイルソフトウェア開発宣言の発展につながる4つの共通の価値に到達しました。
Common Values from the Agile Manifesto
アジャイルソフトウェア開発宣言からの共通の価値
Scrum is an Agile framework and, as such, is consistent with the values of the Agile Manifesto.
スクラムはアジャイルのフレームワークであり、アジャイル・マニフェストの価値と一致しています。
Individuals and interactions over processes and tools
プロセスやツールよりも個人との対話を
Scrum is a team-based approach to delivering value to the business.
Team members work together to achieve a shared business goal.
スクラムは、ビジネスに価値をもたらすためのチームベースのアプローチです。
チームメンバーは協力しながらビジネス目標を共有します。
The Scrum framework promotes effective interaction between team members so the team delivers value to the business.
スクラムフレームワークは、チームメンバー間の効果的なやりとりを促進し、チームがビジネス価値をもたらすようにします。
Once the team gets a business goal, it:
チームがビジネス目標を達成すること、それは
・ Figures out how to do the work
生産性を定量化すること
・ Does the work
作業すること
・ Identifies what's getting in its way
途中で何が起きているのかを特定すること
・ Takes responsibility to resolve all the difficulties within its scope
その範囲内のすべての困難を解決する責任を負うこと
・ Works with other parts of the organization to resolve concerns outside their control
組織外の懸念を解決するために組織の他の部分と協力すること
This focus on team responsibility in Scrum is critical.
スクラムのチームがこれらの責任に焦点を当てることがとても重要です。
Working software over comprehensive documentation
包括的なドキュメントよりも動くソフトウェアを
Scrum requires a working, finished product increment as the primary result of every sprint.
スクラムでは、すべてのスプリントの主な結果として、インクリメントが必要です。
Whatever activities take place during the sprint, the focus is on the creation of the product increment.
どのような活動がスプリント中に行われても、焦点はプロダクトインクリメントの作成にあります。
A Scrum team’s goal is to produce a product increment every sprint. The increment may not yet include enough functionality for the business to decide to ship it, but the team’s job is to ensure the functionality present is of shippable quality.
スクラムチームの目標は、スプリントごとにインクリメントを作成することです。そのインクリメントにはまだビジネスが求める十分な機能は含まれていないかもしれませんが、チームは現在の機能が出荷可能な品質であることを保証する必要があります。
Customer collaboration over contract negotiation
契約交渉よりも顧客との協調（協業）を
Scrum is a framework designed to promote and facilitate collaboration.
Team members collaborate with each other to find the best way to build and deliver the software, or other deliverables, to the business.
スクラムは、コラボレーション（共同作業）の促進を目的としたフレームワークです。
チームメンバーはお互いに協力し、ソフトウェアやその他の成果物を作成しながらビジネスに提供する最良の方法を探求します。
The team, especially the product owner, collaborates with stakeholders to inspect and adapt the product vision so the product will be as valuable as possible.
チーム、特にプロダクトオーナーは、利害関係者（ステークホルダ）と協力しながら製品ビジョンを検査し、（ビジョンと製品を）適合させることで、製品の価値が高まるようにします。
Responding to change over following a plan
計画に従うことよりも変化への対応を
Scrum teams make frequent plans. For starters, they plan the current sprint. In addition, many teams create longer-term plans, such as release plans and product roadmaps.
スクラムチームは頻繁に計画を立てます。スクラムの初心者は現在のスプリントを計画し、さらに多くのチームにまたいだリリース計画やプロダクトロードマップなどの長期計画を作成します。
These plans help the team and the business make decisions.
However, the team’s goal is not to blindly follow the plan; the goal is to create value and embrace change. In essence, the thought process and ideas necessary for planning are more important than the plan itself.
これらの計画は、チームとビジネスの意思決定に役立ちます。
しかし、チームの目標は、計画をやみくもに順守することではありません。目標は価値の創造と、変化を受け入れることにあります。本質は思考のプロセスとアイデアであり、計画よりも重要です。
A plan created early is based on less information than will be available in the future so, naturally, it may not be the best plan. As new information is discovered, the team updates the product backlog. That means the direction of the product likely shifts.
早期に作成された計画は、将来利用できる情報よりも少ない情報に基づいているため、当然これは最善の計画ではない可能性があります。新しい情報が見つかると、チームはプロダクトバックログを更新します。 つまり、製品の方向性は変わる可能性があるということです。
This continuous planning improves the team’s chances of success as it incorporates new knowledge into the experience.
継続的に計画し改善することは、経験に新しい知識を取り入れ、チームの成功の可能性を上げます。
Scrum teams constantly respond to change so that the best possible outcome can be achieved. Scrum can be described as a framework of feedback loops, allowing the team to constantly inspect and adapt so the product delivers maximum value.
スクラムチームは絶えず変化に対応し、可能な限り最良の結果を残します。スクラムはフィードバックループのフレームワークと表すこともでき、チームが絶えず検査し適応することで、製品価値を最大化します。
Scrum Values
スクラムの価値
All work performed in Scrum needs a set of values as the foundation for the team's processes and interactions. And by embracing these five values, the team makes them even more instrumental to its health and success.
スクラムの全ての作業、チームのやり方と相互作用を発揮するためには以下の価値が必要です。
チームの健全さと成功は、これらの5つの価値観によって支えられています。
Focus
集中すること
Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
一度に集中する事柄を少なくし、共に働き、生産性を高めます。価値ある製品を早く届けます。
Courage
勇気を持つこと
Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
私たちは助け合い、余裕もってチームとして働きます。これは私たちに大きなチャレンジをする勇気を与えます。
Openness
解放的であること
As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.
共に働くことで、自分やチームのやり方に対する懸念事項があれば発信できます。
Commitment
コミットメント
Because we have great control over our own destiny, we are more committed to success.
私たちは自律的に行動しているため、更なる成功にコミットします。
Respect
尊敬
As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.
協力して成功と失敗を分かち合うこと、またお互いが尊重し合うことによって、お互いに尊敬し価値を認め合えるようになります。
As an organization applies Scrum it discovers its benefits. At the same time, it sees how these values inherently contribute to the success of Scrum and understands why they are both needed, and bolstered, by Scrum.
組織はスクラムを適用することでスクラムのメリットに気が付きます。同時に、これらの価値が本質的にスクラムの成功にどのように影響しているのかを理解し、スクラムがなぜ必要であり、強力であるかを理解できます。
Scrum Framework
スクラムフレームワーク
Scrum begins when customers need a product. The Scrum framework guides the creation of that product, with a focus on value and high visibility of progress.
スクラムは顧客がプロダクトを必要とするときに始まります。スクラムフレームワークは、価値と進捗状況の高い可視性によって、そのプロダクトを作成する道標となります。
Working from a dynamic list of the most valuable things to do, and using the Scrum framework, a Scrum team brings that product from an idea to life.
動的な作業リストのうち最も価値あるものから着手すること、またスクラムフレームワークを使用することによって、スクラムチームはアイデアを製品に取り入れます。
The Scrum framework is consistent across products and that is what makes it so useful.
You don’t have to modify the framework depending on the product; you use one across all.
スクラムフレームワークはどんな製品にも有効です。
製品に応じてやり方を変える必要はありません。;いずれにおいても、スクラムを実践すれば良いのです。
Scrum roles
スクラムの役割
A Scrum team has three roles:
スクラムチームに存在する３つの役割:
Product Owner -- holds the vision for the product
プロダクトオーナー -- 製品のビジョンを掴む
Scrum Master -- helps the team best use Scrum to build the product
スクラムマスター -- チームがスクラムを使用してプロダクトを作ることを支援する
Development team -- builds the product
開発チーム -- プロダクトを作る
The product is built incrementally in a series of short time periods called sprints. Sprints have a defined length, typically from one to four weeks.
Most teams find that short sprints work better than long ones.
During each sprint, the Scrum team builds and delivers a product increment, which is a shippable subset of the product.
プロダクトは、スプリントと呼ばれる一連の短期間で段階的に構築します。スプリントの長さは定義されており、通常1週間から4週間です。
ほとんどのチームは、短いスプリントの方が長いスプリントよりも優れていることを知っています。
各スプリントの間、スクラムチームは、製品の出荷可能なサブセットであるインクリメントを構築し提供します。
Each product increment is a recognizable, visibly improved, operating version of the product, meeting defined acceptance criteria and built to a level of quality called done.
各製品のインクリメントは、受入可能かつ目に見える形で改良されたプロダクトの動作可能な状態であり、あらかじめ定義された完了基準を満たし、DONEと呼ばれる品質レベルで構築されています。
Scrum artifacts
スクラムの成果物
Scrum features three tangible artifacts:
スクラムの特長である３つの成果物
Product increment -- an integrated, shippable subset of the product
プロダクトインクリメント -- 統合された出荷可能な製品のサブセットです
Product backlog -- the list of ideas for the product, in order of priority
プロダクトバックログ -- 製品のアイデアリスト、優先順に並んでいます
Sprint backlog -- the detailed plan for development during the next sprint
スプリントバックログ -- 次スプリントの開発に関する詳細計画です
The team displays its plans and progress so that all team members and stakeholders can always see what the team is accomplishing.
チームは、すべてのチームメンバーとステークホルダーがチームの成果を常に把握できるように計画と進捗状況を可視化します。
Scrum activities
スクラムの活動
Finally, Scrum includes five activities, or meetings:
最後、スクラムには5つのアクティビティまたは会議が含まれます。
Product backlog refinement
プロダクトバックログリファインメント
Sprint planning
スプリント計画
Daily Scrum
デイリースクラム
Sprint review
スプリントレビュー
Sprint retrospective
スプリントレトロスペクティブ
Scrum roles, artifacts, and activities work together within a Scrum cycle.
Let's take a look at each of these in more detail.
スクラムの役割、成果物、およびアクティビティは、スクラムサイクル内で機能します。
それぞれについて、より詳細に見てみましょう。
Scrum Roles
スクラムの役割
Every Scrum team has three roles, as stated above: product owner, Scrum Master, and development team.
The individuals in these roles work together to bring a product from an idea to life.
すべてのスクラムチームには、前述のとおり、プロダクトオーナー、スクラムマスター、開発チームの3つの役割が存在します。
これらの役割を担う人が協力し合うことで、アイデアを製品に活かします。
Product Owner
プロダクトオーナー
The product owner is the member of the Scrum team charged with maximizing the value of the team’s work. The product owner holds the product vision and works closely with stakeholders, such as end users, customers, and the business to cultivate and nurture a community around the product.
プロダクトオーナーは、チームワークの価値を最大限にすることを義務づけられたスクラムチームのメンバーです。 プロダクトオーナーは製品ビジョンを持ち、エンドユーザー、顧客、ビジネスなどのステークホルダーと密接に連携し、製品の周りのコミュニティを開拓し、教育支援もします。
They facilitate communication between the team and the stakeholders and ensure the team is building the right product.
They describe what should be built and why, but not how.
またチームとステークホルダーとのコミュニケーションを促進し、チームが適切なプロダクトを構築していることを確認します。
プロダクトオーナーは何を造らなければならないのか、またなぜそうするのかを記述するが、どのように実現するかまでは言及しません。
To fulfill the role, the product owner:
役割を担うとは、プロダクトオーナーの場合：
Decides what goes into the product backlog and, equally important, what does not
プロダクトバックログに何が入るのかと同時に、重要でないことを決定する
Maintains the product backlog and orders the items in the backlog to deliver the highest value
プロダクトバックログを常に改善し、バックログアイテムを示すことで高い価値を提供する
Works with the team and the stakeholders to continuously improve the quality of the product backlog and everyone’s understanding of the items it contains
チームやステークホルダーと継続し協力しながら、プロダクトバックログの品質と含まれるアイテムに対する全員の理解を改善する
Decides which product backlog items to ask the team deliver in the current sprint
現在のスプリントでチームが提供するバックログアイテムを決定する
Decides when to ship the product, with a preference toward more frequent delivery.
より頻繁なデリバリーを優先し、プロダクトの出荷時期を決定する
The product owner may be supported by other individuals but must be a single person to maintain clarity of the vision and priorities.
プロダクトオーナーは、他人からのサポートを受けることは可能ですが、ビジョンと優先順位を明確にするためには一人でなければなりません。
Scrum Master
スクラムマスター
The Scrum Master is a servant leader, helping the rest of the Scrum team progress. The Scrum Master keeps the Scrum team productive and learning. They must have a good understanding of the Scrum framework and the ability to train others to use it.
スクラムマスターはサーバントリーダーであり、他のメンバーの進捗を支援します。スクラムマスターは、スクラムチームの生産性と学習機会の維持に努めます。スクラムマスターはスクラムフレームワークとそれを使用する人を育成する能力について、よく理解していなければなりません。
The Scrum Master has three core responsibilities:
スクラムマスターには主に3つの役割があります。
Coach the team
チームのコーチ
The Scrum Master helps the entire team perform better. They help the product owner understand how to create and maintain the product backlog so the project is well defined and work flows smoothly to the team. They also work with the whole Scrum team to determine the definition of done.
スクラムマスターはチーム全体のパフォーマンスを向上させます。 プロダクトオーナーがプロダクトバックログを作成および維持する方法を理解できるよう、プロジェクトが明確に定義され、スムーズにチームが作業できるように支援します。 また、スクラムチーム全体と連携して、doneの定義を決定します。
The Scrum Master coaches the team on how to execute the Scrum process, helping them learn and use the framework and find and implement technical practices so they can reach done at the end of each sprint.
スクラムマスターは、スクラムプロセスの実行方法についてチームを指導し、フレームワークの学習と使用を支援し、各スプリントの終わりまでに（スプリント計画が）達成できるよう、テクニカルプラクティスを見つけて実行します。
Keep the team moving forward
チームを前進させ続ける
As a servant leader, the Scrum Master fosters the team's self-organization and then sees that distractions and impediments, or roadblocks, to the team's progress are removed.
サーバントリーダーとして、スクラムマスターはチームの自己組織化を促進し、チームの進歩に対しての注意散漫となる事象、または障害物が取り除かれていることを確認します。
Impediments may be external to the team, like lack of support from another team, or they could be internal, like the product owner not knowing how to prepare a proper product backlog. They may also facilitate regular team meetings to ensure that the team progresses on its path to done.
障害物は、チームの外部にいるかもしれません。例えば、他のチームからの支援の欠如のようなもの、またプロダクトオーナー自身が適切なプロダクトバックログの作成方法を知らない場合もあります。また、定期的なチームミーティングをファシリテートし、チームがdoneに確実に進めるようにすることもあります。
Help everyone understand Scrum
誰もがスクラムを理解できるように
The Scrum Master ensures that Scrum is understood and in place, both inside and outside the team.
スクラムマスターは、スクラムがチーム内外で理解されることに責任を持ちます。
They help people outside the team understand the process, as well as which interactions with the team are helpful and which are not.
スクラムマスターは、チーム外の人がスクラムのプロセスを理解すると同時に、チームを有効活用し相互作用が働くよう支援します。
The Scrum Master helps everyone improve to make the Scrum team more productive and valuable.
スクラムマスターは、スクラムチームの生産性と価値が向上するように全ての人を支援します。
Development team member
開発チームメンバー
The development team does the actual work of delivering the product increment. The team is a cross-functional group of professionals who, among them, have all the necessary skills to deliver each increment of the product. All team members should be available to the team and the project full time.
開発チームはプロダクトインクリメントを提供するための実作業を行います。 チームは、プロダクトの各インクリメントを提供するために必要なすべてのスキルを備えている多機能のグループです。すべてのチームメンバーはフルタイムにチームの一員としてプロジェクトに参加してもらう必要があります。
The product owner makes an ordered list of what needs to be done.
The development team members then forecast how much they can do in one sprint and self-organize to get the work done, deciding among themselves who does what to produce the new product increment.
プロダクトオーナーは、何をする必要があるかの順序付けられたリストを作成します。
開発チームのメンバーは、1回のスプリントでどれくらいのことができるかを予測し、作業を完了させるために自己組織化し、どの新しい製品のインクリメントを生産するかを決定します。
Scrum activities and artifacts: The Scrum cycle
スクラム活動と成果物：スクラムサイクル
Every Scrum cycle uses a series of activities to produce the tangible deliverables, or artifacts.
Let's go through the cycle and see how activities and artifacts are integrated.
すべてのスクラムサイクルでは、一連のアクティビティを通じて具体的な成果物が作成されます。
サイクルを進める中で、活動と成果物がどのような関係を持っているのかを見てみましょう。
Product backlog (artifact)
プロダクトバックログ（アーティファクト）
How do you know what needs to be done? By reviewing the Scrum artifact called the product backlog. This is an ordered list of ideas for the product, which can come from the product owner, team members, or stakeholders.
A description and estimate of effort complement each product backlog item.
DONEを満たすためにはどうすれば良いか？それを知るためにはプロダクトバックログと呼ばれるScrumの成果物を検討する必要があります。これはプロダクト所有者、チームメンバー、または利害関係者から得られるプロダクトのアイデアの順序付けしたリストです。
各プロダクトバックログアイテムは、重みづけによるの見積もりがなされています。
The product backlog is ordered to maximize the value delivered by the Scrum team. The development team’s work comes from the product backlog, and nowhere else. Every feature, enhancement, bug fix, documentation requirement every bit of work the team does comes from a product backlog item.
プロダクトバックログは、Scrumチームによって価値が最大化されるように作られています。
開発チームの仕事は、プロダクトバックログによって成り立ち、それ以外のものはありません。
すべての機能、拡張、バグ修正、文書化の要件すべて、チームが行うすべての作業は、プロダクトバックログアイテムから生まれます。
The product backlog may begin as a large or short list. It may be vague or well defined. Typically it begins short and vague and becomes longer and more defined as time goes on. Product backlog items slated for implementation soon will be "refined," which means they will further clarified, defined, and split into smaller chunks.
プロダクトバックログは、大きなもの、または短いものとしてリスト化されます。これらは曖昧である場合もあり、明確に定義されている場合もあります。典型的に、初めは短く曖昧ですが、時間の経過と共により長く、より明確になります。特に実装予定のプロダクトバックログアイテムは、早い段階で明確化され、定義され、より小さなチャンクに分割されることで「洗練された」ものとなります。
Though the product owner is responsible for maintaining the product backlog, the development team helps produce and update it.
プロダクトオーナーはプロダクトバックログを管理する責任がありますが、開発チームはそのプロダクトバックログの作成と更新を支援します。
Product backlog refinement (activity)
プロダクトバックログリファインメント（活動）
Product backlog items are often large and general in nature, and they can come and go as priorities change. Because of this fluid environment, product backlog refinement is an ongoing activity throughout a Scrum project.
When you refine the product backlog, you:
本来、プロダクトバックログアイテムは大きく大まか記載されますが、優先順位の変更によって入れ替えが発生します。このように流動的であるため、プロダクトバックログリファインメントは、スクラムのプロジェクト全体で継続的に行われます。
プロダクトバックログリファインメントをするときは、
Confirm the order of the product backlog items
プロダクトバックログアイテムの順序を確認する
Remove or demote items that no longer seem important
重要ではないと思われるアイテムを削除または降格する
Add or promote items that come up or become more important
上がったり、より重要になったりするアイテムを追加または宣伝する
Split larger items into smaller items
大きなアイテムを小さなアイテムに分割する
Merge smaller items into larger items
小さなアイテムを大きなアイテムに結合する
Estimate items
アイテムを見積もる
Identify which items are sprint-ready
どのアイテムがスプリント開始可能であるかを判別する
Product backlog refinement is an excellent way to prepare for upcoming sprints.
During this process, you give special attention to selecting items coming up for the next sprint.
プロダクトバックログのリファインメントは、今後のスプリントの準備に必要です。
このプロセスでは、次のスプリントの実行可能アイテムを選ぶための特別な注意を払う必要がります。
Things to consider include:
考慮すべき事項は次のとおりです。
Each item for the sprint should represent an increment of "business value."
スプリント期間中の各アイテムは、「ビジネス価値」に通じることを示す必要がある
The development team needs to be able to build each item within a single sprint.
開発チームは、単一のスプリント内で各アイテムを構築できる必要がある
Both the stakeholders and the entire Scrum team need to be clear on what is intended.
ステークホルダーとスクラムチーム全体は、意図されていることを明確にする必要がある
Depending on the nature of the product, other skills and inputs may be needed.
That's why product backlog refinement is really a responsibility of all team members, not just the product owner.
製品の特性によっては、新しいスキルや調査が必要な場合があります。
そのため、プロダクトバックログのリファインメントは、プロダクトオーナーだけでなく、すべてのチームメンバーで取り組む必要があります。
Sprint planning (activity)
スプリント計画（活動）
Each sprint begins with a time boxed meeting called sprint planning.
In this meeting, the Scrum team selects and understands the work to be done in the sprint.
各スプリントはスプリント計画と呼ばれるタイムボックス化された会議から始まります。
この会議では、スクラムチームはスプリントで行う作業を選択し、完了条件を理解します。
The entire team attends the sprint planning meeting.
Working from the product backlog, the product owner and the development team members discuss each item and come to a shared understanding of that item and what is required to complete it consistent with the current definition of done.
チーム全員がスプリント計画会議に出席します。
プロダクトバックログから作業レベルへの落とし込みにおいて、プロダクトオーナーと開発チームのメンバーは、そのアイテムの完了の定義についての共通の理解を得るための話し合いを行います。
The recommended time for the sprint planning meeting is two hours or less per week of sprint duration.
Because the meeting is time boxed, the success of the sprint planning meeting depends on the quality of the product backlog going in.
This is why product backlog refinement is so important.
スプリント計画ミーティングの推奨時間は、スプリント１週間当たり2時間以下です。
スプリント計画ミーティングはタイムボックス化されているため、その成功はプロダクトバックログの品質に依存します。
プロダクトバックログのリファインメントが重要である理由はこのためです。
In Scrum, the sprint planning meeting has two outcomes:
スクラムにおいて、スプリント計画会議では2つの成果が求められます。
1. A forecast of what work will be completed in the sprint
スプリントでどのような作業が完了するかの予測
2. A plan for accomplishing the work
仕事を達成するための計画
A forecast of what work will be completed in the sprint
スプリントで完了させる作業の見積もり
The product owner, who decides what to do, presents ordered product backlog items to the development team, and the whole Scrum team collaborates to review and understand the work.
プロダクトオーナーは何をすべきかを決定し、要求事項であるプロダクトバックログアイテムを開発チームに提示します。またスクラムチーム全体は協力し、その作業を理解しレビューします
The number of product backlog items to take on in the sprint is completely up to the development team. The team considers the current state of the product increment, the team’s past performance, its current capacity, and the ordered product backlog.
スプリントで使用するプロダクトバックログアイテムの数は、開発チームによって異なります。 チームは、プロダクトインクリメント（出荷可能状態となっているもの）の現在の状態、チームの過去のパフォーマンス、現在の作業キャパシティ、および注文されたプロダクトバックログを考慮します。
Neither the product owner nor anyone else can add work onto the development team. Often, but not always, the sprint is given a specific and measurable shared goal, called the sprint goal.
This goal, which summarizes why the sprint is happening, helps everyone focus on the essence of what needs to be done.
プロダクトオーナー含めて他の誰にも開発チームに作業（実現手段）を依頼することはできません。
ほとんどの場合スプリントゴールと呼ばれる特定の客観的判断が可能な共通の目標が与えられます。
スプリントゴールは、そのスプリントで実現したいことをまとめ、誰もが何をすべきか本質的に集中するのに役立ちます。
A plan for accomplishing the work
作業を完了させるための計画
The development team then collaborates to decide how to produce the next product increment to the definition of done.
開発チームは協力して、次のプロダクトインクリメントをどのように定義し、完了の定義を満たすかを決定します。
They need to be confident of completing the work during the sprint.
彼ら自身がスプリント期間内に作業を完了させることに自信を持っている必要があります。
Work to be done in the early days is broken down into small units of one day or less.
完了に向け、作業の近いものは、1日以下の小さな単位に分解します。
Work to be done later may be left in larger units to be broken down later.
後で行われる作業については、後で分解できるよう、より大きな作業粒度のままにしておきます。
The product owner is available during this part of the meeting to answer questions and resolve misunderstandings but has no part in determining how the work gets done.
プロダクトオーナーは、スプリント計画で誤解や認識齟齬が起こらないよう、開発チームからの質問に回答しますが、実現のための手段を指示することはありません。
Result of sprint planning
スプリント計画の結果
At the end of sprint planning, the Scrum team has a common understanding of the quantity and complexity of work to be accomplished during the sprint and can, within a reasonable range of circumstances, expect to complete it.
The team then commits to each other to accomplish it.
スプリント計画が終了するタイミングで、スクラムチームはスプリント中に達成すべき作業量や複雑さについての共通理解を持っており、スプリントゴールが妥当であると考えています。
そしてスクラムチームは互いにスプリントゴールを達成することを合意します。
To sum up the sprint planning meeting:
スプリント計画ミーティングをまとめるためには：
The product owner decides what to do
プロダクトオーナーは何を実現すべきかを決定する
Presents "what to do," using the product backlog items
プロダクトバックログアイテムを使用して「何をすべきか」を提示する
Answers questions and resolves misunderstandings about the product backlog items
プロダクトバックログアイテムに関する質問に回答し、誤解があれば解消する
The development team decides how much to take on and how to accomplish it
開発チームは、取り組むべきプロダクトバックログアイテムと、それを達成する方法を決定する
Considers and discusses product backlog items with the product owner
プロダクトバックログアイテムをプロダクトオーナーと検討する
Ensures a common understanding of them
チームとの共通理解を確保する
Selects a number of items they forecast they can accomplish
達成可能なプロダクトバックログアイテムの数を予測し、選択する
Creates a sufficiently detailed plan to be sure they can accomplish the items
プロダクトバックログアイテムを達成するために必要十分な詳細計画を作成する
The resulting list of things to do is the "sprint backlog."
「スプリントバックログ」が結果として得られます
Sprint backlog (artifact)
スプリントバックログ（アーティファクト）
The sprint backlog is the list of refined product backlog items chosen for development in the current sprint, together with the team's plan for accomplishing the work.
スプリントバックログは、現在のスプリントで開発するために選択された洗練されたプロダクトバックログアイテムのリストと、作業を達成するためのチームの計画です。
It reflects the team's forecast of what work can be completed.
スプリントバックログは、どのような作業が完了するかというチームの予測を反映しています。
Once the sprint backlog is established, the development team begins work on the new product increment.
スプリントのバックログの完成（確立）後、開発チームは新しいプロダクトインクリメントに着手します。
Sprint
スプリント
During the sprint, the development team self-organizes to produce the product increment defined by the sprint backlog.
スプリント中、開発チームはスプリントバックログによって定義されたプロダクトインクリメントを、自己組織化を通じて完成させます。
Self-organizing means that the members of the development team determine how to work together to best produce the product increment according to the organization's standards and the team's definition of done.
自己組織化とは、開発チームのメンバーが、組織の基準とチームの定義に従い、プロダクトインクリメントを最大限生み出すために協力する方法を独自に決定することを意味します。
Product increment (artifact)
プロダクトインクリメント（アーティファクト）
Every sprint produces a product increment, the most important Scrum artifact.
すべてのスプリントでプロダクトインクリメントを生み出すことこそ、スクラムにとって最も重要なアーティファクトです。
A product increment is the "goal line" for each sprint and, at the end of the sprint, it must:
プロダクトインクリメントは、各スプリントの「ゴールライン」であり、スプリントの終わりには、次の条件を満たす必要があります。
Be of high enough quality to be given to users
ユーザーにとって十分な品質が与えられていること
Meet the Scrum team's current definition of done
Scrumチームの現在のdoneの定義を満たしていること
Be acceptable to the product owner
プロダクトオーナーに受け入れられる状態であること
Additional indicators of progress
進行状況の追加指標
Scrum requires that people within and outside the team can see what the team is doing.
スクラムでは、チーム内だけでなく、チーム外の人々がチームの活動を見ることができます。
And though delivering the product increment is the most powerful way to create this transparency, the Scrum team might also create other optional but helpful artifacts.
プロダクトインクリメントを提供することが、スクラムの透明性を作り出す最も強力な方法ですが、スクラムチームは、透明性を更に確保するための他の有益なアーティファクトを作ることもできます。
These might include burn-down charts and task boards, to make sure the status of the project is understood by other teams and stakeholders.
プロジェクトのステータスを他のチームやステークホルダーが理解し確認するために、バーンダウンチャートやタスクボードを含めることもできます。
Definition of done
完了の定義
When the product increment is delivered, it needs to be "done" according to a shared understanding of what "done" means.
プロダクトインクリメントを提供するとき、「完了」についての共有理解に基づき「完了」する必要があります。
This definition is different for every Scrum team, and as the team matures, the definition of done will expand and become more stringent.
この定義はスクラムチームごとに異なり、チームが成熟するにつれて、完了の定義が拡大し、より厳しくなります。
The definition of done must always include the notion that the product increment is of high enough quality to be shippable.
完成品の定義には、プロダクトインクリメントが出荷可能なほど高い品質であるという概念が必ず含まれていなければなりません。
In other words, the product owner could choose to release it immediately.
つまり、プロダクトオーナーはプロダクトインクリメントを直ちにリリースすることができます。
The latest product increment includes the functionality of all previous product increments and is fully tested so that all completed product backlog items continue to work together.
最新のプロダクトインクリメントには、それ以前のすべてのプロダクトインクリメントの機能が含まれており、完成したプロダクトバックログアイテムが機能するように完全にテストされている必要があります。
Daily Scrum (activity)
デイリースクラム（活動）
The development team uses the Daily Scrum meeting to ensure that they are on track for that sprint.
They hold the meeting at the same time and place every day.
開発チームはデイリースクラム通じて、スプリントの進捗状況を確認します。
彼らは毎日同じ時間と場所で会議を開催します。
The meeting should be short and time boxed for a maximum of 15 minutes.
会議は、短時間であり最大15分間のタイムボックスで実施する必要があります。
During the meeting, each development team member gives three bits of information:
会議中、各開発チームのメンバーは3つの情報を提供します。
What he or she has accomplished since the last Daily Scrum
最後のデイリースクラム以降にどの作業を達成したか
What he or she plans to accomplish between now and the next Daily Scrum
次のデイリースクラムまでの間にどの作業を達成しようとしているか
What is impeding progress
現在の作業を妨げるものはなにか
Team members might ask brief clarifying questions and get brief answers, but they don't go into depth during the Daily Scrum.
デイリースクラムでは、チームメンバー同士が簡単な質問と受け答えを行いますが、深くは触れません。
Instead, subsets of the development team often meet right after the Daily Scrum to work on any issues that have come up.
代わりに、デベロッパーチームのサブセットは、デイリースクラムの直後に出てきて、問題が発生したときに作業することがよくあります。
The Daily Scrum is not a reporting event. It's a communication meeting within the development team that helps ensure that all team members are on the same page and moving forward.
デイリースクラムは報告イベントではありません。開発チーム全員が助け合い、同じ土俵である状態を確保するためのコミュニケーション促進を目的としたミーティングです。
Though interested parties are welcome to come and listen to the Daily Scrum, only the Scrum team members, including the Scrum Master and product owner, speak during this meeting.
利害関係者もデイリースクラムに歓迎はしますが、スクラムマスターとプロダクトオーナーを含むスクラムのチームメンバーだけがこのミーティング中に話すことができます。
Based on what comes up in the meeting, the development team reorganizes the work as needed to accomplish the sprint goal, if one has been established, and the product increment.
ミーティングで得た気づきに基づき、開発チームはスプリント目標を達成するため必要に応じて作業の再編成を行います。もし既にスプリントゴールが達成されている場合、新たなプロダクトインクリメントの着手についても検討します。
The Daily Scrum leads to transparency, trust, and better performance.
How? The daily check-in provides immediate recognition and resolution of problems and promotes the team's self-organization and self-reliance.
デイリースクラムは、透明性、信頼性、そしてより良いパフォーマンスをもたらします。
こういった毎日の手続きが、問題の即時認識と解決を促し、チームの自己組織化や自立を促進します。
Sprint review (activity)
スプリントレビュー（活動）
At the end of each sprint, the Scrum team and stakeholders review the resulting product increment.
スプリント終了時、スクラムチームとステークホルダーは作成したプロダクトインクリメントをレビューします。
This meeting is called a sprint review and should be time boxed one hour per week of the sprint. So if the sprint lasts two weeks, the recommended timebox for the sprint review is two hours.
この会議はスプリントレビューと呼ばれ、スプリントの１週間あたり1時間以下で実施する必要があります。 もしスプリントが2週間の場合、スプリントレビューの推奨タイムボックスは2時間となります。
The main point of discussion is the product increment completed during the sprint. Since the stakeholders are those who have a "stake" in the results, it's a good idea, and helpful too, for them to attend this meeting.
ディスカッションの主なポイントは、スプリント中に完了したプロダクトインクリメントです。
ステークホルダーは結果への「投資」をした人であるため、この会議に参加することが良いことであり、また役に立ちます。
During the meeting, the team members look at where they are and collaborate on how they might move forward.
ミーティング中、チームメンバーは自身の立ち位置を認識し、スプリントレビューの進行を協力をします。
Everyone has input at the sprint review.
And naturally, the product owner makes the final decisions about the future, updating the product backlog as appropriate.
全員がスプリントのレビューでインプット（プロダクトインクリメント、フィードバックなど）を持っています。
当然プロダクトオーナーは将来に関する最終的な決定を下し、必要に応じてプロダクトバックログを更新します。
Teams will find their own way to conduct the sprint review.
Some common components of the meeting include:
チームはスプリントレビューを実施する独自の方法を見つけるはずです。
この会議の一般的な構成要素は次のとおりです。
An overview of the product increment
プロダクトインクリメントの概要
A demonstration of the product increment
プロダクトインクリメントのデモンストレーション
A discussion of what team members observed during the sprint, or perhaps product ideas that came to mind
スプリント中にチームメンバーがどのようなことに注力したか、また思い浮かんだ製品のアイデア
A discussion about the state of the product backlog, possible completion dates, and what might be done by those dates
プロダクトバックログの状態、完成予定日、その日までに行われる可能性のあることについてのディスカッション（新たなプロダクトインクリメント、プロダクトバックログの変更の可能性、その他イベント等）
An update of the product backlog
プロダクトバックログの更新
Sprint retrospective (activity)
スプリントレトロスペクティブ（活動）
At the end of each sprint, the Scrum team meets for the sprint retrospective, which is again timeboxed for about an hour per week of the sprint duration.
各スプリントの終わりに、スクラムチームはスプリントレトロスペクティブ（振り返り）を行います。
スプリントレトロスペクティブは、スプリント１週あたり、約1時間のタイムボックスを設けます。
During the sprint retrospective, the team members review how the process went, including the intrapersonal relationships and the tools used.
スプリントレトロスペクティブの際、チームメンバーは、個人間の関係や使用されるツールを含め、スクラムのプロセスがどのように進行できたかをレビューします。
They talk about what went well and not so well, and they identify potential improvements.
スクラムチームはうまくいった事についてはあまり話さず、潜在的に改善可能な課題発見に注力します。
Then they come up with a plan for improving those things in the future.
スクラムチームは発見した課題を将来的に改善するための計画を練ります。
Remaining true to the Scrum framework, the Scrum team improves its own process versus relying on others to provide direction.
スクラムのフレームワークに乗っ取った上で、他者に依存せずスクラムチーム独自にプロセスを改善します。
Rinse and repeat
洗練と繰り返し
The Scrum cycle repeats for every sprint. In short:
スクラムサイクルはすべてのスプリントで繰り返します。 要するに：
The Scrum team members (product owner, development team, and Scrum Master) collaborate to create a series of product increments during timeboxed intervals called sprints
スクラムのチームメンバー（プロダクトオーナー、開発チーム、スクラムマスター）は協力して、スプリントと呼ばれるタイムボックスインターバルの間で一連のプロダクトインクリメントを作成する
Each product increment meets the product owner's acceptance criteria and the team's shared definition of done
各プロダクトインクリメントは、プロダクトオーナーのアクセプタンスクライテリア（受入基準）とチームで共有されている完了の定義を満たす必要がある
The team works from a product backlog
スクラムチームの仕事はプロダクトバックログから始まる
Each sprint begins with sprint planning to produce the sprint backlog,
which is a plan for the sprint
各スプリントはスプリント計画で始まり、まずスプリントバックログを作成する、
これはスプリント計画のこと
The team self-organizes to execute the development, using Daily Scrum meetings to coordinate and ensure the best possible product increment
チームは開発のために自己組織化されており、デイリースクラムミーティングによって最適なプロダクトインクリメントを調整する
The team performs product backlog refinement to prepare for the next sprint's planning meeting
スクラムチームはプロダクトバックログのリファインメントを行い、次のスプリント計画ミーティングに備える
The team ends the sprint with the sprint review and sprint retrospective, reviewing the product and the process
チームは、スプリントレビューとスプリントレトロスペクティブでスプリントを終了し、プロダクトとプロセスについてレビューする
Ready to put Scrum into practice?
スクラムを実践する準備はできただろうか？
Now you have an overview of the core elements of Scrum that you can use to deliver complex projects in a productive, sane, and enjoyable manner.
It's a proven framework, but this is just a start.
今あなたは、スクラムのコアと概要を理解し、複雑なプロジェクトを生き生きとした楽しいものにする準備ができました。スクラムは実績のあるフレームワークではありますが、これはほんの始まりにすぎません。
Applying the framework takes practice and trial and error.
However, the more you work with it, the better you'll be.
スクラムフレームワークの適用には、プラクティスの実践や試行錯誤が必要となりますが、
実践すればするほど、より良い方向へと導かれるはずです。
And Scrum Alliance is with you every step of the way, with Advocacy, Community, and Education that can make your Scrum journey easier, fun, and rewarding.
スクラムアライアンスは、アドボカシー（提言）、コミュニティ、そして教育の全てを通じて、あなたがスクラムの旅を楽しく、そしてより簡単に価値のあるものにできるよう応えることができます。
- Scrum Alliance Core Scrum v2014.08.15
- スクラムアライアンス コアスクラムv2014.08.15 Core Scrum translations コアスクラムの翻訳 Translations of the original Core Scrum document have been undertaken by CSCs, CSTs, and other Scrum community experts. We will work to update these translations. Here we list existing translations and honor the volunteers who are doing the work. 元のCore Scrumドキュメントの翻訳は、CSC、CST、および他のScrumコミュニティの専門家によって行われています。 私たちはこれらの翻訳を更新するよう努めます。 ここでは、既存の翻訳を列挙し、その作業を行っているボランティアを称えます。 Please visit the Scrum Alliance website at スクラムアライアンスのウェブサイトをご覧ください。https://www.scrumalliance.org/whyscrum/core-scrum-values-roles