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.

Riassunto di Scrum: guida pratica per il successo di un progetto software

guida pratica per il successo di un progetto software

Chris Sims& Hillary Louise Johnson

3(1 Reviews)

Panoramica del Riassunto di Scrum: guida pratica per il successo di un progetto software

Rivoluziona la gestione dei progetti con "The Elements of Scrum", la guida adottata a livello globale e insegnata nelle università di tutto il mondo. Attraverso una narrazione coinvolgente, Sims e Johnson trasformano complessi principi agile in saggezza pratica. E se la più grande svolta nella produttività del tuo team fosse a sole 40 pagine di distanza?

Scegli come raccontarlo

Esplora il Riassunto di Scrum: guida pratica per il successo di un progetto software con diversi stili di apprendimento

Le stesse idee di Scrum: guida pratica per il successo di un progetto software. Scegli la voce, la profondità e il ritmo adatti a te. Cambia in qualsiasi momento.

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

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

Vedi ogni parola mentre la ascolti

Segui la lettura senza sforzo mentre ogni parola del Riassunto di Scrum: guida pratica per il successo di un progetto software si illumina in tempo reale.

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

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

Ottieni di più dal Riassunto di Scrum: guida pratica per il successo di un progetto software

Ricevi spunti ogni giorno da oltre 100.000 lezioni
Le parole si illuminano in sincronia con l'audio
La tua libreria salvata su ogni dispositivo

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

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

Vedi ogni parola mentre la ascolti

Segui la lettura senza sforzo mentre ogni parola del Riassunto di Scrum: guida pratica per il successo di un progetto software si illumina in tempo reale.

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

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

Ottieni di più dal Riassunto di Scrum: guida pratica per il successo di un progetto software

Ricevi spunti ogni giorno da oltre 100.000 lezioni
Le parole si illuminano in sincronia con l'audio
La tua libreria salvata su ogni dispositivo

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

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

Vedi ogni parola mentre la ascolti

Segui la lettura senza sforzo mentre ogni parola del Riassunto di Scrum: guida pratica per il successo di un progetto software si illumina in tempo reale.

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

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

★★★★★

Hai raggiunto la fine del Riassunto di Scrum: guida pratica per il successo di un progetto software

“Sono passati 23 giorni e l'ho usata ogni giorno. Ora fa parte della mia routine quotidiana.”

jayallen

Temi chiave del Riassunto di Scrum: guida pratica per il successo di un progetto software

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

Le migliori citazioni dal Riassunto di Scrum: guida pratica per il successo di un progetto software

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.

Personaggi del Riassunto di Scrum: guida pratica per il successo di un progetto software

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

Sull'autore

Chris Sims e Hillary Louise Johnson, co-autori di The Elements of Scrum, sono rinomati esperti in metodologie agile e framework Scrum. Sims, Certified Scrum Trainer e fondatore di Agile Learning Labs, apporta oltre due decenni di esperienza nel coaching di team nello sviluppo software e nella gestione dei progetti. Johnson, romanziera e giornalista economica, ha collaborato con pubblicazioni come Inc Magazine e il Los Angeles Times, fondendo chiarezza narrativa e intuizione tecnica. La loro collaborazione unisce una guida pratica a Scrum con una narrazione coinvolgente, demistificando i principi agile per i professionisti di ogni settore.

Oltre a questo bestseller internazionale, hanno scritto insieme Scrum: A Breathtakingly Brief and Agile Introduction, una guida concisa adottata da università tra cui la UCLA e l'Arizona State. L'esperienza pratica di Sims come scrum master e il background di Johnson nella proprietà intellettuale e nella narrativa arricchiscono il loro approccio nel tradurre framework complessi in pratiche accessibili. The Elements of Scrum è stato tradotto in mandarino e funge da testo fondamentale nei programmi di formazione accademica e aziendale in tutto il mondo, riflettendo il suo impatto duraturo sulla gestione dei progetti agile.

Scarica il riassunto di Scrum: guida pratica per il successo di un progetto software

Ottieni il riassunto di Scrum: guida pratica per il successo di un progetto software in formato PDF o EPUB gratuito. Stampalo o leggilo offline quando vuoi.

Agli utenti è piaciuto anche

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

Copertina del libro Scrum Story Points, Epics & Themes Explained

6 sources

Scrum Story Points, Epics & Themes Explained

Making Ideas Happen

Scott Belsky

Domande frequenti sul Riassunto di Scrum: guida pratica per il successo di un progetto software

Scopri di più

PIANO DI APPRENDIMENTO

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 Sezioni

PIANO DI APPRENDIMENTO

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 Sezioni

PIANO DI APPRENDIMENTO

Turn Dead Standups into High-Energy Huddles

Many teams struggle with repetitive, low-value meetings that drain morning energy rather than fueling it. This plan is designed for team leads and scrum masters looking to revitalize their daily rituals and drive faster delivery through better collaboration.

1 h 30 m•3 Sezioni

PIANO DI APPRENDIMENTO

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 Sezioni

PIANO DI APPRENDIMENTO

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 Sezioni

PIANO DI APPRENDIMENTO

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 Sezioni

PIANO DI APPRENDIMENTO

The Invisible Architecture of Behavior

This plan is essential for anyone struggling to break persistent cycles or build lasting routines. It is ideal for professionals and lifelong learners who want to stop relying on willpower and start using behavioral science to engineer their success.

1 h 30 m•3 Sezioni

PIANO DI APPRENDIMENTO

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 Sezioni

Creato da alumni della Columbia University | a San Francisco

BeFreed Riunisce Una Community Globale Di Menti Curiose

4.7

valutazione media

Oltre 7,84 mila valutazioni dell’app

Community BeFreed

Sul serio, non ho ancora esplorato l'app fino in fondo, ma dopo questi primi giorni sono davvero colpita… BeFreed è su un altro livello rispetto a qualsiasi altra app di apprendimento che abbia usato. Ti coinvolge tantissimo e migliora davvero la concentrazione: perfetta per chi non riesce a smettere di scrollare!

@ladyInfinity

Ho comprato BeFreed esattamente 23 giorni fa e da allora l'ho usata ogni singolo giorno. Si è integrata completamente nel mio flusso di lavoro e nelle mie abitudini di studio.

@jayallen

La verità è che l'app ha superato tutte le mie aspettative. Posso chiederle di generare audio su qualunque argomento, qualsiasi esso sia, e il risultato è impressionante. Il mio campo professionale è una specializzazione in psicoterapia, molto multidisciplinare; eppure le risposte sono molto accurate.

@Raguipa

Quello che apprezzo di più è quanto abbia ridotto il mio scrolling: passo meno tempo a cercare e più tempo ad assorbire informazioni. La combinazione di audiolibri completi, podcast e piani di apprendimento è brillante.

@colonyofcreatorsNGO

Sono istruttore di apprendimento accelerato PhotoReading da 24 anni… libri, lettura e apprendimento sono il mio pane, e BeFreed ha fatto un ottimo lavoro offrendo un approccio innovativo per trasmettere le informazioni in un modo facile da assimilare.

@BeFreed user

Non è solo un'app di riassunti di libri: ho usato l'opzione di lettura divertente ed è un riassunto molto migliore, un modo più efficace di afferrare le idee rispetto al metodo tradizionale. Solo questo vale la spesa.

@austinakon

Adoro questa app. La uso da diversi giorni e non riesco a smettere di ascoltare. Un ottimo modo per iniziare.

@jcrules328

Il programma mi piace davvero; lo sto provando da circa un mese e lo trovo una vera gemma. Funziona così bene perché con BeFreed posso creare i miei argomenti, e la voce è ottima, con una scelta illimitata di narrazioni.

@DanielCZ

Sul serio, non ho ancora esplorato l'app fino in fondo, ma dopo questi primi giorni sono davvero colpita… BeFreed è su un altro livello rispetto a qualsiasi altra app di apprendimento che abbia usato. Ti coinvolge tantissimo e migliora davvero la concentrazione: perfetta per chi non riesce a smettere di scrollare!

@ladyInfinity

Ho comprato BeFreed esattamente 23 giorni fa e da allora l'ho usata ogni singolo giorno. Si è integrata completamente nel mio flusso di lavoro e nelle mie abitudini di studio.

@jayallen

La verità è che l'app ha superato tutte le mie aspettative. Posso chiederle di generare audio su qualunque argomento, qualsiasi esso sia, e il risultato è impressionante. Il mio campo professionale è una specializzazione in psicoterapia, molto multidisciplinare; eppure le risposte sono molto accurate.

@Raguipa

Quello che apprezzo di più è quanto abbia ridotto il mio scrolling: passo meno tempo a cercare e più tempo ad assorbire informazioni. La combinazione di audiolibri completi, podcast e piani di apprendimento è brillante.

@colonyofcreatorsNGO

Sono istruttore di apprendimento accelerato PhotoReading da 24 anni… libri, lettura e apprendimento sono il mio pane, e BeFreed ha fatto un ottimo lavoro offrendo un approccio innovativo per trasmettere le informazioni in un modo facile da assimilare.

@BeFreed user

Non è solo un'app di riassunti di libri: ho usato l'opzione di lettura divertente ed è un riassunto molto migliore, un modo più efficace di afferrare le idee rispetto al metodo tradizionale. Solo questo vale la spesa.

@austinakon

Adoro questa app. La uso da diversi giorni e non riesco a smettere di ascoltare. Un ottimo modo per iniziare.

@jcrules328

Il programma mi piace davvero; lo sto provando da circa un mese e lo trovo una vera gemma. Funziona così bene perché con BeFreed posso creare i miei argomenti, e la voce è ottima, con una scelta illimitata di narrazioni.

@DanielCZ

Adoro poter ricevere informazioni e idee utili e condensate in un audio in stile podcast da 8-15 minuti. Non sono un grande fan dei podcast per via di tutto il riempitivo, ma qui si va dritti al punto.

@BeFreed user

Sto finendo il dottorato e devo leggere un sacco di materiale che non conosco… Con BeFreed basta inserire un prompt: l'app trova le fonti per te e genera un podcast audio. Trovo il processo di BeFreed più scorrevole di NotebookLM.

@Brad

Cerco spesso su YouTube qualcosa da ascoltare mentre preparo la colazione, cammino o sono in viaggio, e BeFreed offre un approccio ancora più mirato, senza pubblicità e senza riempitivi!

@BeFreed user

La cosa in assoluto migliore di questa piattaforma è la versatilità. Non c'è letteralmente nessun argomento fuori portata. Gestisce qualsiasi cosa le proponi… È raro trovare uno strumento di apprendimento senza limiti che mantenga davvero le promesse.

@jayallen

BeFreed è fantastica. Il design intuitivo mi fa passare meno tempo a navigare e più tempo a imparare. Il mix di audiolibri, podcast e piani di apprendimento è una combinazione geniale che ha cambiato completamente la mia routine quotidiana.

@BeFreed user

All'inizio mi ci è voluto un po' per capire come creare podcast in italiano e poi… boom! È fantastico! Posso chiedergli di spiegarmi qualsiasi argomento e lo fa benissimo, con grande intelligenza!

@matteo77

BeFreed è diventata la mia app quotidiana per gli audiolibri… Quello che mi piace di più è che inserisci il tuo testo e ottieni un audio da ascoltare ovunque.

@kotanzu1

Adoro poter ricevere informazioni e idee utili e condensate in un audio in stile podcast da 8-15 minuti. Non sono un grande fan dei podcast per via di tutto il riempitivo, ma qui si va dritti al punto.

@BeFreed user

Sto finendo il dottorato e devo leggere un sacco di materiale che non conosco… Con BeFreed basta inserire un prompt: l'app trova le fonti per te e genera un podcast audio. Trovo il processo di BeFreed più scorrevole di NotebookLM.

@Brad

Cerco spesso su YouTube qualcosa da ascoltare mentre preparo la colazione, cammino o sono in viaggio, e BeFreed offre un approccio ancora più mirato, senza pubblicità e senza riempitivi!

@BeFreed user

La cosa in assoluto migliore di questa piattaforma è la versatilità. Non c'è letteralmente nessun argomento fuori portata. Gestisce qualsiasi cosa le proponi… È raro trovare uno strumento di apprendimento senza limiti che mantenga davvero le promesse.

@jayallen

BeFreed è fantastica. Il design intuitivo mi fa passare meno tempo a navigare e più tempo a imparare. Il mix di audiolibri, podcast e piani di apprendimento è una combinazione geniale che ha cambiato completamente la mia routine quotidiana.

@BeFreed user

All'inizio mi ci è voluto un po' per capire come creare podcast in italiano e poi… boom! È fantastico! Posso chiedergli di spiegarmi qualsiasi argomento e lo fa benissimo, con grande intelligenza!

@matteo77

BeFreed è diventata la mia app quotidiana per gli audiolibri… Quello che mi piace di più è che inserisci il tuo testo e ottieni un audio da ascoltare ovunque.

@kotanzu1

Scopri di piu su come si parla di BeFreed nel web

Inizia il tuo percorso di apprendimento, ora

Capitolo 5

Riassunto di Scrum: guida pratica per il successo di un progetto software

Panoramica del Riassunto di Scrum: guida pratica per il successo di un progetto software

Esplora il Riassunto di Scrum: guida pratica per il successo di un progetto software con diversi stili di apprendimento

Transforming Software Development: The Scrum Revolution

The Waterfall's Fatal Flaw

Vedi ogni parola mentre la ascolti

The Agile Rebellion

The Business Case for Agility

Ottieni di più dal Riassunto di Scrum: guida pratica per il successo di un progetto software

Scrum: The Framework That Changed Everything

The Three Pillars: Scrum Roles

Vedi ogni parola mentre la ascolti

The Sprint: Scrum's Heartbeat

Making Work Visible: Scrum Artifacts

Ottieni di più dal Riassunto di Scrum: guida pratica per il successo di un progetto software

User Stories: The Building Blocks of Value

Beyond Estimation: Predictable Delivery

Vedi ogni parola mentre la ascolti

Engineering Excellence: The Technical Practices

Beyond the Team: Organizational Agility

Hai raggiunto la fine del Riassunto di Scrum: guida pratica per il successo di un progetto software

Temi chiave del Riassunto di Scrum: guida pratica per il successo di un progetto software

Le migliori citazioni dal Riassunto di Scrum: guida pratica per il successo di un progetto software

Personaggi del Riassunto di Scrum: guida pratica per il successo di un progetto software

Sull'autore

Scarica il riassunto di Scrum: guida pratica per il successo di un progetto software

Agli utenti è piaciuto anche

Domande frequenti sul Riassunto di Scrum: guida pratica per il successo di un progetto software

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?

Scopri di più

BeFreed Riunisce Una Community Globale Di Menti Curiose

Esplora il Riassunto di Scrum: guida pratica per il successo di un progetto software con diversi stili di apprendimento

Transforming Software Development: The Scrum Revolution

The Waterfall's Fatal Flaw

Vedi ogni parola mentre la ascolti

The Agile Rebellion

The Business Case for Agility

Ottieni di più dal Riassunto di Scrum: guida pratica per il successo di un progetto software

Scrum: The Framework That Changed Everything

The Three Pillars: Scrum Roles

Vedi ogni parola mentre la ascolti

The Sprint: Scrum's Heartbeat

Making Work Visible: Scrum Artifacts

Ottieni di più dal Riassunto di Scrum: guida pratica per il successo di un progetto software

User Stories: The Building Blocks of Value

Beyond Estimation: Predictable Delivery

Vedi ogni parola mentre la ascolti

Engineering Excellence: The Technical Practices

Beyond the Team: Organizational Agility

Hai raggiunto la fine del Riassunto di Scrum: guida pratica per il successo di un progetto software

Agli utenti è piaciuto anche

Scopri di più