Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

SCRUM GUIDE SCRUM GUIDE This guide explains how to use Scrum to build products.

SCRUM GUIDE SCRUM GUIDE This guide explains how to use Scrum to build products. In doing so, it will describe how the framework and its artifacts, time-boxes, roles and rules work together. Scrum does not include techniques and processes for building products; however, it will point out the efficacy and flaws of these techniques and processes. Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory*. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Within each iteration, Scrum employs self-organizing, cross- functional Teams to optimize flexibility and productivity. The heart of Scrum is a Sprint. A Sprint is one iteration of a month or less that is of consistent length throughout a development effort. All Sprints use the same Scrum framework, and all Sprints end with an increment of the end product that is potentially releasable. The increment is a complete slice, or piece, of the finished product or system that is developed by the end of an iteration, or Sprint. One Sprint starts immediately after the prior Sprint ends. Scrum employs time-boxes to create regularity. The time-boxes within Scrum are : the Sprint Planning Meeting, the Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. Scrum employs self-organizing, cross-functional Scrum Teams to do the work. Each Scrum Team has three roles where accountability and responsibility lie. The ScrumMaster is responsible for ensuring the process is understood and followed. The Product Owner is responsible for maximizing the value of the work done. The Team does the work. The Team consists of developers with all the skills to turn the Product Owner’s requests into the potentially shippable increment each Sprint. The Team is usually seven plus or minus two members. The Scrum framework consists of these time-boxes, Teams (with roles), and artifacts glued together by Rules. One rule is that only the people committed to turning the Product Backlog into an increment, namely the Team, talks during a Daily Scrum. * “Agile Software Development with Scrum,” Ken Schwaber, Microsoft Press, 2004 SCRUM GUIDE 02 SCRUM GUIDE TIP: If there are fewer people on the team, the team may reach skill constraints during parts of the Sprint. If there are more members, the team may be overwhelmed with too many people to collaborate and to keep informed. In our experience, however, teams do range outside this recommended size of seven plus or minus two. SCRUM GUIDE 03 Rules bind the roles, time-boxes and meetings. These rules are implicit throughout this document as the roles, time-boxes and meetings are described. When there are suggested approaches, or TIPS, on how to proceed, these are in separate TIP boxes. Scrum has been used to develop complex products since the early 1990s. Many best practices have been uncovered for developing complex products within the Scrum framework. In tandem with this guide, the books “Agile Project Management with Scrum” (Schwaber, Microsoft Press, 2004) and “The Enterprise and Scrum” (Schwaber, Microsoft Press, 2007) contain many tips about managing projects and scaling Scrum. Scrum Theory Scrum is a framework for developing complex products and systems that is grounded in empirical process control theory.* Empirical process control has three legs underlying all of its implementations: transparency, inspection, and adaptation. Transparency means that aspects of the process must be visible to and understood by those controlling the process. The second leg is inspection. The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected. Two key factors of inspection are the skill and diligence of the people inspecting the work and the frequency with which they inspect the process. It must be taken into consideration that all processes are changed by the act of inspection. A conundrum occurs when the required frequency of inspection exceeds the team’s tolerance to inspection of the process. Fortunately, this doesn’t seem to be true in software development. The third leg of empirical process control is adaptation. If the inspector determines from the inspection that one or more aspects of the process are outside acceptable limits, and that the resulting product will be unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation. There are three inspect and adapt points in Scrum. The Sprint Review and Planning meetings are used to inspect progress toward the Release Goal, and to make adaptations that optimize the value of the next Sprint. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next workday. The Retrospective meeting is used to adapt the process and interactions of the previous Sprint, and to make adaptations that make the next Sprint more productive, fulfilling, and enjoyable. TIP: When rules are not stated, the users of Scrum are expected to figure out what to do. Don’t try to figure out a perfect solution, because the problem usually changes quickly. Instead, try something and see how it works. The inspect and adapt mechanisms of Scrum’s empirical nature will guide you. * “Process Dynamics, Modeling, and Control,” Babatunde A. Ogunnaike and W. Harmon Ray, Oxford University Press, 1994 SCRUM GUIDE 04 The Roles The Scrum Team The Scrum Team consists of the ScrumMaster, the Product Owner, and the Team (of developers). Scrum team members are called “pigs” . Everyone else is a “chicken.” Chickens cannot tell “pigs” how to do their work. Chickens and pigs come from the following story: “A chicken and a pig are together when the chicken says, “Let’s start a restaurant!” The pig thinks it over and says, “What would we call this restaurant?” The chicken says, “Ham n’ Eggs!” The pig says, “No thanks, you’d only be involved but for me it would be a real commitment!” The ScrumMaster The ScrumMaster is responsible for ensuring that Scrum values, practices and rules are enacted and enforced. The ScrumMaster is the driving force behind all of the Scrum and helps the Scrum Team and the organization adopt and use Scrum to produce a higher quality product. The ScrumMaster is not the manager but leads by coaching, teaching and supporting the team. The ScrumMaster helps the Team understand and use self- management and cross-functionality. Product Owner The Product Owner is the one and only person responsible for managing and controlling the Product Backlog. This is the person who is officially responsible for the value of the work done. This person maintains the Product Backlog and ensures that it is visible to everyone. Everyone knows what items have the highest priority, so everyone knows the order in which the items will be addressed. The Product Owner is one person, not a committee. Committees may exist that advise or influence this person, but any person or body of people wanting an item’s priority changed must convince the Product Owner. Organizations have many ways TIP: The ScrumMaster may be part of the Team such as a developer performing Sprint tasks. However, if this is the case, there may be conflict between removing impediments and performing tasks. The ScrumMaster is never the Product Owner. TIP: For commercial development, the Product Owner may be the product manager. For in-house development efforts, the Product Owner could be the user department manager. TIP: The ScrumMaster works with the customers and management to identify and instantiate a Product Owner. The ScrumMaster teaches the Product Owner how to do his or her job, in order to optimize the value of the use Scrum. If they don’t, the ScrumMaster is held accountable. SCRUM GUIDE 05 of setting priorities and requirements. These practices will be influenced by Scrum across time, particularly through the meeting that reviews product increments (Sprint Review). For the Product Owner to succeed, everyone in the organization has to respect his or her decisions. No one is allowed to tell the Teams to work from a different set of priorities, and Teams aren’t allowed to listen to anyone who says otherwise. The Product Owner’s decisions are visible in the content and prioritization of the Product Backlog. This visibility requires the Product Owner to do his or her best, and makes the role of Product Owner both a demanding and a rewarding one. The Team Teams are the developers who turn Product Backlog into increments of potentially shippable functionality every Sprint. Teams are responsible for organizing themselves to do the work. Teams are cross-functional, having all the skills needed to create an increment. There are no titles for team members. Teams self- organize to turn the requirements and technology into product functionality. Everyone chips in and does his or her best, doing or learning how to do what is needed. No job descriptions. No titles, no exceptions. For example, people who refuse to code because they are systems architects or designers could not be part of a Scrum Team. Teams are cross functional. A Scrum Team should include people with uploads/s3/ scrum-guide.pdf