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.

Scrum要素

克里斯·西姆斯和希拉里·路易丝·约翰逊

3(1 Reviews)

《Scrum要素》概述

通过全球高校采用的权威指南《Scrum 要素》（The Elements of Scrum），彻底革新您的项目管理方式。通过引人入胜的叙述，Sims 和 Johnson 将复杂的敏捷原则转化为实用的智慧。如果您的团队实现生产力重大突破的关键就在这短短 40 页的内容中，结果会如何？

选择讲述方式

一本书，多种聆听方式。

来自《Scrum要素》的相同理念。选择适合你的声音、深度和节奏，随时切换。

第 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.

边听边看，每个词都清晰呈现

轻松跟读，《Scrum要素》中的每个词都会随音频实时高亮。

第 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.

从《Scrum要素》中收获更多

每日获取新洞见，探索 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.

边听边看，每个词都清晰呈现

轻松跟读，《Scrum要素》中的每个词都会随音频实时高亮。

第 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.

从《Scrum要素》中收获更多

每日获取新洞见，探索 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.

边听边看，每个词都清晰呈现

轻松跟读，《Scrum要素》中的每个词都会随音频实时高亮。

第 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.

★★★★★

你已读完《Scrum要素》

深受 100 万+ 学习者喜爱

“坚持使用 23 天了，我每天都会打开它。它现在已经成为我的日常习惯。”

jayallen

《Scrum要素》核心主题

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

《Scrum要素》经典语录

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.

《Scrum要素》主要人物

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

关于作者

Chris Sims 和 Hillary Louise Johnson 是《The Elements of Scrum》的共同作者，也是敏捷方法论和 Scrum 框架领域的知名专家。Sims 是一位认证 Scrum 培训师（Certified Scrum Trainer）及 Agile Learning Labs 的创始人，在软件开发和项目管理团队辅导方面拥有超过二十年的经验。Johnson 是一位小说家和商业记者，曾为《Inc Magazine》和《洛杉矶时报》（Los Angeles Times）等刊物撰稿，她将叙事的清晰度与技术洞察力完美结合。他们的合作将实用的 Scrum 指导与引人入胜的叙述融为一体，为各行各业的专业人士揭开了敏捷原则的神秘面纱。

除了这部国际畅销书外，他们还合著了《Scrum: A Breathtakingly Brief and Agile Introduction》，这本简洁的指南已被包括加州大学洛杉矶分校（UCLA）和亚利桑那州立大学（Arizona State）在内的多所大学采用。Sims 作为 Scrum Master 的实战经验，结合 Johnson 在知识产权和小说创作方面的背景，丰富了他们将复杂框架转化为易于操作的实践的方法。《The Elements of Scrum》已被翻译成中文，并作为全球学术和企业培训计划的基石教材，体现了其在敏捷项目管理领域持久的影响力。

下载《Scrum要素》摘要

免费获取《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 章节

学习计划

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 章节

学习计划

The Transformation Director's Playbook

This playbook is essential for high-achievers who want to treat their fitness journey with the same strategic precision as a professional production. It is designed for individuals looking to combine physical excellence with powerful digital storytelling to inspire others.

1 h 30 m•3 章节

由哥伦比亚大学校友创建源自旧金山

BeFreed 汇聚全球求知若渴的学习者

4.7

平均评分

7,840+ 条 App 评分

BeFreed Community

"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 的讨论

由哥伦比亚大学校友创建源自旧金山

BeFreed 汇聚全球求知若渴的学习者

4.7

平均评分

7,840+ 条 App 评分

BeFreed Community

"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 章

Scrum要素

概述《Scrum要素》概述

一本书，多种聆听方式。

Transforming Software Development: The Scrum Revolution

The Waterfall's Fatal Flaw

边听边看，每个词都清晰呈现

The Agile Rebellion

The Business Case for Agility

从 《Scrum要素》中收获更多

Scrum: The Framework That Changed Everything

The Three Pillars: Scrum Roles

边听边看，每个词都清晰呈现

The Sprint: Scrum's Heartbeat

Making Work Visible: Scrum Artifacts

从 《Scrum要素》中收获更多

User Stories: The Building Blocks of Value

Beyond Estimation: Predictable Delivery

边听边看，每个词都清晰呈现

Engineering Excellence: The Technical Practices

Beyond the Team: Organizational Agility

你已读完 《Scrum要素》

《Scrum要素》核心主题

《Scrum要素》经典语录

《Scrum要素》主要人物

关于作者

下载《Scrum要素》摘要

用户还喜欢

关于本书的常见问题

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?

发现更多

BeFreed 汇聚全球求知若渴的学习者

BeFreed 汇聚全球求知若渴的学习者

一本书，多种聆听方式。

Transforming Software Development: The Scrum Revolution

The Waterfall's Fatal Flaw

边听边看，每个词都清晰呈现

The Agile Rebellion

The Business Case for Agility

从 《Scrum要素》中收获更多

Scrum: The Framework That Changed Everything

The Three Pillars: Scrum Roles

边听边看，每个词都清晰呈现

The Sprint: Scrum's Heartbeat

Making Work Visible: Scrum Artifacts

从 《Scrum要素》中收获更多

User Stories: The Building Blocks of Value

Beyond Estimation: Predictable Delivery

边听边看，每个词都清晰呈现

Engineering Excellence: The Technical Practices

Beyond the Team: Organizational Agility

你已读完 《Scrum要素》

用户还喜欢

发现更多

《Scrum要素》概述

从《Scrum要素》中收获更多

从《Scrum要素》中收获更多

你已读完《Scrum要素》

从《Scrum要素》中收获更多

从《Scrum要素》中收获更多

你已读完《Scrum要素》