What do you think?
Rate this book
Scrum für Dummies
Das Sch?ne an Scrum ist, dass das Regelwerk so ?berschaubar ist. Es schafft nur so viel Struktur, dass Teams sich ganz und gar auf die L?sung der eigentlichen Herausforderung konzentrieren k?nnen und keine Zeit mit der Abarbeitung unn?tiger und bereits ?berholter Prozesse verlieren. Das Buch zeigt Ihnen, wie Sie ein Team zusammenstellen und diese beliebte agile Projektmanagementmethode implementieren, um Projekte reibungsloser zu gestalten, und zwar vom Anfang bis zum Ende. Wenn Sie m?chten, auch in Ihrem Privatleben. Scrum wird Ihnen das Leben leichter machen. Warum probieren Sie es nicht einfach aus?
408 pages, Kindle Edition
First published November 24, 2014
88 people are currently reading
147 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 - 16 of 16 reviews
September 9, 2020
+ Informative
+ free (work gave it to me)
+ A good way of working, which suits me at least partially
- too much repetition, not enough juicy/funny examples
- not fun to read
- no dragons
+ free (work gave it to me)
+ A good way of working, which suits me at least partially
- too much repetition, not enough juicy/funny examples
- not fun to read
- no dragons
April 20, 2021
solid introduction / refresher
May 6, 2025
I signed on as a consultant and ended up managing the project. Wanted to see if scrum would help us run things better and get more done.
I normally will not read any “for dummies” book on principle. I am not a dummy. But in this case, I told myself it was like reading the children’s book when you just want to get up to speed fast, in the simplest terms.
The book was fine. You don’t need to be dumb to appreciate it. In fact (and I don’t mean this as an insult at all), whenever I needed to sleep, this book knocked me right out. Even though I was very interested, I just couldn’t stay awake. If I had trouble sleeping, I’d buy a copy just for that.
One takeaway that’s proved useful in my life: don’t schedule your standup meeting for first thing in the morning. Give your people time to check their email and get a cup of coffee first. For part of the time when I read this book, I was being extremely disciplined about not doing anything else before I did my yoga, Tony Robbins’s priming exercise, and two hours of focused work in MY business. (I had been letting client work take over my life and take up all my time. This was the antidote.) That’s a lot of discipline, and it was really hard. But if I let myself do a little brain dump and check in on my Trello board (in other words, let myself get settled and clear out my brain a bit) before starting the focused work, I felt a lot better.
To summarize: scrum is an agile process. There’s the project owner, who determines what needs to be done when, based on stakeholder requirements and which features will make the most impact; the scrum master, who manages the project and protects the development team from as much bullshit as possible; and the developers. Everyone is equal, and everyone is full-time on this project.
You create the vision for the product so you know what you’re building toward. Then you create the product roadmap—what features will make the vision a reality? Then you plan the releases, with the most important features first. Then you do the work in a series of sprints, which could be one day, one week, two weeks, but probably not longer than that. The authors recommend one week. For each sprint, you plan the sprint (what are we building this sprint?), have the daily scrum to find out what everybody needs to move forward. At the end of the sprint, you make sure the product works with the new stuff you just built, and you do a retrospective to learn from this sprint so you can do better next time.
For software, the power of this model is you’re always building the most important things, and you’re always testing and releasing, so you get feedback as you go.
Tools to help:
- Task board with 4 columns: to do, in progress, accept, done. Move sticky notes or Trello cards through the pipeline as you do their tasks. (Accept is for tasks that are waiting for acceptance from the product owner.)
- Burndown chart: line graph showing how many hours of work should remain over time as the sprint goes on
Questions for the retrospective:
“- What do you think went well?
- What would you like to change?
- How should we implement that change?”
What do you do if you’re planning the sprint and there’s too much work for the team’s capacity? (P. 102) “Do they hunker down and work overtime? No, the product owner has a decision to make: which sprint backlog items will be moved back to the product backlog to get the number of hours below the development team’s capacity. Sustained overtime leads to poor team morale, poorer quality, and long-term productivity losses.”
After explaining the fundamentals, the book goes on to show how scrum could apply to different industries. I could see where it makes sense for a lot of different applications where you’re building something, including an e-course or a launch. I have a harder time seeing how it applies to something that’s just ongoing, like customer service. And when they tried to apply it to dating, that just felt like a big nerdy reach. Interesting to think about, though.
For my own projects, I already have a weekly cadence, so I’d probably stick with that. For just one or two people, it seems like too much to have all the structure of scrum. (Daily meetings, plus a retrospective every week? That seems like way too much.) But I do like planning what to build each week. It will be different for sure to actually keep that to only an amount that’s possible to do! That could be a real life-changer. And I like the idea of a retrospective after each phase of a project. I’l probably do that.
I normally will not read any “for dummies” book on principle. I am not a dummy. But in this case, I told myself it was like reading the children’s book when you just want to get up to speed fast, in the simplest terms.
The book was fine. You don’t need to be dumb to appreciate it. In fact (and I don’t mean this as an insult at all), whenever I needed to sleep, this book knocked me right out. Even though I was very interested, I just couldn’t stay awake. If I had trouble sleeping, I’d buy a copy just for that.
One takeaway that’s proved useful in my life: don’t schedule your standup meeting for first thing in the morning. Give your people time to check their email and get a cup of coffee first. For part of the time when I read this book, I was being extremely disciplined about not doing anything else before I did my yoga, Tony Robbins’s priming exercise, and two hours of focused work in MY business. (I had been letting client work take over my life and take up all my time. This was the antidote.) That’s a lot of discipline, and it was really hard. But if I let myself do a little brain dump and check in on my Trello board (in other words, let myself get settled and clear out my brain a bit) before starting the focused work, I felt a lot better.
To summarize: scrum is an agile process. There’s the project owner, who determines what needs to be done when, based on stakeholder requirements and which features will make the most impact; the scrum master, who manages the project and protects the development team from as much bullshit as possible; and the developers. Everyone is equal, and everyone is full-time on this project.
You create the vision for the product so you know what you’re building toward. Then you create the product roadmap—what features will make the vision a reality? Then you plan the releases, with the most important features first. Then you do the work in a series of sprints, which could be one day, one week, two weeks, but probably not longer than that. The authors recommend one week. For each sprint, you plan the sprint (what are we building this sprint?), have the daily scrum to find out what everybody needs to move forward. At the end of the sprint, you make sure the product works with the new stuff you just built, and you do a retrospective to learn from this sprint so you can do better next time.
For software, the power of this model is you’re always building the most important things, and you’re always testing and releasing, so you get feedback as you go.
Tools to help:
- Task board with 4 columns: to do, in progress, accept, done. Move sticky notes or Trello cards through the pipeline as you do their tasks. (Accept is for tasks that are waiting for acceptance from the product owner.)
- Burndown chart: line graph showing how many hours of work should remain over time as the sprint goes on
Questions for the retrospective:
“- What do you think went well?
- What would you like to change?
- How should we implement that change?”
What do you do if you’re planning the sprint and there’s too much work for the team’s capacity? (P. 102) “Do they hunker down and work overtime? No, the product owner has a decision to make: which sprint backlog items will be moved back to the product backlog to get the number of hours below the development team’s capacity. Sustained overtime leads to poor team morale, poorer quality, and long-term productivity losses.”
After explaining the fundamentals, the book goes on to show how scrum could apply to different industries. I could see where it makes sense for a lot of different applications where you’re building something, including an e-course or a launch. I have a harder time seeing how it applies to something that’s just ongoing, like customer service. And when they tried to apply it to dating, that just felt like a big nerdy reach. Interesting to think about, though.
For my own projects, I already have a weekly cadence, so I’d probably stick with that. For just one or two people, it seems like too much to have all the structure of scrum. (Daily meetings, plus a retrospective every week? That seems like way too much.) But I do like planning what to build each week. It will be different for sure to actually keep that to only an amount that’s possible to do! That could be a real life-changer. And I like the idea of a retrospective after each phase of a project. I’l probably do that.
March 30, 2019
Does provide background/context and quotes from the Agile 'Manifesto', but in a way that makes the methodology seem ridiculous to me. Further it aims to take the methodology out of its intended context (software development, starting after securing an established, tested design.)
This effort highlights for me the absurdity of the methodology _as written_. Agile allows for no project manager as "the team members pick up those tasks", but the 'Product Owner' takes on the role of deciding what is built, when, in what order. Nice in theory, but it does not work well in most companies, and these authors advocate taking this methodology beyond its intended use.
A fundamental tenet of Agile is that changes are 'welcome' at any time in the development. Imagine applying this to construction, or baking ? It's equally absurd in software - some change is fine at specific points, but is it reasonable to change the footprint of a building after the foundation is dug, or change the ingredients of a cake after it's been mixed?
The Agile answer to changes is to 'involve' the 'Product Owner' at every step of the process. This is akin to having to meet with the construction crew daily to listen to their plans, tell them if the area they are working on is a priority from the client's view, talk to the baker about which products will be prepared, mixed, baked, at what point, etc. (A 'good' IT company has 'only' a 30% turnover rate, even with Agile.)
In fact, chunking work into short modules is ideal, but not always efficient for the tasks to be accomplished. Further, this approach is akin to splitting up the writing of a textbook by sections within chapters. Extra work is incurred in tying the sections together, ensuring that the terms are provided and defined, only once, at the appropriate points, etc. It can work, but it takes active coordination. Which Scrum accomplishes via _daily_ stand-up meetings!
This book illustrates well why this methodology is highly 'tailored' from the 'ideal' when it is implemented at various companies. For me it did not add value. Statements such as, "The scrum master's most important trait is clout." are more warnings than help. One cannot learn or practice 'clout' - it may come from a combination of authority, confidence, respect, and hiring/firing power, but if that's the requirement for success, isn't this methodology already a failure?
I would recommend leaving this behind, and reading instead (free online) "The Scrum Guide" https://www.scrumguides.org/scrum-gui... by Schwaber and Sutherland, two of the original authors of the Agile Manifesto (also free online: https://agilemanifesto.org/.)
This effort highlights for me the absurdity of the methodology _as written_. Agile allows for no project manager as "the team members pick up those tasks", but the 'Product Owner' takes on the role of deciding what is built, when, in what order. Nice in theory, but it does not work well in most companies, and these authors advocate taking this methodology beyond its intended use.
A fundamental tenet of Agile is that changes are 'welcome' at any time in the development. Imagine applying this to construction, or baking ? It's equally absurd in software - some change is fine at specific points, but is it reasonable to change the footprint of a building after the foundation is dug, or change the ingredients of a cake after it's been mixed?
The Agile answer to changes is to 'involve' the 'Product Owner' at every step of the process. This is akin to having to meet with the construction crew daily to listen to their plans, tell them if the area they are working on is a priority from the client's view, talk to the baker about which products will be prepared, mixed, baked, at what point, etc. (A 'good' IT company has 'only' a 30% turnover rate, even with Agile.)
In fact, chunking work into short modules is ideal, but not always efficient for the tasks to be accomplished. Further, this approach is akin to splitting up the writing of a textbook by sections within chapters. Extra work is incurred in tying the sections together, ensuring that the terms are provided and defined, only once, at the appropriate points, etc. It can work, but it takes active coordination. Which Scrum accomplishes via _daily_ stand-up meetings!
This book illustrates well why this methodology is highly 'tailored' from the 'ideal' when it is implemented at various companies. For me it did not add value. Statements such as, "The scrum master's most important trait is clout." are more warnings than help. One cannot learn or practice 'clout' - it may come from a combination of authority, confidence, respect, and hiring/firing power, but if that's the requirement for success, isn't this methodology already a failure?
I would recommend leaving this behind, and reading instead (free online) "The Scrum Guide" https://www.scrumguides.org/scrum-gui... by Schwaber and Sutherland, two of the original authors of the Agile Manifesto (also free online: https://agilemanifesto.org/.)
March 30, 2022
This was great.
As I am living agile daily, I gave Agile Project Management for Dummies a read last month, and I wanted to read this book.
This book did a great job at describing the scrum methodology.
Would recommend!
4.3/5
As I am living agile daily, I gave Agile Project Management for Dummies a read last month, and I wanted to read this book.
This book did a great job at describing the scrum methodology.
Would recommend!
4.3/5
March 3, 2017
Seemed like a good introduction to this approach to project management. I'm looking to apply Scrum to project-based learning.
March 23, 2018
J'ai senti beaucoup de répétitions. À mon sens, seuls les premiers paragraphes étaient intéressant.
May 12, 2018
Step by step guide to scrum, for use in multiple applications. Could use more real world examples.
August 1, 2018
Who would have thought that you can use Scrum even for finding a life partner? X)
Very easy language and great examples to understand the framework and artifacts
Very easy language and great examples to understand the framework and artifacts
May 10, 2019
Good ideas for any field
Excellent information on Scrum and also valuable
tips and ideas to apply this framework to any professional or personal field in life.
Excellent information on Scrum and also valuable
tips and ideas to apply this framework to any professional or personal field in life.
September 25, 2021
Read for class.
July 9, 2015
A good introduction to the concepts and history of Scrum. The book goes off the rails though, when the author attempts to apply Scrum to personal life, such as dating.
Read
August 3, 2015Location: ND6 IRC
Accession No: DL027407
Location: PTI IRC
Accession No: DL027408
Location: GG6 IRC
Accession No: DL027409
Accession No: DL027407
Location: PTI IRC
Accession No: DL027408
Location: GG6 IRC
Accession No: DL027409
September 8, 2024
It’s not the scrum I was looking for. It’s too technical and doesn’t have concrete examples that fit what was looking to do — teach my kid scrum.
February 17, 2023
Great Scrum book for beginner. It covers a lot of things, from IT sector until daily life.
March 20, 2023
I give it a 5/5 it's very thorough and an excellent starting point for those interested in the topic.
Displaying 1 - 16 of 16 reviews