The Scrum Manual

Xavier Quesada Allue

v1.1 - 24/May/2011

About this manual

This manual is intended as pre-reading material before taking a Scrum training. The goal is for the trainee to become acquainted with the basic framework and the terminology. Thus, it is short and to the point, and does not cover any implementation details. It is not recommended for standalone reading.

Acknowledgements Parts of this manual are directly derived from material originally published in: The Scrum Primer v1.2 by Deemer, Benefield, Larman and Vodde. The Scrum Guide, by Schwaber and Sutherland, Scrum Alliance version (retired).

Scrum is an Agile framework for product development. Product development is usually structured around projects, so you can also think of Scrum as an agile approach to project management. Rather than a full process or methodology, Scrum is a simple framework based on Agile principles, practices and values. This means that instead of providing complete, detailed descriptions of how everything should be done on a project, Scrum is lightweight and most of the implementation details are left up to the people actually doing the work.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. www.agilemanifesto.org Snowbird, Utah, USA February 2001

Principles behind the Agile Manifesto

We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Scrum Framework Scrum is the most widely implemented Agile method, with an estimated 75% of market share in 20091. At the center of Scrum is the Sprint. A Sprint is an iteration of fixed length, generally one to four weeks. A Scrum project is structured as a series of consecutive Sprints. All Sprints start with a sprint goal and should end with an increment of product that is potentially shippable. The next Sprint starts immediately after the prior Sprint ends. Sprints are timeboxed they end on a specific date whether the work has been completed or not. Sprints, by definition, can never be extended. At the beginning of each Sprint, a Scrum team selects a number of end-user requirements (generally called user stories or just stories for short) from a prioritized list called the Product Backlog. The team commits to complete the selected stories by the end of the Sprint. During the Sprint, the chosen stories do not change. Every day the team gathers briefly to inspect its progress, and adjust the next steps needed to complete the work remaining. At the end of the Sprint, the team reviews the Sprint with stakeholders, and demonstrates the stories it has successfully built. Scrum Roles In Scrum, there are three roles: The Product Owner, The Team, and The ScrumMaster. The Product Owner is responsible for maximizing return on investment. The Product Owner does this by identifying product features, translating these into a prioritized list, deciding which should be at the top of the list for the next Sprint, and continually updating, re-prioritizing and refining the list as the project evolves. Prioritization may be influenced by technical dependencies, the need to satisfy key customers, alignment with strategic objectives, mitigating risks, and other factors. In some cases, the Product Owner and the final customer or end user are the same person; this is common for internal development. In others, the customer or end user might be external customers of the organization, in which case the Product Owner role might be similar to a Product Manager position. Yet in other (less desirable) situations, the Product Owner might be a proxy to the real customer. The Product Owner in Scrum is one person. A single responsible person is fundamental to guarantee there will never be conflicting priorities for the team regarding what to do next.

VersionOne State of Agile survey 2009, www.versionone.com

The Team builds the product that the Product Owner indicates. The Team in Scrum is crossfunctional it includes all the expertise necessary to deliver the potentially shippable product each Sprint and it is self-organizing, with a very high degree of autonomy and accountability. The Team decides what to commit to, and how best to accomplish that commitment. The Team designs, develops and tests the product and provides ideas to the Product Owner about how to make the product great. The team is also responsible for ensuring the internal quality of the product, which the Product Owner might not be able to assess. A Team in Scrum is recommended to be between 5 and 9 people, to be sitting together, and to be full-time dedicated to the work of the project. Other configurations are possible, but suboptimal.

The ScrumMaster helps the Team and Product Owner succeed at delivering maximum business value and getting the full benefits of Scrum. The ScrumMaster serves the Team and Product Owner by removing impediments that are blocking them from getting their work done; protects them from outside interference; makes sure everyone understands and follows the practices of Scrum; acts as facilitator and guardian for the Scrum process; and helps lead the organization through the often difficult change required to achieve success with agile development. Good ScrumMasters have coaching and facilitation skills, have a servant leader mentality, and are good at solving and unblocking problems. They can come from any background or discipline: Engineering, Product Management, Project Management, Line Management, etc. The ScrumMaster in Scrum is one person, and for medium to large projects it is a full-time job.

Starting with Scrum The first step in Scrum is for the Product Owner to articulate the product vision. The vision is then transformed into a prioritized and estimated list of features called the Product Backlog. The backlog is the product roadmap and planning. All this happens before the first Sprint, during a period that is sometimes referred to as sprint zero. The shorter this period, the better. A good Product Backlog is a prioritized list of requirements (stories), expressed as much as possible as end-user functionalities in simple terms that anybody can understand. Only a single Product Backlog exists; and every story has a unique priority. This means the Product Owner is required to make prioritization decisions across the entire spectrum of demands representing the interest of different stakeholders and influenced by the team. The Product Backlog can be updated by the Product Owner at any time to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth. In order to do proper planning, the Product Backlog should be estimated. The Team provides the Product Owner with estimates of the effort required to complete each item. Taking into account size, business value, and other important factors such as risks and dependencies, the Product Owner prioritizes the backlog with the help and advice of the team. Release Planning Projects and products are commonly organized around releases. A release is typically defined by the moment when a product goes into production or is launched into the market. Scrum teams focus their detailed planning around the next release of their product. The goal is to have a realistic planning horizon; planning too far into the future is wasteful except at a very high level. Release planning in Scrum involves identifying the functionality that we want to include in the next release, making sure it is broken down into manageable pieces that are estimated and prioritized, and defining a target release date. A release burndown chart is a simple chart that shows us in a visual way how much scope we need to deliver sprint by sprint in order to reach our target release date. It is created during release planning, and updated by the Product Owner at the end of every sprint.

Sprint Planning At the beginning of each Sprint, the Sprint Planning Meeting takes place. During the first part of the Sprint Planning, the Product Owner and the Team (with facilitation from the ScrumMaster) review the high-priority items in the Product Backlog that the Product Owner is interested in implementing during the Sprint that is starting. The Team then selects as many items from the Product Backlog as they believe they can complete by the end of the Sprint, starting from the top (in others words, starting with the items that are the highest priority for the Product Owner) and working down the list in order. The Team decides how much work it will commit to complete, rather than having it assigned to them by the Product Owner. This makes for a more reliable commitment because the Team is making it based on its own analysis and planning, rather than having it decided by someone else. If the team cannot commit to as much work as the Product Owner would like, this is discussed as a capacity problem but the Product Owner can never impose a scope on the Team. While the Product Owner does not have control over how much the Team commits to, he or she knows that the items the Team is committing to are drawn from the top of the Product Backlog in other words, the items that he or she has rated as most important. During the second part of the Sprint Planning, the team goes into detail regarding how to actually implement the chosen stories. Typically this involves some analysis and design discussions, and breaking up stories into tasks. Tasks are individual small steps that the team identifies as necessary to completely develop a story. Typically tasks have no meaning for the Product Owner, they might be technical in nature. Ideally, tasks should be no larger than one day in size. Once the Team makes its commitment, the Sprint can start. A sprint has fixed scope and fixed time, so any additions or changes in functionality must be deferred until the next Sprint. If halfway through the Sprint the Product Owner decides there is a new high priority story, they have to wait until the start of the next Sprint.

Daily Scrum The daily Scrum is a short (15 minutes or less) synchronization and feedback meeting that happens every workday at the same hour in the same place. Everyone who is actively working on the project should attend. To keep it brief, it is recommended that everyone remain standing. It is the Teams opportunity to align, synchronize their work and notify each other of obstacles. In the Daily Scrum, one by one, each member of the Team talks about three things: (1) What they were able to get done since the last meeting; (2) what they are planning to finish by the next meeting; and (3) any blocking issues or impediments that are in their way. The Daily Scrum is not a status report meeting to a manager or to the Product Owner or ScrumMaster. The goal is exclusively for the team to coordinate and align among themselves. After a successful daily Scrum everybody should know who is working on what, and should be confident that everybody is doing the most valuable thing they could be doing to help the Team succeed in delivering what was committed for the current Sprint. There should be no discussions during the Daily Scrum, or it will never finish on time. Any issues that surface in the Daily Scrum that require discussion should be addressed immediately afterwards in a follow-up meeting Taskboard The Taskboard is used by the Team to self-organize, visualize, plan and keep track of their day to day work during the sprint. A taskboard contains all the work that needs to be done by the team, generally represented by stories and tasks. Typically tasks are written on Post-it notes that are placed along columns representing the state they are in (for example: not started, in progress and done). The taskboard is populated at the beginning of the Sprint during the Sprint Planning, and updated continuously throughout the Sprint as the team gets work done. A good Taskboard is always up to date and accurately reflects the work that everybody is doing. It is a complement to the Daily Scrum, which is normally held in front of it.

Ending the Sprint The duration of the Sprint is never extended it ends on the assigned date regardless of whether the Team has completed the work it committed to or not. Stories that were not finished remain in progress and are moved on to the next sprint or cancelled if no longer valid. Partially completed work earns the team no credit. Sprint Review Every Sprint ends with a Sprint Review, where the Team and the Product Owner go over the work that was completed during the iteration. A key idea in Scrum is inspect and adapt in order to continuously improve. To observe what is going on and evolve based on feedback, in repeating cycles. The Sprint Review constitutes the inspect and adapt activity for the product being built. Present at this meeting are the Product Owner, Team members, and ScrumMaster, plus anyone else interested in following up the progress on the project. The sprint review should be open and transparent. It might include customers, domain experts, senior management, representatives of other business units essentially anyone who is considered a stakeholder. A typical Sprint Review will include a short, high level demo of the new functionalities that have been built into the existing product. Feedback is captured from all people present. The feedback creates conversation about the product, led by the Product Owner and facilitated by the ScrumMaster. Eventually the conclusions gathered are fed by the Product Owner back into the product backlog in the shape of new or changed stories for future Sprints.

Sprint Retrospective The Sprint Retrospective, which follows the Review, is an improvement activity regarding the process, the way of working. It is the moment for the Team to discuss what is going well and what should be changed. Everything that is not working well with the current process should be discussed, and a series of improvements that can be implemented during the next Sprint should be decided upon and committed to. The ScrumMaster facilitates the Retrospective and is responsible for maintaining the Improvement Backlog which is the list of improvements that have to be done. Every Sprint ends with a Retrospective. When a team stops doing retrospectives, they stop improving; if they stop improving they are no longer doing Scrum.

Closing comments Scrum is simple, but doing Scrum correctly is hard. Just like chess, the rules are easy to learn but the game is hard to master.