What do you think?
Rate this book
The Elements of Scrum
The Elements of Scrum has gained an international following and a reputation for being perhaps the only book on software development that reads like a page-turner. Written by Chris Sims, a top scrum trainer and pioneer of experiential learning, and Hillary Louise Johnson, a novelist and business journalist, it demonstrates the principles, practices and pitfalls of the scrum framework through lively storytelling and vividly told example.
The Elements of Scrum opens with a blow-by-blow description of a week in the life of a scrum team, then briefly details the history and origins of scrum, comparing it to traditional methodologies and providing context for how scrum applies to the cultural history of the software industry. Next, the principles and practices set forth in the Agile Manifesto are broken down and illustrated with real-world examples, putting the reader inside the heads of the founders of scrum and agile for a thorough grounding in theory.
The meat of the book explains every aspect of the scrum process, including team composition, scheduling and work flow management, in crisp, clear, example-laden prose designed to provide insight to novices and experienced practitioners alike.
The book concludes with a section on supporting technical practices like Test Driven Development and Pair Programming, to help the reader apply scrum at the practical level.
The Elements of Scrum is taught at colleges and universities across the country, including UCLA, George Mason University, Arizona State, SUNY Potsdam, Wofford College, and Becker College. It has been translated into Mandarin, and is soon to appear in other international editions.
The Elements of Scrum opens with a blow-by-blow description of a week in the life of a scrum team, then briefly details the history and origins of scrum, comparing it to traditional methodologies and providing context for how scrum applies to the cultural history of the software industry. Next, the principles and practices set forth in the Agile Manifesto are broken down and illustrated with real-world examples, putting the reader inside the heads of the founders of scrum and agile for a thorough grounding in theory.
The meat of the book explains every aspect of the scrum process, including team composition, scheduling and work flow management, in crisp, clear, example-laden prose designed to provide insight to novices and experienced practitioners alike.
The book concludes with a section on supporting technical practices like Test Driven Development and Pair Programming, to help the reader apply scrum at the practical level.
The Elements of Scrum is taught at colleges and universities across the country, including UCLA, George Mason University, Arizona State, SUNY Potsdam, Wofford College, and Becker College. It has been translated into Mandarin, and is soon to appear in other international editions.
184 pages, Paperback
First published January 1, 2011
185 people are currently reading
636 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 73 reviews
August 23, 2016
Excellent reference and starting point for anyone that wants to learn Agile Project Management.
September 19, 2017
The best practical introduction to the mechanics — roles, ceremonies, and artifacts, of Scrum. A must-have addition to the original Scrum book by Jeff Sutherland, if you're a rookie to the framework.
June 14, 2019
Well written book that clearly explains SCRUM and Agile principles. Useful for anyone who needs an overview without going too deep.
Read
November 18, 2022Get agile and flexible, and learn how scrum will help you work better.
Do you think you have the best method for organizing a project? It’s a classic mistake, especially in software development. Each team has its own preferences and conceits: the designers want it one way, the coders another – and in the chaos, the client is left out in the cold.
The bottom line is that there is no set procedure, no perfect path from A to Z in developing great software products. But there are a couple of tricks that will get you as close to perfection as possible.
Today’s teams have to be flexible and agile, ready to bend with the whims and challenges that come their way. You have to make a plan then toss it aside, building another on the fly while keeping your eye on the ultimate goal.
How do you do this? Ditch those old waterfall methods and embrace scrum – an agile, flexible system that will change the way you think and revolutionize your development process.
---
The traditional methods of software development are inefficient and lead to cost overruns.
Tradition may have its charm, but it has few fans when it comes to technology development. Technology needs to be constantly updated to remain relevant; in fact, being current is essential not only to technology but also to the processes used to create it.
One system of development is called the waterfall method, which is a finish-to-start process for producing software. In such a system, a software team would typically compile requirements, make a design, write code, test and then deliver a finished product.
The “finish-to-start” aspect of the process is crucial. Activity A must be completed before work on activity B can start. For instance, you can’t begin testing a design until you’ve finished coding.
Why do people and organizations like this method?
By separating each development step, scheduling and planning is made easier. Managers often prefer a waterfall approach as they believe it allows them greater accuracy in scheduling and allocating budgets.
But the waterfall method isn’t very reliable. Software is often too complicated a product to be fully designed before production starts. Therefore, if you demand a perfectly designed product, you’ll be left with little wiggle room for change during production.
So while it’s possible for a perfect design to seamlessly transition to a perfect production process, this usually only occurs when you’re producing a static object, like a car. In this example, you’d design every element in the car, then follow those design directions to the letter during manufacturing.
But software production, in contrast, is just too complex.
So, while designers may come up with what they think is a perfect product, complications are sure to arise when designs are applied. The numbers tell the tale: only 16 percent of waterfall-method projects meet completion deadlines, while 31 percent are cancelled and 53 percent go over budget!
How do you avoid such a pitfall in your own projects? Read on to learn more.
---
An agile process has the same components as a waterfall process, but gives you more flexibility.
In the fast-paced and often unpredictable technology market, you need to be flexible to adapt your development process quickly. This means preventing one project element from holding up another.
But how can you keep the development train running?
You choose an agile process – a development strategy that embraces change as an opportunity for growth.
Agile teams work largely in the same fashion as do those using a waterfall process: they gather requirements, make designs, write code, test and deliver a product. The thing that they don’t do is to wait for each step to be completely finished before starting on the next.
Instead, agile teams work on each step a little bit at a time, delivering pieces of a product to the client. The team repeats this process, over and over, until the product is complete. This cycle is called iteration.
Let’s think about a photo-editing software development team. Using an agile process, the team might first finish a feature that changes a color photo to black and white. The team would send this small feature to the client, who would offer feedback. The team then could work toward improving the feature based on the feedback in the next iteration.
But don’t think that agile processes are just “mini” waterfalls; they’re fully integrated processes. This means that agile teams treat each project like a complete unit and not as separate parts, as do teams working with a finish-to-start process.
Thus an agile team ensures that its designers and coders think of their contributions as complementing one another – instead of thinking only of “their part” and ignoring the rest.
There’s another crucial difference between waterfall and agile processes. In a waterfall process, a client offers his software requirements when the project begins, and isn’t consulted again until the product is delivered. Yet with an agile process, a team constantly interfaces with the client during the process, allowing requirements to be tweaked or changed throughout.
---
The four core values of agility pave the way to a streamlined, efficient and successful process.
You’re driving along your usual route to work when you see that an accident is blocking the intersection ahead. What do you do? Would you wait for the accident to clear, or turn down an unfamiliar road to explore a way around?
If you said turn and explore, you’ve already got one of the four key values of agility. Each value represents a priority, or a choice between different approaches.
The first value of agility is to prioritize individuals and interactions over processes and tools. This means that the people involved in a project are more important than the process guiding the project.
Basically, tools and processes should serve people, not the other way around.
The second value is to prioritize functional software over in-depth documentation. Sure, documentation is important, but it shouldn’t supercede the product itself. So if you’re pressed for time, focus your energies on turning out a great product and don’t sweat taking dozens of documentary photos.
The third value is to prioritize customer collaboration over contract negotiation. It’s essential for the contractual agreement between a development team and a client to remain open. Only in doing so can you be sure of producing and delivering what the customer is really after.
Agile teams hold regular meetings and maintain open communication at every iteration. While contracts are important, they don’t ensure that a client’s standards of quality will be adhered to – but open, fluid communication will.
And finally, the fourth value prioritizes responding to change over sticking to a plan. A plan shows that you know where you want to go and how to get there; but if there’s a sudden change (like that traffic accident), you’ll need to be both flexible and agile to adapt and reach your goals in stride.
When you hold true to the four values of agility, you’ll be able to set project priorities both adaptive and efficient.
---
Scrum is a system that embodies agility through a focused development process.
Now that you know the agile values, you’ll need a system in which to implement them ‒ and that’s where scrum will help you.
But what exactly is a “scrum?”
A scrum is a software development process that applies the four values of agility to build new products through a series of sprints – with each series containing every step of the development process, from researching requirements to delivering the product to the client.
Within each sprint you only tackle a small piece of your larger project, which can mean that a sprint period can run from as short as a week to as long as a month.
So how do you start a sprint?
Each sprint comes alive at a sprint planning meeting, which is composed of two parts: the first determines what the sprint’s deliverables are, and the second figures out how to achieve them.
First discover what your team needs to deliver at the end of the sprint. This part is led by a product owner, the team member who decides what to build and when, based on the wishes of your client.
In our photo-editing software example, the product owner might say that the team will do a sprint on the product’s black and white feature this week, then focus on another feature the next week.
The product owner is also responsible for presenting an ideal user experience, called a story (you’ll learn more about this).
Once the first part is agreed upon, the second part of the sprint planning meeting is devoted to deciding how the team will reach its goals.
To do this, the team sets certain tasks, such as conducting user interviews or testing. It’s important that no task takes longer than half a day, so big tasks should be split into many smaller ones.
---
Sprints revolve around the experience and stories of your users.
A crucial aspect of every sprint planning meeting is coming up with a great user experience. But how do scrums incorporate this element in the process? Through user stories.
Stories are a simple way to show how people actually use a product. They’re called user stories to ensure a team keeps its attention on the end customer and not the product owner, designer or coder.
Every user story has three components: who is the target user, what is the user requirement and why the user requirement is necessary.
Here’s an example story template: As a (type of user), I want to (do something) so that (some value) is created. Filling in the blanks, a team might come up with: As a user of a smartphone with a camera, I want the photos I take to be automatically edited by the phone software to save me time.
To plan a successful sprint, a team has to estimate how complicated – or how “big” – a user story is. The bigger the story is, the more development time is needed. For example, tracking a user’s entire purchasing process is a big story, requiring a month-long sprint, while developing new headers is a small one, needing a week.
So how do you figure out the size of a user story?
One way is to focus on the story’s relative size – that is, how “big” it is in relation to other stories in your project. A story is, after all, an abstract concept; there’s no way to measure exactly how “big” it is.
So take a look at your projects and compare user stories. Find what you think would be the “smallest” story, and then measure the other stories against the smallest one.
You can even come up with a special numbering system as a reference tool for your team, to quickly identify big stories from smaller ones. For example, if a sprint to redesign headers is the smallest on your list of projects, you could measure the purchasing process sprint as “four header redesigns.”
---
Incorporate the three types of scrum meetings to ensure the responsiveness and agility of the sprint.
So your team just launched a new project, and everyone says they’re clear on scope and expectations and is hard at work. A month passes, and you gather to share notes – and then the trouble starts.
Three teammates have finished their tasks, two are stuck mulling a problem and can’t finish and one guy took it upon himself to change his task in a way that messes up everyone else’s work.
Does this sound familiar?
The scrum method uses three types of meetings to avoid this sort of situation.
First, a daily scrum identifies changes as they occur in “real-time.” It’s a very short, daily meeting designed to keep your team on track by identifying obstacles so you can address them straight away.
A daily scrum should be held at the same time every day – for 15 minutes maximum – and only team members should be present.
In the meeting, each team member shares what they accomplished the previous day, what they’ll tackle today and any roadblocks that might be slowing progress.
Another type of meeting is the sprint review, held at the end of each sprint for clients to offer feedback. Here your team can show its work to the client; be sure that the product owner and other team members take note of the client’s reactions.
The client’s response lets the product owner adjust the product backlog – a list of to-do items that are ranked according to priority.
The last type is called the retrospective meeting. Here you and your team can look back on the finished sprint and discuss what everyone has learned. This meeting should be held after the sprint review, on the same day that the sprint is completed.
During this meeting, your team should also reflect on how to apply new knowledge to the next sprint. For instance, the team might find that it’s necessary to change the testing process to make it more efficient.
---
Traditional methods for managing software development are ineffective and inflexible. Instead of defining a project, getting to work and not stopping until you’re finished, it’s essential to bring your customers into the process early on and seek advice frequently. To produce the customer satisfaction you want, you need a process with the agility and flexibility to adapt to any change. That process is scrum!
Actionable advice:
Put the project first.
Developing software is about building a system that solves a problem; and solving a problem is all about teamwork. That’s because no software project is ever completed by a lone individual, no matter how central his role. Rather, development processes rely on teamwork to find solutions and overcome roadblocks. In other words, put the project first, not your ego.
Do you think you have the best method for organizing a project? It’s a classic mistake, especially in software development. Each team has its own preferences and conceits: the designers want it one way, the coders another – and in the chaos, the client is left out in the cold.
The bottom line is that there is no set procedure, no perfect path from A to Z in developing great software products. But there are a couple of tricks that will get you as close to perfection as possible.
Today’s teams have to be flexible and agile, ready to bend with the whims and challenges that come their way. You have to make a plan then toss it aside, building another on the fly while keeping your eye on the ultimate goal.
How do you do this? Ditch those old waterfall methods and embrace scrum – an agile, flexible system that will change the way you think and revolutionize your development process.
---
The traditional methods of software development are inefficient and lead to cost overruns.
Tradition may have its charm, but it has few fans when it comes to technology development. Technology needs to be constantly updated to remain relevant; in fact, being current is essential not only to technology but also to the processes used to create it.
One system of development is called the waterfall method, which is a finish-to-start process for producing software. In such a system, a software team would typically compile requirements, make a design, write code, test and then deliver a finished product.
The “finish-to-start” aspect of the process is crucial. Activity A must be completed before work on activity B can start. For instance, you can’t begin testing a design until you’ve finished coding.
Why do people and organizations like this method?
By separating each development step, scheduling and planning is made easier. Managers often prefer a waterfall approach as they believe it allows them greater accuracy in scheduling and allocating budgets.
But the waterfall method isn’t very reliable. Software is often too complicated a product to be fully designed before production starts. Therefore, if you demand a perfectly designed product, you’ll be left with little wiggle room for change during production.
So while it’s possible for a perfect design to seamlessly transition to a perfect production process, this usually only occurs when you’re producing a static object, like a car. In this example, you’d design every element in the car, then follow those design directions to the letter during manufacturing.
But software production, in contrast, is just too complex.
So, while designers may come up with what they think is a perfect product, complications are sure to arise when designs are applied. The numbers tell the tale: only 16 percent of waterfall-method projects meet completion deadlines, while 31 percent are cancelled and 53 percent go over budget!
How do you avoid such a pitfall in your own projects? Read on to learn more.
---
An agile process has the same components as a waterfall process, but gives you more flexibility.
In the fast-paced and often unpredictable technology market, you need to be flexible to adapt your development process quickly. This means preventing one project element from holding up another.
But how can you keep the development train running?
You choose an agile process – a development strategy that embraces change as an opportunity for growth.
Agile teams work largely in the same fashion as do those using a waterfall process: they gather requirements, make designs, write code, test and deliver a product. The thing that they don’t do is to wait for each step to be completely finished before starting on the next.
Instead, agile teams work on each step a little bit at a time, delivering pieces of a product to the client. The team repeats this process, over and over, until the product is complete. This cycle is called iteration.
Let’s think about a photo-editing software development team. Using an agile process, the team might first finish a feature that changes a color photo to black and white. The team would send this small feature to the client, who would offer feedback. The team then could work toward improving the feature based on the feedback in the next iteration.
But don’t think that agile processes are just “mini” waterfalls; they’re fully integrated processes. This means that agile teams treat each project like a complete unit and not as separate parts, as do teams working with a finish-to-start process.
Thus an agile team ensures that its designers and coders think of their contributions as complementing one another – instead of thinking only of “their part” and ignoring the rest.
There’s another crucial difference between waterfall and agile processes. In a waterfall process, a client offers his software requirements when the project begins, and isn’t consulted again until the product is delivered. Yet with an agile process, a team constantly interfaces with the client during the process, allowing requirements to be tweaked or changed throughout.
---
The four core values of agility pave the way to a streamlined, efficient and successful process.
You’re driving along your usual route to work when you see that an accident is blocking the intersection ahead. What do you do? Would you wait for the accident to clear, or turn down an unfamiliar road to explore a way around?
If you said turn and explore, you’ve already got one of the four key values of agility. Each value represents a priority, or a choice between different approaches.
The first value of agility is to prioritize individuals and interactions over processes and tools. This means that the people involved in a project are more important than the process guiding the project.
Basically, tools and processes should serve people, not the other way around.
The second value is to prioritize functional software over in-depth documentation. Sure, documentation is important, but it shouldn’t supercede the product itself. So if you’re pressed for time, focus your energies on turning out a great product and don’t sweat taking dozens of documentary photos.
The third value is to prioritize customer collaboration over contract negotiation. It’s essential for the contractual agreement between a development team and a client to remain open. Only in doing so can you be sure of producing and delivering what the customer is really after.
Agile teams hold regular meetings and maintain open communication at every iteration. While contracts are important, they don’t ensure that a client’s standards of quality will be adhered to – but open, fluid communication will.
And finally, the fourth value prioritizes responding to change over sticking to a plan. A plan shows that you know where you want to go and how to get there; but if there’s a sudden change (like that traffic accident), you’ll need to be both flexible and agile to adapt and reach your goals in stride.
When you hold true to the four values of agility, you’ll be able to set project priorities both adaptive and efficient.
---
Scrum is a system that embodies agility through a focused development process.
Now that you know the agile values, you’ll need a system in which to implement them ‒ and that’s where scrum will help you.
But what exactly is a “scrum?”
A scrum is a software development process that applies the four values of agility to build new products through a series of sprints – with each series containing every step of the development process, from researching requirements to delivering the product to the client.
Within each sprint you only tackle a small piece of your larger project, which can mean that a sprint period can run from as short as a week to as long as a month.
So how do you start a sprint?
Each sprint comes alive at a sprint planning meeting, which is composed of two parts: the first determines what the sprint’s deliverables are, and the second figures out how to achieve them.
First discover what your team needs to deliver at the end of the sprint. This part is led by a product owner, the team member who decides what to build and when, based on the wishes of your client.
In our photo-editing software example, the product owner might say that the team will do a sprint on the product’s black and white feature this week, then focus on another feature the next week.
The product owner is also responsible for presenting an ideal user experience, called a story (you’ll learn more about this).
Once the first part is agreed upon, the second part of the sprint planning meeting is devoted to deciding how the team will reach its goals.
To do this, the team sets certain tasks, such as conducting user interviews or testing. It’s important that no task takes longer than half a day, so big tasks should be split into many smaller ones.
---
Sprints revolve around the experience and stories of your users.
A crucial aspect of every sprint planning meeting is coming up with a great user experience. But how do scrums incorporate this element in the process? Through user stories.
Stories are a simple way to show how people actually use a product. They’re called user stories to ensure a team keeps its attention on the end customer and not the product owner, designer or coder.
Every user story has three components: who is the target user, what is the user requirement and why the user requirement is necessary.
Here’s an example story template: As a (type of user), I want to (do something) so that (some value) is created. Filling in the blanks, a team might come up with: As a user of a smartphone with a camera, I want the photos I take to be automatically edited by the phone software to save me time.
To plan a successful sprint, a team has to estimate how complicated – or how “big” – a user story is. The bigger the story is, the more development time is needed. For example, tracking a user’s entire purchasing process is a big story, requiring a month-long sprint, while developing new headers is a small one, needing a week.
So how do you figure out the size of a user story?
One way is to focus on the story’s relative size – that is, how “big” it is in relation to other stories in your project. A story is, after all, an abstract concept; there’s no way to measure exactly how “big” it is.
So take a look at your projects and compare user stories. Find what you think would be the “smallest” story, and then measure the other stories against the smallest one.
You can even come up with a special numbering system as a reference tool for your team, to quickly identify big stories from smaller ones. For example, if a sprint to redesign headers is the smallest on your list of projects, you could measure the purchasing process sprint as “four header redesigns.”
---
Incorporate the three types of scrum meetings to ensure the responsiveness and agility of the sprint.
So your team just launched a new project, and everyone says they’re clear on scope and expectations and is hard at work. A month passes, and you gather to share notes – and then the trouble starts.
Three teammates have finished their tasks, two are stuck mulling a problem and can’t finish and one guy took it upon himself to change his task in a way that messes up everyone else’s work.
Does this sound familiar?
The scrum method uses three types of meetings to avoid this sort of situation.
First, a daily scrum identifies changes as they occur in “real-time.” It’s a very short, daily meeting designed to keep your team on track by identifying obstacles so you can address them straight away.
A daily scrum should be held at the same time every day – for 15 minutes maximum – and only team members should be present.
In the meeting, each team member shares what they accomplished the previous day, what they’ll tackle today and any roadblocks that might be slowing progress.
Another type of meeting is the sprint review, held at the end of each sprint for clients to offer feedback. Here your team can show its work to the client; be sure that the product owner and other team members take note of the client’s reactions.
The client’s response lets the product owner adjust the product backlog – a list of to-do items that are ranked according to priority.
The last type is called the retrospective meeting. Here you and your team can look back on the finished sprint and discuss what everyone has learned. This meeting should be held after the sprint review, on the same day that the sprint is completed.
During this meeting, your team should also reflect on how to apply new knowledge to the next sprint. For instance, the team might find that it’s necessary to change the testing process to make it more efficient.
---
Traditional methods for managing software development are ineffective and inflexible. Instead of defining a project, getting to work and not stopping until you’re finished, it’s essential to bring your customers into the process early on and seek advice frequently. To produce the customer satisfaction you want, you need a process with the agility and flexibility to adapt to any change. That process is scrum!
Actionable advice:
Put the project first.
Developing software is about building a system that solves a problem; and solving a problem is all about teamwork. That’s because no software project is ever completed by a lone individual, no matter how central his role. Rather, development processes rely on teamwork to find solutions and overcome roadblocks. In other words, put the project first, not your ego.
August 8, 2013
The best Scrum guide available. But sorry, no Scrum guide deserves 5 stars. I save those for the books I fall in love with :) Still, if you are looking to get started with Scrum this book is a must-have. It offers a very clear description of the process, roles, artifacts and ceremonies, combined with stories and words of wisdom. If you teach or coach Scrum, I recommend you have copies of this book to give to your students. As well as being useful it is elegantly written—something that cannot be said for most of the Scrum and Agile books available, many of which are simply tedious.
February 5, 2017
Primarily a method for managing coding projects. I found a lot of ideas that I think will apply quite well to various kinds of library projects. Basically if you have a definable end product for your project I think scrum can help to improve your process.
December 20, 2017
I got this book after reading the abridged version by the same authors. Like the abridged version this book is well written and the concepts well explained. The book opens with a good comparison of "waterfall" vs "agile" development. Following this is a very enjoyable exposition of the agile values and principles (individuals and interactions over processes and tools etc etc). Following this is the core part of the book: explanations of the roles (product owner, scrum master, team member), ceremonies (sprint planning, daily standup, sprint review, sprint retrospective, backlog grooming, story time) and artifacts (product backlog, sprint backlog, burn charts, task board, definition of done) that make up scrum. Within the core part of the book is a good explanation of what user stories are and how they help with understanding what needs to be built, for who and, importantly, why. And closing out the core part of the book is a discussion on some tried and tested strategies for estimating stories.
I've not read any other books on scrum so I can't compare but I'd be very very amazed to find a better one out there than this one. This book covered absolutely lots of ground whilst remaining compact and, most importantly, very readable.
I've not read any other books on scrum so I can't compare but I'd be very very amazed to find a better one out there than this one. This book covered absolutely lots of ground whilst remaining compact and, most importantly, very readable.
August 2, 2017
I think scrum is a culture more than a process. Contrary to the book, which kinda says its a principle (which makes it apples to oranges when your comparing a process to a principle), I believe you cannot apply Scrum on a company with a strict authoritarian hierarchy, poor communication (very political and need to save face), cannot accept risks and limitations (have never heard of an FMEA and do a lot of ass-covering work), and is not about the problem solving instead focusing on misdirection.
That said, scrum (after reading this book) is a great criteria at looking at Company or Organizational Culture. While the book says waterfall is terrible and uses a strawman to do it, a culture that meets the Scrum criteria will operate Waterfall method very AGILE like. While a culture that fails in Scrum will implode when attempting scrum. I say this after finishing Kim Heldmans PMP study guide book, while Project Management is very Waterfall-like it has elements in place that allow it to survive many different Cultures (including terrible ones) while Scrum or Agile is the Ideal few of us really have the chance to experience.
That said, scrum (after reading this book) is a great criteria at looking at Company or Organizational Culture. While the book says waterfall is terrible and uses a strawman to do it, a culture that meets the Scrum criteria will operate Waterfall method very AGILE like. While a culture that fails in Scrum will implode when attempting scrum. I say this after finishing Kim Heldmans PMP study guide book, while Project Management is very Waterfall-like it has elements in place that allow it to survive many different Cultures (including terrible ones) while Scrum or Agile is the Ideal few of us really have the chance to experience.
April 14, 2023
This book provides a clear and concise introduction to Scrum, an agile framework for managing complex projects. The author does an excellent job of explaining the core principles and practices of Scrum, and provides plenty of real-world examples to illustrate how it can be applied in practice.
While it's true that "The Elements of Scrum" doesn't go into as much detail as some other Scrum books, such as Jeff Sutherland's "Scrum", it still provides a solid foundation for anyone new to the methodology.
One thing that I appreciated about the book is that it's very practical and actionable. The author provides clear guidance on how to set up a Scrum team, plan and execute sprints, and continuously improve your Scrum processes.
Overall, while "The Elements of Scrum" may not be the most comprehensive or in-depth Scrum book out there, it's still a valuable resource for anyone looking to learn the basics of this agile framework. I would recommend it to anyone new to Scrum, or to those who are looking for a quick refresher.
While it's true that "The Elements of Scrum" doesn't go into as much detail as some other Scrum books, such as Jeff Sutherland's "Scrum", it still provides a solid foundation for anyone new to the methodology.
One thing that I appreciated about the book is that it's very practical and actionable. The author provides clear guidance on how to set up a Scrum team, plan and execute sprints, and continuously improve your Scrum processes.
Overall, while "The Elements of Scrum" may not be the most comprehensive or in-depth Scrum book out there, it's still a valuable resource for anyone looking to learn the basics of this agile framework. I would recommend it to anyone new to Scrum, or to those who are looking for a quick refresher.
February 8, 2019
Probably more like 3.5 Stars.
It was nice to see all the things I've gleaned from the Scrum process from trainings and hands-on experience expanded upon in one concise book, however it seemed to end abruptly. The last chapter was talked about a scrum-like practice that could be employed without any conclusion chapter. Or if the 'conclusion' came before the last chapter, it was misplaced.
It would have been nice to have more information on how scrum could be applied to non-software projects, although that may have been decidedly outside the scope of this book.
It was nice to see all the things I've gleaned from the Scrum process from trainings and hands-on experience expanded upon in one concise book, however it seemed to end abruptly. The last chapter was talked about a scrum-like practice that could be employed without any conclusion chapter. Or if the 'conclusion' came before the last chapter, it was misplaced.
It would have been nice to have more information on how scrum could be applied to non-software projects, although that may have been decidedly outside the scope of this book.
December 21, 2017
Short and to-the-Point
This book definitely gets right to the definitions of every aspect of Scrum. I would have liked to see a little more real-world examples. One example being, “How does one manage defects that come up mid-sprint?” Do they go into the backlog or do they need to be done that sprint? Can they go into the backlog if they are critical and you are at the last sprint before the release?
This book definitely gets right to the definitions of every aspect of Scrum. I would have liked to see a little more real-world examples. One example being, “How does one manage defects that come up mid-sprint?” Do they go into the backlog or do they need to be done that sprint? Can they go into the backlog if they are critical and you are at the last sprint before the release?
March 24, 2018
Just enough and not too much
I read this after the mini version by the same authors as I wanted to explore some areas in more depth but am under pressure as we’ve already started our project and new way of working.
The book gave me an incredible amount of practical tips and processes that I can start using tomorrow, so great on that front.
Well written with a light tone, this has given me what I need today but also a useful resource to revisit tomorrow.
I read this after the mini version by the same authors as I wanted to explore some areas in more depth but am under pressure as we’ve already started our project and new way of working.
The book gave me an incredible amount of practical tips and processes that I can start using tomorrow, so great on that front.
Well written with a light tone, this has given me what I need today but also a useful resource to revisit tomorrow.
January 29, 2019
Los métodos tradicionales para gestionar el desarrollo de software son ineficaces e inflexibles. En lugar de definir un proyecto, comenzar a trabajar y no detenerse hasta que haya terminado, es esencial que sus clientes participen en el proceso desde el principio y que busquen consejos con frecuencia. Para producir la satisfacción del cliente que desea, necesita un proceso con la agilidad y flexibilidad para adaptarse a cualquier cambio. ¡Ese proceso es scrum!
July 26, 2023
Intro to scrum for adaptiveness and efficiency .
Sprint plan: 1) user story (who, what and why) 2) indentify: deliverable and tasks), 3) Agile 4 priority choices: invidual>tool, functional > documentation , collaboration>negotiation, change >plan. Agile> waterfall method with iteration (step by step implementation in full unit but integrated) which allows earlier tweaks before full completion though backlog and retrospective meeting after every sprint.
Sprint plan: 1) user story (who, what and why) 2) indentify: deliverable and tasks), 3) Agile 4 priority choices: invidual>tool, functional > documentation , collaboration>negotiation, change >plan. Agile> waterfall method with iteration (step by step implementation in full unit but integrated) which allows earlier tweaks before full completion though backlog and retrospective meeting after every sprint.
This entire review has been hidden because of spoilers.
November 30, 2016
This is a super short book that describes a new-ish type of project management. The definitions are great if you're trying to find the words to describe what business structure is required for agile software management. Likely you're already doing parts of this, but how nice it always is to have someone just give you the words that help you even better understand why it works.
January 13, 2018
The book to evanvelize scrum with
I use to recommend the pocket book by varheyen to anyone starting out with scum but recently got briefed to go through this book at a project orientation. Sims book is very well written, very easy to read, quick and focuses on the crux of scrum and related tool sets.
I use to recommend the pocket book by varheyen to anyone starting out with scum but recently got briefed to go through this book at a project orientation. Sims book is very well written, very easy to read, quick and focuses on the crux of scrum and related tool sets.
August 21, 2019
The most clear and easy to read description of Agile and Scrum principles. The book walks through why waterfall is a bad method and then follows the story of a team through a project they are running with Scrum. Scrum is useful not only for developers, but project with moving piece (so pretty much everything!). I recommend business owners read this book as well!
March 15, 2020
An easy to read introduction to Scrum that was both helpful and humorous. I just became the Scrum Master at my organization so I picked this up to learn a bit more about how to improve the day to day functioning of my team. I read over a few days and learned a lot. I'm looking forward to implementing some new things over the next few sprints!
March 16, 2018
Weird jokes aside (architecture is like a...bra?), this is a concise, explanatory guide for anyone new to agile development. For someone with a few years' experience, there may not be anything new here.
June 16, 2019
Insightful
I've been doing scrum for a while but this book with it's storytelling, amazing examples and great options for the application of the same principle provides a perspective that few books on this subject have been able to deliver
I've been doing scrum for a while but this book with it's storytelling, amazing examples and great options for the application of the same principle provides a perspective that few books on this subject have been able to deliver
September 19, 2019
I read this after reading their smaller book: Scrum: A Breathtakingly Brief and Agile Introduction. I found the first book a very helpful introduction to get your feet wet and this book a wonderful follow-up to get into the details.
March 23, 2020
This book gives a quick overview about agile and scrum and also gives directions as to where to go after reading it. If you use agile in your projects you will be able to better connect with the book and improve the development process in your team.
December 14, 2017
Elements of Scrum is a great book for a beginner. It is very easy to read and understand. Use cases is something I would loved to see in the book. I recommend this book for any beginner.
December 11, 2017
A simple, no fuss introduction to scrum.
January 4, 2018
Wonderful book to assist with managing application development projects.
February 17, 2018
Clear overview of process with lots of tips and tricks.
July 1, 2018
This book contains the right amount of detail. It's a good place to start and, most likely, finish with Scrum. You'll have about all the info you need to be proficient in less than 200 pages.
September 3, 2018
Loved it
Very simple and funny way to learn about how to use Agile and Scrum with your teams. Entertaining and very helpful!
Very simple and funny way to learn about how to use Agile and Scrum with your teams. Entertaining and very helpful!
February 12, 2019
Good book with a practical approach on the topic
September 26, 2019
Really a good starter for understanding Scrum. Usecases and examples used throughout the book are helping lot to understand the concepts.
Displaying 1 - 30 of 73 reviews