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장

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)은 애자일 방법론과 스크럼 프레임워크 분야의 저명한 전문가들입니다. 공인 스크럼 트레이너(Certified Scrum Trainer)이자 애자일 러닝 랩스(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

이 책에 대한 FAQ

더 알아보기

학습 계획

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장

스크럼

개요스크럼 개요

한 권의 책, 다양한 듣기 방식.

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

스크럼: 팀의 잠재력을 깨우는 애자일 입문서 완독을 축하합니다

스크럼의 핵심 주제

스크럼의 명언

스크럼의 등장인물

저자 소개

스크럼: 팀의 잠재력을 깨우는 애자일 입문서 요약 다운로드

다른 사용자들도 좋아한 책

이 책에 대한 FAQ

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.

한 권의 책, 다양한 듣기 방식.

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

스크럼: 팀의 잠재력을 깨우는 애자일 입문서 완독을 축하합니다

다른 사용자들도 좋아한 책

더 알아보기

스크럼 개요