Core Scrum === ###### tags: `Scrum` source: [Core Scrum](https://www.scrumalliance.org/ScrumRedesignDEVSite/media/ScrumAllianceMedia/Files%20and%20PDFs/Learn%20About%20Scrum/Core-Scrum.pdf) ScrumAllianceのスクラムコーチの方によると、スクラムコーチのスクラムの定義の原典はScrumGuideではなくCoreScrumだとのこと。ScrumGuideは、それを元に実践用に噛み砕いたりプラクティスを組み位入れたもの、だとのこと。 読んでみたら、実際こちらの方がvalueの記述が丁寧だったり非常に説得力があるとおもったので、和訳した。 # 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年に "New New Product Development Game"（Harvard Business Review、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." 彼らはそれを全体論的または「ラグビー」アプローチと呼んでいました、というのも、ラグビーの試合のように、ある機能横断型チームが「ボール」を「ゴールライン」に向かって行ったり来たりするためです。 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. After much skiing, talking, relaxing, and eating, they arrived at four common values that led to the development of the Agile Manifesto. 2001年、17人がユタ州のワサッチ山脈に集まり、アジャイル周辺に共通認識を見出しました。 スキー、会話、リラックス、そして食事の後、彼らはアジャイルマニフェストの開発につながった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: チームがビジネス目標を理解(gets a business)すると、次のようになります。 * 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. スクラムで実行されるすべての作業は、チームのプロセスと共同作業の基盤として一連のValue(価値観)を必要とします。そして、これら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. 私たちが共同するとき、私たちは自分たちのしていること、やり方、懸念していること表明(express)することにより、それらを上手く対処(address)できるようにします。 ## 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 組織がスクラムを適用すると、その利点を発見します。同時に、これらのValueがスクラムの成功にどのように本質的な貢献をしているのかを理解し、それらがスクラムによって必要とされ、支持されている理由を理解するようになります。 --- # 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: スクラムチームには3つの役割があります。 * Product Owner -- holds the vision for the product プロダクトオーナー -- 製品のビジョンを保持します * ScrumMaster -- 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. この製品は、スプリントと呼ばれる一連の短期間で段階的に構築されます。スプリントの長さは決まっていて、通常1〜4週間です。 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. 各スプリントの間に、スクラムチームは製品の増分を作成して提供します。これは製品の出荷可能なサブセットです。 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. 各製品の増分は、明確に認識され、目に見えて改善された製品の動作バージョンであり、定義された許容基準を満たし、完了と呼ばれるレベルの品質に構築されています。 ## Scrum artifacts Scrum features three tangible artifacts: スクラムには、3つの具体的な成果物があります。 * 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 スプリントバックログ - 次のスプリントにおける開発のための詳細な計画 > [name=little-hands]プロダクトインクリメントについて 意訳：出荷可能な品質の成果物 プロダクト＝ソフトウェアとは限らない。「成果物」ぐらいの訳が適切そう。(参考：[weblio](https://ejje.weblio.jp/content/produkp['/./ct)) (スクラムはソフトウェア業界以外でも適用される) また、出荷(Ship)とは： ・ソフトウェアならリリース ・制度なら実際の組織に適用 ・チームビルディングならチームとしての活動開始 といったような解釈と思われる 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 Role Every Scrum team has three roles, as stated above: product owner, ScrumMaster,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 チームと利害関係者と協力して、プロダクトバックログの品質とそれに含まれるPBIに対する全員の理解を継続的に向上させる。 * Decides which product backlog items to ask the team deliver in the current sprint チームに現在のスプリントでの着手を依頼するPBIを決定する * 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. プロダクトオーナーは他の個人によってサポートされてもよいですが、ビジョンと優先順位の明快さを維持するために一人の人物でなければなりません。 ## ScrumMaster The ScrumMaster is a servant leader, helping the rest of the Scrum team progress. スクラムマスターはサーバントリーダーで、他のスクラムチームメンバーの進歩を助けます。 The ScrumMaster 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 ScrumMaster has three core responsibilities: スクラムマスターには、3つの中心的な責任があります。 ### Coach the team チームをコーチングする The ScrumMaster 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 ScrumMaster 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. スクラムマスターはスクラムプロセスをどのように実行するかについてチームをコーチングし、彼らがフレームワークを学び、使用し、技術的なプラクティスを見つけて実行し、各スプリントで「Done」に到達できるようにします。 ### Keep the team moving forward チームを前進させ続ける As a servant leader, the ScrumMaster fosters the team's self-organization and then sees that distractions and impediments, or roadblocks, to the team's progress are removed. サーバントリーダーとして、スクラムマスターはチームの自己組織化を促進し、それからチームの進歩に対して気を散らせるもの、妨害(impediments)、問題を取り除きます。 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. 妨害(impediments)は、他のチームからのサポートの欠如のようにチームの外部にある場合もあれば、プロダクトオーナーが適切なプロダクトバックログを準備する方法を知らない場合のように内部にある場合もあります。 They may also facilitate regular team meetings to ensure that the team progresses on its path to done. また、チームが「Done」に向かって進むことを確実にするために、定期的なチームミーティングを促進するかもしれません。 ### Help everyone understand Scrum 誰もがスクラムを理解するのを手伝う The ScrumMaster 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 ScrumMaster 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 ## 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. 説明と工数見積もりは、各PBIを補完します。 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. すべての新規機能、機能追加、バグ修正、要件の文書化など（つまり、チームが行うすべての作業）は、プロダクトバックログ項目に由来します。 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. PBIは、多くの場合大きくて一般的な性質のものであり、優先順位の変更に応じて増減する可能性があります。 Because of this fluid environment, product backlog refinement is an ongoing activity throughout a Scrum project. この流動的な性質(environment意訳)のため、リファインメントはスクラムプロジェクト全体を通して継続的に行われています。 When you refine the product backlog, you: リファインメントでは以下のようなことを実施します * Confirm the order of the product backlog items PBIの優先順位を決定する * Remove or demote items that no longer seem important 重要ではなくなったPBIを削除、または優先順位を下げる * Add or promote items that come up or become more important 重要性が上がったPBIを追加、または優先順位を上げる * Split larger items into smaller items 大きなPBIを小さなPBIに分割する * Merge smaller items into larger items 小さいPBIを大きいPBIにマージする * Estimate items PBIを見積もる * Identify which items are sprint-ready 「スプリントレディ」な状態のPBIを決定する 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. このプロセスにおいて、その次のスプリントのPBIは特に注意して選択します。 Things to consider include: 検討事項は次のとおりです。 * Each item for the sprint should represent an increment of "business value." スプリントに割り当てられるPBIは「ビジネス価値」を増加する必要があります。 * The development team needs to be able to build each item within a single sprint. 開発チームは単一のスプリント内で各PBIを構築できる必要があります。 * 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. プロダクトバックログから作業し、プロダクトオーナーと開発チームメンバーがそれぞれのPBIについて話し合い、PBIごとに現在のDoneの定義に基づいて「完了」するために必要なものについて、現在理解していることを共有します。 The recommended time for the sprint planning meeting is two hours or less per week of sprint duration. スプリントプランニングの推奨時間は、スプリント期間1週間あたり2時間以内です。 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. これが、プロダクトバックログリファインメントが非常に重要な理由です。 ### Scrum planning outcomes 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 仕事を達成するための計画 #### 1. 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. 何をすべきかを決定するプロダクトオーナーは、優先順位がつけられたPBIを開発チームに提示し、スクラムチーム全体が共同で作業をレビューし、理解します。 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. １スプリントで着手するPBIの数は、開発チームに完全に任されています。チームは、プロダクトインクリメントの状況、チームの過去の実績、現在の処理能力、優先順位付けられたプロダクトバックログを考慮して決定します。 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. 必ずというわけではありませんが、スプリントには「スプリント目標」と呼ばれる特定の測定可能な共通の目標が与えられることが多々あります。スプリントが発生している理由を要約したこの目標は、全員が行うべきことの本質に集中するのに役立ちます。 #### 2. 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. その後、開発チームは協力して、次のインクリメントを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. チームはそれからそれを達成することをコミットします。(達成することに全力を尽くします。) ### Sum up the sprint planning meeting スプリントプランニングに関するまとめ * The product owner decides what to do プロダクトオーナーが何をするかを決定します * Presents "what to do," using the product backlog items PBIを使用して、「何をするか」を提示します。 * Answers questions and resolves misunderstandings about the product backlog items PBIに関する質問に答え、誤解を解決します。 * The development team decides how much to take on and how to accomplish it 開発チームは、どの程度引き受けるべきか、そしてそれをどのように達成するかを決定します。 * Considers and discusses product backlog items with the product owner PBIについて、プロダクトオーナーと議論し、検討します。 * 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. スプリントバックログは、作業を達成するためのチームの計画と共に、現在のスプリントで開発するために選択された洗練されたPBIのリストです。 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. 自己組織化とは、開発チームのメンバーが、組織の標準とチームの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 スクラムチームの現在の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. プロダクトインクリメントを提供するためには、「Done」の意味についての共通の理解に従って完了(Done)する必要があります。 This definition is different for every Scrum team, and as the team matures, the definition of done will expand and become more stringent. この定義はスクラムチームごとに異なり、チームが成熟するにつれて、Doneの定義は拡大し、より厳密になります。 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. Doneの定義には、プロダクトインクリメントが出荷可能であるために十分に高い品質であるという概念を常に含める必要があります。言い換えれば、プロダクトオーナーがすぐにリリースという選択ができる状態ということです。 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) 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 ScrumMaster 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. デイリースクラムは、透明性、信頼、そしてパフォーマンスの向上につながります。どのようにでしょうか？毎日の確認(check-inn)で問題を即座に認識して解決し、チームの自己組織化と自立を促進します。 ## 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週間あたり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週間あたり約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 ScrumMaster) 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 各プロダクトインクリメントは、プロダクトオーナーの受け入れ基準とチームの共通の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. そしてスクラムアライアンスは、アドボカシー、コミュニティ、そして教育によって、あなたのスクラムの旅をより簡単に、楽しく、そしてやりがいのあるものにするお手伝いをします。