What is *The Elements of Scrum* by Chris Sims and Hillary Louise Johnson about?

*The Elements of Scrum* provides a comprehensive guide to the Scrum framework, blending theory with real-world examples to explain roles, artifacts, and events like sprints, backlogs, and daily standups. It contrasts Scrum with traditional methodologies like waterfall, emphasizes Agile principles, and covers supporting practices like Test-Driven Development. The book is widely used in academia and industry for its clear, example-driven approach.

Who should read *The Elements of Scrum*?

This book is ideal for software developers, project managers, and Agile coaches seeking practical insights into Scrum. It’s also valuable for educators and students in courses on software development or project management, as it’s taught at universities like UCLA and Arizona State. Beginners and seasoned practitioners alike benefit from its actionable frameworks.

Is *The Elements of Scrum* worth reading?

Yes, the book is praised for its engaging, narrative-driven style that simplifies complex concepts. It offers actionable advice for implementing Scrum, addresses common pitfalls, and includes technical practices like Pair Programming. Readers appreciate its balance of foundational theory and real-world application.

How does *The Elements of Scrum* compare to other Agile books?

Unlike drier technical manuals, *The Elements of Scrum* uses storytelling and vivid examples to demystify Scrum. It focuses specifically on Scrum (rather than Agile broadly) and is frequently compared to Jeff Sutherland’s *Scrum* for its depth on team dynamics and workflow. Its academic adoption sets it apart.

What are the key Scrum roles explained in the book?

The book details three core roles: - **Product Owner**: Defines goals and prioritizes the backlog. - **Scrum Master**: Facilitates processes and removes impediments. - **Development Team**: Executes tasks during sprints. It emphasizes cross-functional, self-organizing teams as critical to Scrum’s success.

What Scrum artifacts and ceremonies does the book cover?

Key artifacts include the **product backlog**, **sprint backlog**, and **burn charts**. Ceremonies like **sprint planning**, **daily standups**, **sprint reviews**, and **retrospectives** are explained with examples. The book stresses the importance of a clear “definition of done” to ensure quality.

How does *The Elements of Scrum* address user stories?

It explains user stories as tools to clarify *what* to build, *for whom*, and *why*. Stories are framed in non-technical language (e.g., “As a user, I want…”) to foster collaboration and prioritize customer-centric outcomes. The book also covers estimation techniques like story points.

What technical practices support Scrum in the book?

The authors advocate for **Test-Driven Development** (TDD), **Pair Programming**, and continuous integration to maintain code quality. These practices align with Scrum’s iterative approach, ensuring deliverables meet functional requirements.

スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法

クリス・シムズ＆ヒラリー・ルイーズ・ジョンソン

3(1 Reviews)

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の概要

世界中の大学で教材として採用されている、グローバルなガイド本『スクラムの要素（The Elements of Scrum）』で、プロジェクト管理に革命を起こしましょう。シムズとジョンソンは、魅力的なストーリーテリングを通じて、複雑なアジャイルの原則を実践的な知恵へと変貌させます。あなたのチームの生産性を劇的に向上させる突破口が、わずか40ページ先にあるとしたらどうでしょうか？

語り方を選ぶ

1冊の本。さまざまな聴き方。

スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法の同じアイデアを、あなたに合う声・深さ・ペースで学べます。いつでも切り替えられます。

第1章

Transforming Software Development: The Scrum Revolution

The year was 1993, and Jeff Sutherland was facing a critical software project at Easel Corporation with seemingly impossible deadlines. Traditional development methods had repeatedly failed his team. Desperate for a solution, he stumbled upon a Harvard Business Review article by Takeuchi and Nonaka that compared high-performing teams to rugby formations-where the whole team "moves as one unit, passing the ball back and forth." This metaphor sparked what would become a global revolution in software development. Today, Scrum is practiced by over 16 million professionals worldwide, has been adopted by 86% of software development teams, and has transformed industries far beyond software. Even tech titans like Google, Apple, and Microsoft credit their agility to Scrum principles. When Jeff Bezos mandated "two-pizza teams" at Amazon, he was essentially implementing Scrum's small, cross-functional team approach. The framework's influence has been so profound that in 2019, the Harvard Business Review named it one of the most important management ideas of the century.

第2章

The Waterfall's Fatal Flaw

The waterfall method dominated software development for decades despite a peculiar origin story: its creator, Winston W. Royce, actually presented it in 1970 as an example of how *not* to develop software. Ironically, Royce advocated for an iterative approach similar to today's agile methods, but his audience latched onto the sequential waterfall model instead. This misunderstanding became institutionalized when the US Department of Defense adopted waterfall as their official standard in 1985. Waterfall breaks software development into discrete sequential phases: requirements, design, implementation, verification, and maintenance. Each phase must be completed before the next begins, creating a one-way flow like water cascading down steps. This approach appealed to executives because it aligned with familiar budgeting and contracting processes, embracing a "big design up front" (BDUF) philosophy that promised to catch errors early by perfecting designs before implementation. But this approach fundamentally misunderstands software development. Unlike manufacturing physical objects, software systems are complex and unpredictable. No matter how detailed the initial specifications, unintended consequences inevitably emerge during implementation. By the early 2000s, even government agencies like NASA began recognizing waterfall's association with failed projects and astronomical costs. The evidence was damning: a 1995 Standish Group report revealed only 16% of traditionally-run software projects finished on time and within budget, while 31% were canceled outright. Something had to change.

聴きながら、すべての言葉を目で追えます

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の一語一語が音声に合わせてリアルタイムでハイライトされ、自然に読み進められます。

第3章

The Agile Rebellion

In February 2001, seventeen software development experts gathered at Snowbird ski resort in Utah. These self-described "organizational anarchists" represented various emerging methodologies like Extreme Programming, Crystal, and Scrum. Despite their different approaches, they shared a common frustration with heavyweight, documentation-driven processes that consistently failed to deliver working software. Over three days of skiing and discussion, they crafted the Agile Manifesto-a philosophical foundation that would transform the industry. The manifesto wasn't theoretical; it emerged from hard-won field experience of battle-scarred veterans who had independently developed iterative methodologies that actually worked. The manifesto's four core values prioritize: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan These seemingly simple statements require almost Zen-like discipline to practice consistently. The "over" phrasing is crucial-agile doesn't eliminate tools, documentation, contracts, or plans, but rather prioritizes human elements and adaptability. Think about it: how often have you seen organizations obsess over following a process or using a specific tool while neglecting the actual people doing the work? Or teams spending weeks producing detailed documentation that no one reads while the software itself remains unfinished? The agile values challenge these common dysfunctions by refocusing on what truly matters. The manifesto's twelve supporting principles provide practical guidance, emphasizing customer satisfaction through continuous delivery, embracing change, frequent software delivery, business-developer collaboration, building around motivated individuals, face-to-face communication, measuring progress through working software, sustainable pace, technical excellence, simplicity, self-organizing teams, and regular reflection. Together, these values and principles recognize that software development is fundamentally a journey of discovery requiring constant course correction, not rigid adherence to outdated plans.

第4章

The Business Case for Agility

Why should businesses care about agile methodologies? The answer is simple: they deliver value faster and more reliably than traditional approaches. Consider a fictional but realistic comparison between agile and waterfall approaches for the same project: six engineers, part-time product and project managers, and a $1 million yearly budget over 1.5 years. While both approaches cost the same, the difference in value delivery is staggering. The waterfall team spends the first six months gathering requirements and designing, with nothing to show customers. They then spend six months coding, followed by three months testing and fixing bugs. Only after 15 months do they finally release something customers can use and generate revenue from. Meanwhile, the agile team delivers working software from the first quarter, generating immediate revenue that self-funds the project by the second quarter. By the fourth quarter, while the waterfall team is still coding with no revenue, the agile approach has already paid for the entire project. After six quarters, the agile project has generated substantial profit while the waterfall project is just breaking even. The final tally? Despite identical revenue rates once the products are in market, the agile project delivers more than double the profit of waterfall. This dramatic difference occurs because agile's early and continuous delivery creates a compounding effect on return on investment. This isn't just theoretical. Companies like Spotify, Netflix, and Etsy deploy code to production dozens or even hundreds of times per day, continuously delivering new value to customers while their slower competitors struggle to release quarterly updates.

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』をもっと深く楽しむ

毎日の新しい気づきを10万件以上のレッスンから
言葉をハイライトして音声と同期
ライブラリを保存して、どの端末からでも利用

第5章

Scrum: The Framework That Changed Everything

Among agile methodologies, Scrum has emerged as the dominant framework, used by over 70% of agile teams worldwide. Its origin story begins in 1993 when Jeff Sutherland at Easel Corporation faced a critical software project that threatened the company's survival. After years of missed deadlines and failed projects, his CEO approved an experimental approach based on concepts from "Wicked Problems, Righteous Solutions" and Takeuchi and Nonaka's influential paper that compared high-performing teams to rugby players passing the ball back and forth. Sutherland's vision was to create a team that functioned like a "multi-headed super-programmer," where individuals would work in perfect synchronization. He implemented daily stand-up meetings, short iterative cycles, and self-organizing teams - revolutionary concepts at the time. Six months later, his team not only delivered on schedule but did so with such confidence that they offered customer guarantees-unprecedented in the software industry of the 1990s. This success attracted attention from other technology companies struggling with similar challenges. Parallel to Sutherland's work, Ken Schwaber was investigating why traditional project management methods were failing. At DuPont, scientists confirmed his suspicions that waterfall methods were fundamentally unsuitable for complex software projects, as they relied on predictive planning in an inherently unpredictable environment. This validation led to the development of Scrum's empirical "inspect and adapt" approach, which acknowledged the need for continuous adjustment based on real-world feedback. Sutherland and Schwaber formally introduced the Scrum framework in their groundbreaking 1995 paper at OOPSLA. Shortly after, physicist Mike Beedle demonstrated Scrum's effectiveness by successfully rescuing a major banking project that had been failing for 18 months, completing it in just three months using Scrum principles. The framework's success led to the formation of the Scrum Alliance, which has now certified over 100,000 practitioners worldwide. While maintaining its fundamental principles, Scrum has evolved beyond its initial "three roles, three ceremonies, three artifacts" definition to accommodate various industry contexts. Modern implementations often include refinements like sprint goals, definition of done, and scaled frameworks for larger organizations. At its core, Scrum continues to provide a lightweight framework that enables teams to deliver value through empirical process control-regularly inspecting and adapting both their product and their process through structured events like daily scrums, sprint reviews, and retrospectives. The framework's influence extends beyond software development, with organizations in healthcare, education, and government adopting Scrum principles to manage complex projects and drive innovation. Its success has spawned numerous variations and hybrid approaches, yet the fundamental principles of transparency, inspection, and adaptation remain constant.

第6章

The Three Pillars: Scrum Roles

Scrum recognizes just three distinct roles: product owner, scrum master, and team member-a radical simplification compared to traditional software teams with their architects, business analysts, developers, testers, and project managers. The product owner maximizes return on investment by directing the team toward valuable work and away from less valuable work. They control the priority order of backlog items and are the only person authorized to ask the team to do work or change priorities. As keeper of the product vision, they must be available to answer the team's questions throughout the sprint. This demanding role creates a healthy tension with the team-the product owner wants more while the team defends its sustainable pace. Due to this tension and workload, the product owner should be a dedicated role, not combined with other responsibilities. The scrum master coaches the team toward higher levels of cohesiveness, self-organization, and performance. Their deliverable is the self-organizing team itself. As the team's champion, guardian, facilitator, and scrum expert, they lead through influence rather than authority. This non-hierarchical position builds the trust needed to be an effective advisor and advocate. The scrum master "holds space" by monitoring processes, providing guidance, and serving as a sounding board. As teams become high-performing, a good scrum master adapts their style-teaching more with new teams, then stepping back as they mature. Team members have complete authority over how work gets done. They decide which tools and techniques to use, which members work on which tasks, and estimate how much work each feature requires. The ideal team size is seven, plus or minus two-enough for skill variety but not so many that communication becomes burdensome. On a scrum team, everyone shares the same job: helping deliver the sprint's committed stories. While team members bring unique expertise, these specialties shouldn't limit contributions. When the team needs different skills than someone's primary expertise, members adapt to serve the team's current needs. This approach maximizes team productivity rather than individual efficiency-a global optimization rather than local optimization. Think about traditional teams where specialists sit idle waiting for "their type of work" while others are overwhelmed. Scrum's cross-functional approach eliminates these bottlenecks by encouraging everyone to help wherever needed.

聴きながら、すべての言葉を目で追えます

第7章

The Sprint: Scrum's Heartbeat

The sprint cycle forms the foundational rhythm of scrum, reflecting the iterative approach common to all agile methodologies. Each sprint produces working software that could potentially be shipped to customers. While scrum doesn't specify sprint length, four weeks is generally the maximum, with two weeks being most popular. Teams typically need about six sprints to become proficient with agile processes, regardless of sprint length. For this reason, starting with one-week sprints allows teams to learn and adapt quickly. Sprint planning marks the beginning of each sprint, typically requiring one to two hours per week of development time. The meeting has two parts focused on what will be delivered and how the work will be accomplished. The team commits to stories they believe they can complete by sprint's end, using their velocity as a guide. The product owner presents prioritized stories, and the team decides how much work they can take on. In the second part, the team decomposes stories into tasks, which may be sized using task hours, task points, or simple task counts to track progress. The daily scrum, sometimes called the stand-up meeting, occurs daily at a regular time. Team members stand in a small circle to keep the meeting brief (under 15 minutes). Each participant quickly shares what they accomplished since the last meeting, what they expect to accomplish by the next meeting, and any obstacles slowing them down. This format immediately reveals schedule slips-with daily meetings, the schedule can slip by at most one day before the team becomes aware. Though not officially recognized as part of scrum, story time (or "backlog grooming") is a weekly one-hour meeting where the team works on upcoming stories rather than current sprint stories. The team assigns sizes to unsized stories and breaks larger stories into smaller ones, ensuring well-understood stories are always ready at the top of the backlog. At the sprint's end, the team demonstrates their completed work at the sprint review (or "sprint demo"). This meeting welcomes all stakeholders and serves as both a celebration of accomplishments and an opportunity to gather feedback, which the product owner may later use for backlog decisions. The retrospective, held at each sprint's end, gives the team dedicated time to reflect on what they learned and how to improve. Following the Retrospective Prime Directive that "everyone did the best job they could," the team focuses on continuous improvement rather than blame. A well-structured retrospective follows five steps: setting the stage, gathering data about what happened during the sprint, generating insights by finding patterns and causes, deciding on one specific improvement to implement, and closing by recognizing the team's work through appreciation exercises.

第8章

Making Work Visible: Scrum Artifacts

Scrum artifacts make the process visible, including traditional elements like backlogs and burn charts, along with the widely-used task board and the valuable definition of done. The product backlog is the cumulative list of desired deliverables-features, bug fixes, documentation changes, and anything valuable for the product. These "backlog items" (often called "user stories") are ordered strictly by priority, with well-defined, smaller items at the top and larger, less-defined items lower down. Like a garden, the backlog constantly evolves, with items becoming more refined as they move upward. The sprint backlog is the team's finite to-do list for the sprint, containing all committed stories, their associated tasks, and any additional tasks like team improvements from retrospectives. Once sprint planning ends, the product owner cannot change the story list, though the task list evolves throughout the sprint as new tasks are discovered or removed. Information radiators (or "big visible charts") are low-tech tools like hand-drawn charts and task boards displayed prominently on walls where everyone can see them. These physical displays engage more senses than software tools and keep information constantly visible to the team. Burn charts track work over time, with work remaining plotted vertically and time horizontally. Release burn down charts track work remaining across sprints, helping product owners monitor progress toward release. Sprint burn down charts track work remaining in the current sprint, helping teams monitor if they'll deliver everything committed. Task boards visibly display all sprint work, typically using columns like "to do," "doing," and "done" marked on a wall with painter's tape. Tasks written on sticky notes move across the board as work progresses, providing immediate visibility and the satisfaction of physically moving completed work. The Definition of Done (DoD) establishes shared criteria for when work is truly complete. Teams should collaborate to create their unique DoD and display it prominently. Unlike acceptance criteria (which define user-facing functionality), the DoD addresses technical requirements for shippability. A clear DoD prevents accumulating hidden technical debt of unplanned tasks needed before delivery.

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』をもっと深く楽しむ

毎日の新しい気づきを10万件以上のレッスンから
言葉をハイライトして音声と同期
ライブラリを保存して、どの端末からでも利用

第9章

User Stories: The Building Blocks of Value

User stories serve as the fundamental building blocks of the product backlog, focusing on capturing real user needs in a clear, actionable format. These stories translate complex requirements into digestible chunks that teams can effectively work with. While traditionally written on index cards for visibility and easy manipulation during planning, they're now often managed in digital tools while maintaining their essential simplicity. The widely adopted format "As a <type of user>, I want <to do something>, So that <some value is created>" efficiently captures three crucial elements: the user persona (who needs the functionality), the desired action (what they want to accomplish), and the expected benefit (why it matters). For example, "As a mobile banking user, I want to receive instant notifications for transactions, so that I can quickly detect unauthorized charges." User stories are deliberately kept brief and high-level, serving as conversation starters rather than exhaustive specifications. They typically contain just enough information to remind the team about the requirement's essence while leaving room for discovery and elaboration. This conciseness promotes flexibility and prevents teams from getting locked into detailed specifications too early in the development process. The real value emerges through collaborative conversations between developers, testers, product owners, and sometimes end users. These discussions provide richer context and nuanced understanding that written documentation alone cannot capture. Teams often use techniques like story mapping, wire-framing, and whiteboard sessions to explore different aspects of each story. Acceptance criteria transform abstract requirements into concrete, testable conditions. Written in plain English, they specify the boundaries and expectations that define when a story is complete. For example, a login story might include criteria like "Users must be locked out after three failed attempts" and "Password reset links expire after 24 hours." Experienced product owners ensure these criteria are defined and agreed upon before sprint planning to avoid mid-sprint confusion. The three components - story, conversation, and acceptance criteria - form what's known as the "3C's model" (Card, Conversation, Confirmation). This approach creates a complete requirements specification that balances efficiency with clarity. Stories capture initial ideas quickly, conversations allow for detailed exploration and shared understanding, and acceptance criteria document specific, testable expectations that guide development and testing efforts. Effective teams treat user stories as living documents that evolve through refinement sessions, adapting to new insights and changing business needs while maintaining their focus on delivering real user value. This flexibility, combined with clear success criteria, helps teams maintain agility while ensuring they build the right features right.

第10章

Beyond Estimation: Predictable Delivery

Traditional software projects often fail because they rely on absolute time estimates that humans are notoriously bad at providing. Scrum takes a different approach through relative sizing rather than time-based estimates. While humans are poor at estimating absolute time, we excel at relative sizing-comparing two things and determining which is bigger and by how much. Scrum teams use a two-step process: first assigning relative sizes to work items using "story points," then measuring how long actual items take to complete. Teams use Fibonacci numbers (1, 2, 3, 5, 8, 13, 21...) for story sizing because they increase at roughly the same rate humans perceive differences in size. This sequence provides enough granularity without encouraging pointless arguments over minor differences. After completing sprints, teams establish their velocity-the number of story points they can complete per sprint. Product owners use this metric to select appropriately sized stories for upcoming sprints. Velocity should never be used as a performance metric; it's about gaining predictability of schedule to produce more value. This approach creates predictability without requiring precise time estimates. A team might not know exactly how long a specific feature will take, but they can reliably predict how many story points they'll complete in a sprint, allowing for accurate release planning.

聴きながら、すべての言葉を目で追えます

第11章

Engineering Excellence: The Technical Practices

Scrum is a lightweight framework that doesn't prescribe how to write and test code. While teams must decide how to handle these aspects themselves, several complementary agile practices work well with Scrum. Refactoring is the primary technique for evolving system design in agile development. Martin Fowler defines it as "a disciplined technique for restructuring existing code, altering its internal structure without changing external behavior." With protective tests in place, developers can fearlessly modify and improve code, enabling rapid, agile development. Test-driven development (TDD) creates well-designed, verifiable code through the "red, green, refactor" cycle. Developers write an automated test first (which fails-"red"), implement code to make it pass ("green"), then improve the design through refactoring while ensuring tests still pass. Research at IBM and Microsoft showed TDD reduced defects by 40-90% without sacrificing productivity. Pair programming involves two developers writing code together at one computer. Rather than halving productivity, it produces better designed, cleaner code more quickly while eliminating knowledge silos. The resulting code has fewer defects and is easier to maintain-crucial since most development time is spent changing, not creating code. These practices aren't required to be a Scrum team, but they synergize powerfully with the framework, helping teams maintain quality and speed as they iterate rapidly.

第12章

Beyond the Team: Organizational Agility

For Scrum to reach its full potential, it needs organizational support beyond the individual team level. Release planning, user personas, story mapping, and project chartering help align teams with broader business objectives. Release planning determines which stories will be included in a product release and when that release should occur. Usually, either the feature set or the release date is fixed while the other remains variable-a business decision that guides the planning approach. Organizations new to Scrum often claim they have both fixed dates and fixed scope with fixed resources. When this approach hasn't been working, Scrum is not a magic solution-it simply makes the necessary trade-offs more visible. Scrum requires honest planning decisions rather than pretending impossible constraints can be met. User personas replace the flawed concept of an "average user" with specific fictional profiles based on real user behaviors. These personas help teams design for actual user needs rather than abstract generalizations. Microsoft's Office 2003 illustrates the problem of designing without clear personas-over 90% of users requested features that already existed among the 1,500+ commands, showing how designing for everyone serves no one well. Story mapping organizes user stories in a two-dimensional format that provides richer context than a traditional product backlog. While a product backlog is one-dimensional (prioritized from highest to lowest), a story map shows both priority and relationships between stories, helping teams understand how they fit together to form a complete product. A micro-charter efficiently captures a project's core idea in a brief, shareable document that helps prevent scope creep. It includes elements like code name, mission statement, vision statement, elevator pitch, business value, customers and users, metrics, milestones, resources, risks, and trade-offs. These practices help bridge the gap between team-level agility and organizational agility, ensuring that Scrum teams aren't just building the wrong things efficiently, but are aligned with true business value.

★★★★★

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』を最後まで読み終えました

100万人以上の学習者に愛用されています

“23日間、毎日使い続けています。今では日課の一部です。”

jayallen

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の主要テーマ

agile manifesto
iterative software development
cross-functional teams
scrum framework
adaptive project management

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の名言

The waterfall's fatal flaw.
Agile doesn't eliminate tools...but rather prioritizes human elements and adaptability.
Software development is fundamentally a journey of discovery.
The agile project delivers more than double the profit of waterfall.
Scrum: The framework that changed everything.

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の登場人物

Chris SimsAuthor and agile expert
Hillary Louise JohnsonAuthor and business writer
Jeff SutherlandCo-creator of Scrum at Easel Corporation
Winston W. RoyceComputer scientist who described Waterfall

著者について

『The Elements of Scrum』の共著者であるクリス・シムズ（Chris Sims）とヒラリー・ルイーズ・ジョンソン（Hillary Louise Johnson）は、アジャイル手法とスクラムフレームワークにおける著名な専門家です。認定スクラムトレーナーであり、Agile Learning Labsの創設者でもあるシムズは、ソフトウェア開発とプロジェクトマネジメントにおけるチームコーチングに20年以上の経験を持っています。小説家でありビジネスジャーナリストでもあるジョンソンは、『Inc Magazine』や『Los Angeles Times』などの出版物に寄稿しており、物語の明快さと技術的な洞察を融合させています。二人のコラボレーションは、実践的なスクラムのガイダンスと魅力的なストーリーテリングを融合させ、あらゆる業界のプロフェッショナルに向けてアジャイルの原則を解き明かしています。

この国際的なベストセラーに加え、二人はUCLAやアリゾナ州立大学などの大学で採用されている簡潔なガイド『Scrum: A Breathtakingly Brief and Agile Introduction』を共著しています。スクラムマスターとしてのシムズの実践的な専門知識と、知的財産やフィクションにおけるジョンソンの経歴は、複雑なフレームワークを親しみやすい実践へと変換する彼らのアプローチを豊かなものにしています。『The Elements of Scrum』は中国語にも翻訳されており、世界中の学術および企業研修プログラムの基礎テキストとして活用されており、アジャイルプロジェクトマネジメントにおけるその永続的な影響力を反映しています。

スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法の要約をダウンロード

スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法の要約をPDFまたはEPUBで無料でダウンロード。印刷やオフラインでいつでもお読みいただけます。

他のユーザーのお気に入り

Scrum

Jeff Sutherland

The Scrum Fieldbook

J.J. Sutherland

Scrum Insights for Practitioners

Hiren Doshi

Learning Agile

Andrew Stellman & Jennifer Greene

Agile Project Management for Beginners

Bryan Mathis

Agile Testing

Lisa Crispin

Scrum Story Points, Epics & Themes Explained の書籍表紙

6 sources

Scrum Story Points, Epics & Themes Explained

Making Ideas Happen

Scott Belsky

この本に関するよくある質問

学習プラン

The Science of Starting

This plan is essential for professionals and students who struggle with procrastination and the paralysis of starting new tasks. It provides a scientific approach to overcoming biological resistance and optimizing your digital environment for maximum output.

1 h 45 m•3 セクション

学習プラン

Learn Project Management for Beginners

This plan is essential for aspiring managers looking to bridge the gap between basic task tracking and strategic leadership. It benefits professionals across industries who need to deliver complex projects on time while managing diverse teams and methodologies.

4 h 18 m•4 セクション

学習プラン

The Systems Thinking Advantage for Founders

In the volatile world of startups, founders often fall into the trap of reactive management. This learning plan is essential for entrepreneurs who want to move beyond chaos by mastering the structural dynamics of their business. It is ideal for early-stage leaders aiming to build scalable, stable organizations through first-principles design.

1 h 30 m•3 セクション

学習プラン

The Strategic Mindset Toolkit

In an era of information overload, the ability to see what others miss is a critical competitive advantage. This plan is designed for leaders and problem-solvers who need to navigate complexity using systemic analysis and creative logic.

1 h 45 m•3 セクション

学習プラン

Energy First: The Sustainable Productivity System

Traditional time management often ignores the biological reality of human performance, leading to burnout. This system is designed for high-performers and knowledge workers who need to optimize their cognitive output while maintaining long-term health and focus.

2 h•4 セクション

学習プラン

The Bullet Journal Strategy

In an era of digital distraction, this strategy offers a tactile, intentional approach to personal management. It is ideal for professionals and creatives who need to bridge the gap between daily chaos and long-term aspirations through structured reflection.

1 h 30 m•3 セクション

学習プラン

Strategic Power Dynamics for Projects

In complex organizational environments, technical skill alone is often insufficient for project success. This plan is designed for project leads and aspiring managers who need to master the unspoken rules of influence and historical power strategies to drive results.

30 m•1 セクション

学習プラン

The Resilient Schedule Framework

In an era of constant distraction, traditional time management often fails because it is too rigid. This framework is essential for professionals who need to balance high-level productivity with the unpredictable nature of modern work life.

1 h 30 m•3 セクション

コロンビア大学卒業生がサンフランシスコで開発

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

BeFreedがウェブ上でどのように話題になっているかをもっと見る

コロンビア大学卒業生がサンフランシスコで開発

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

BeFreedがウェブ上でどのように話題になっているかをもっと見る

今すぐ学習の旅を始めよう

第5章

スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法

概要『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の概要

1冊の本。さまざまな聴き方。

Transforming Software Development: The Scrum Revolution

The Waterfall's Fatal Flaw

聴きながら、すべての言葉を目で追えます

The Agile Rebellion

The Business Case for Agility

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』をもっと深く楽しむ

Scrum: The Framework That Changed Everything

The Three Pillars: Scrum Roles

聴きながら、すべての言葉を目で追えます

The Sprint: Scrum's Heartbeat

Making Work Visible: Scrum Artifacts

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』をもっと深く楽しむ

User Stories: The Building Blocks of Value

Beyond Estimation: Predictable Delivery

聴きながら、すべての言葉を目で追えます

Engineering Excellence: The Technical Practices

Beyond the Team: Organizational Agility

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』を最後まで読み終えました

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の主要テーマ

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の名言

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の登場人物

著者について

スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法の要約をダウンロード

他のユーザーのお気に入り

この本に関するよくある質問

What is The Elements of Scrum by Chris Sims and Hillary Louise Johnson about?

Who should read The Elements of Scrum?

Is The Elements of Scrum worth reading?

How does The Elements of Scrum compare to other Agile books?

もっと見る

1,000,000+ curious minds.

1,000,000+ curious minds.

1冊の本。さまざまな聴き方。

Transforming Software Development: The Scrum Revolution

The Waterfall's Fatal Flaw

聴きながら、すべての言葉を目で追えます

The Agile Rebellion

The Business Case for Agility

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』をもっと深く楽しむ

Scrum: The Framework That Changed Everything

The Three Pillars: Scrum Roles

聴きながら、すべての言葉を目で追えます

The Sprint: Scrum's Heartbeat

Making Work Visible: Scrum Artifacts

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』をもっと深く楽しむ

User Stories: The Building Blocks of Value

Beyond Estimation: Predictable Delivery

聴きながら、すべての言葉を目で追えます

Engineering Excellence: The Technical Practices

Beyond the Team: Organizational Agility

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』を最後まで読み終えました

他のユーザーのお気に入り

もっと見る

『スクラムの基本 ― アジャイルなチーム、プロダクト、組織をつくる方法』の概要