# The Power of Scrum  ## Metadata - Author: [[Jeff Sutherland, Rini van Solingen, Eelco Rustenberg]] - Full Title: The Power of Scrum - Category: #books ## Highlights - “To use a rough analogy: in the game of rugby the players form into a group called the scrum and try to get control of the ball so that their team can run with it and score. They pass the ball back and forth to each other to gain momentum going down the field. In our version of the game, the ball represents ideas, and the scrum is simply called ‘Scrum.’” ([Location 149](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=149)) - When people talk about Agile, they often think that you’ll just work faster. With Scrum you can become faster, but that isn’t the main purpose. The purpose of Scrum is to increase your agility. ([Location 159](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=159)) - In a nutshell, what Scrum forces you to do is to always be open to adapting your priorities. And if your priorities change, your product changes. These priorities are set by new insights and ideas, both from yourself and your client. ([Location 162](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=162)) - Scrum makes you keep your promises. It brings things under control, makes things transparent both to you and to your customer. It forces you to be honest with yourself, your company, and your client.” ([Location 178](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=178)) - Scrum lets you develop in short cycles. Each cycle is called a “Sprint.” Scrum supports a development team by becoming completely flexible regarding the work in the next Sprint. In return the team needs to be completely inflexible regarding the work in the current Sprint, thus guaranteeing that they complete each Sprint. ([Location 367](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=367)) - “That could be a good idea. But I wouldn’t call it a beta. That sends the wrong message, both to your customer and to yourself. It says it doesn’t have to be good. I’d say it was a product increment, or a ‘feature set.’ That way, you’re saying that while it’s only a part of the product, it’s a part that is done. That’s ready.” ([Location 411](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=411)) - Never do betas. Never do work that you don’t think is good. You either give your customer something good, or you don’t. There is no ‘try’.” ([Location 415](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=415)) - Scrum doesn’t have project managers. Instead, the team is empowered. They’re responsible for the outcome, and they can manage themselves. The classic project manager ‘boss’ of the team isn’t needed in Scrum. The team plans each Sprint based on the priorities of the Product Owner. They divide the work among themselves, make progress transparent and monitor themselves. ([Location 432](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=432)) - Knowledge workers need to be facilitated, not controlled. Give them clear goals and the freedom to manage themselves, and you’ll have a smooth-running machine.” ([Location 441](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=441)) - But his job is only to manage the process, keep it running well, and make sure the rhythm is maintained. But the Scrum Master is not the boss!” ([Location 447](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=447)) - Note: Role of a Scrum Master - We call that test-driven development. Again, not really part of Scrum, but it really helps. ([Location 479](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=479)) - we eventually want a comprehensive automatic testing script we can run after each build. ([Location 515](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=515)) - Using Scrum, the product is always ready. You are able to deliver a version of your product that is at most one Sprint old. ([Location 535](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=535)) - If a task is going to take a couple of days, it’s too big; break it into smaller sub-tasks. You also, ideally, want a single developer to be able to complete the task. So if you have a two-day, two-developer task, you break it up. If it’s too hard to break up, that usually indicates that what needs to be done is not clear enough, or it’s not clear enough what the end result should be. ([Location 623](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=623)) - Using Scrum, the product is always ready. You are able to deliver a version of your product that is at most one Sprint old. ([Location 774](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=774)) - Scrum team should be seven people plus or minus two. ([Location 777](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=777)) - In the Sprint planning meeting, items on the Sprint backlog are split into individual tasks. These tasks should take between 2 and 4 hours of work, with a maximum of 2 days. ([Location 780](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=780)) - Accept that functionality is flexible. It’s going to change. It can’t be frozen up front. Once you accept that, then you can nail down quality, cost, and time. You set high-level functional goals for your project, but with very hard and strict budgets of both time and money. ([Location 887](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=887)) - By making the functionality dimension flexible, you are forced to look at it over and over. By doing that, you can freeze effort and cost—if you want.” ([Location 891](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=891)) - “It’s better that a project manager not become the Scrum Master of his project. When a former project manager steps into that role, there’s a fair chance that everyone will fall back into their old patterns. The developers will expect him to solve all their problems, and he’ll feel obligated to do so.” ([Location 962](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=962)) - Accept that functionality is flexible and cannot be fixed in detail up front. Such flexibility requires regular feedback. ([Location 983](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=983)) - With Scrum you set overall goals for your project or product, with very strict budgets and milestones. The requirements are detailed “just in time” before every sprint. ([Location 985](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=985)) - Scrum helps you to focus on quality. There is a working product sooner, so you do quality testing earlier, in each and every Sprint. ([Location 992](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=992)) - The best way to learn Scrum and to learn to appreciate it is by applying it ‘by the book’. A lot of companies make the mistake of trying to customize Scrum before they understand how it actually works. They nip and tuck, and often erode the philosophy behind Scrum. They think they’re using Scrum, but they don’t realize what they’ve lost by taking things out. As a result, they miss out on a lot of what Scrum has to offer.” ([Location 1035](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1035)) - The key was to propose something that could be completed in two weeks, and released as an enhancement to a working product. Each Sprint brought you that much closer toward a real release. ([Location 1053](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1053)) - You can learn to apply and appreciate Scrum best by doing it “by the book.” ([Location 1278](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1278)) - Try to keep focused on the Sprint during these meetings. Share with the team what you’re doing, what you’ve achieved, and when you’re dependent on them for something. Mention the problems that put the Sprint at risk. ([Location 1351](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1351)) - “Problems you can’t resolve that threaten the Sprint are called ‘impediments.’ At the standup meeting, they’ll be assigned to someone; usually the Scrum Master takes the lead. It’s important that the impediments be resolved that day! Either by reassigning work, rescheduling, talking to the Product Owner about priorities, whatever. It doesn’t matter what the solution is, just make sure it’s solved by the next day. ([Location 1355](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1355)) - To determine if something is really “finished” and whether it meets the predetermined quality criteria, Scrum uses a tool: the Definition of Done (DoD). The DoD is a list of criteria that is used as a checklist to ensure that nothing is forgotten and that the work is truly finished. ([Location 1525](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1525)) - The DoD is also used in the Sprint Planning Meeting to assess whether the team has completely defined all necessary work-items. ([Location 1528](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1528)) - The Product Owner determines only what comes out of the process, not how that process is formed. ([Location 1533](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1533)) - A common failing in Scrum is a Product Owner with not enough knowledge to define and not enough authority to defend the backlog.” ([Location 1549](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1549)) - A backlog shows an overall vision of the future, but not a detailed one. You only detail the next couple of Sprints, but you do define your vision in a broad way. You express in chunks of increasing size what may come later. ([Location 1644](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1644)) - Your job as Product Owner is to put the what, the why, and for whom it is important in the backlog. In other words, you set the context within which the team can figure out the best solution. The ‘why’ is really important, because that communicates the value of the backlog item. ([Location 1655](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1655)) - The great thing about user stories is that they aren’t complete.” ([Location 1680](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1680)) - The Product Owner is crucial for effective Scrum. Even a team with a great working process will still suffer from “garbage in, garbage out.” ([Location 1702](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1702)) - The Product Owner role is the most difficult and least understood role in Scrum. If the Product Owner doesn’t have the authority, or simply lacks sufficient knowledge, she won’t be able to decide on product backlog issues, and the Scrum implementation will fail. ([Location 1704](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1704)) - The Product Owner must ensure that a backlog does not describe “solutions,” but instead it lists “value requests.” In Scrum this is done using “user stories” that describes a usage scenario and setting. It describes the what, the for whom, and the value of that scenario: the why. ([Location 1710](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1710)) - A backlog holds the vision for the future. It provides a “destination on the horizon.” The product backlog contains all the ideas, whether strategic or not. They are then prioritized in terms of value. The further away in time they lie, the more abstractly they are described. ([Location 1715](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1715)) - ‘Change is hard.’ ([Location 1743](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1743)) - Making a decision, sticking with it and adapting to whatever happens. That’s what makes us strong, both in our lives and in our work. But saying out loud that it isn’t easy, acknowledging the fear and upset—that’s the first step. Because change is hard. ([Location 1756](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1756)) - “The Retrospective is the most important meeting in Scrum. After all, this is where you can explicitly improve your processes—how you can get better! If you do Scrum well, each Sprint is better than the one before. ([Location 1825](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1825)) - A Retrospective begins with looking at the results of the last Retrospective; ([Location 1835](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1835)) - If the Retrospective becomes nothing more than defining potential actions that aren’t acted upon, it is useless. If the improvements identified in the Retrospective are not implemented, then Scrum fails! Without that implementation, there is no improvement; if there isn’t continuous improvement, Scrum dies. That is the whole point: to get better!” ([Location 1837](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1837)) - We knew that no matter what we did, it would be in alignment with what the customer actually wanted, not what we thought the customer wanted—and that would increase the value of the product for them. ([Location 1901](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1901)) - Scrum puts emphasis on quickly delivering the most added value ([Location 1995](https://readwise.io/to_kindle?action=open&asin=B007474YMC&location=1995))