Scrum (Scrum.

org) - Ken Schwaber and Jeff Sutherland February 2010 1 Scrum has been used to develop complex products since the early 1990s. This paper describes how to use Scrum to build products. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them while providing a framework within which complex products can be developed. Theory 2 Scrum, which is grounded in empirical process control theory, employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control. The first leg is transparency 3 Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. Not only must these aspects be transparent, but also what is being seen must be known. That is, when someone inspecting a process believes that something is done; it must be equivalent to their definition of done. The second leg is inspection 4 The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected. The frequency of inspection has to take into consideration that all processes are changed by the act of inspection. A conundrum occurs when the required frequency of inspection exceeds the tolerance to inspection of the process. Fortunately, this doesnt seem to be true of software development. The other factor is the skill and diligence of the people inspecting the work results. The third leg is adaptation 5 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 points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, 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. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable.

Traduccin del Scrum Guide - February 2010 - Ken Schwaber and Jeff Sutherland David Arteaga Scrum se usa para desarrollar productos complejos desde principios de los 90. Este documento describe cmo usar Scrum para construir productos. Scrum no es un proceso o una tcnica para construir productos; mas bien es un marco de referencia en el cual podemos emplear distintos procesos y tcnicas. El rol del Scrum es destacar la eficiencia relativa de sus prcticas de desarrollo de modo que podamos mejorarlas y a la vez proporcionar un marco de referencia para desarrollar productos complejos. Teora El Scrum, que se basa en la teora del control de proceso emprico, emplea un enfoque iterativo, incremental para optimizar la predictibilidad y el control del riesgo. Tres pilares sostienen cada implementacin del proceso de control emprico. El primer soporte es la transparencia La transparencia asegura que los aspectos del proceso que afectan el resultado deben ser visibles a aquellos que gestionan los resultados. No slo estos aspectos deben ser transparentes sino tambin que, lo que se ve debe ser conocido. Es decir, cuando alguien que inspecciona un proceso cree que algo est hecho, esto debe ser equivalente a su definicin de hecho. El segundo soporte es la inspeccin Los distintos aspectos del proceso deben ser inspeccionados frecuentemente de modo que las variaciones inaceptables en el proceso puedan ser detectadas. La frecuencia de la inspeccin tiene que tomar en consideracin que todos los procesos cambian por el acto de inspeccin. El problema sucede cuando la frecuencia requerida de inspeccin excede la tolerancia de inspeccin del proceso. Afortunadamente, esto no parece ser cierto en el desarrollo de software. El otro factor es las habilidades y diligencia de las personas inspeccionando los resultados finales.

El tercer soporte es la adaptacin Si el inspector determina, a partir de la inspeccin, que uno ms aspectos del proceso estn fuera de lmites aceptables y que el producto resultante ser inaceptable, el inspector debe ajustar el proceso o material que est siendo procesado. El ajuste debe realizarse tan pronto como sea posible para minimizar desviacin futura. Hay tres puntos para la inspeccin y adaptacin en Scrum. La reunin Scrum Diaria se usa para inspeccionar el avance hacia el objetivo del Sprint y para ralizar adaptaciones que optimicen el valor del siguiente da de trabajo. Adicionalmente, las reuniones de Revisin Sprint y Planeamiento Sprint se usan para inspeccionar el avance hacia el Objetivo Release y realizar adaptaciones que optimicen el valor del siguiente Sprint. Finalmente, la Retrospectiva Sprint se usa para revisar el Sprint anterior y determinar cules adaptaciones harn el siguiente Sprint ms productivo, cumplidor y divertido. Scrum Content Contenido del Scrum 6 The Scrum framework consists of a set of Scrum Teams and their associated roles; Time-Boxes, El marco de referencia Scrum consiste en un conjunto de Equipos Scrums y sus roles asociados; Artifacts, and Rules. Espacios de Tiempo Fijo, Artefactos y Reglas 7 Scrum Teams are designed to optimize flexibility and productivity; to this end, they are selfLos Equipos Scrum estn diseados para optimizar la flexibilidad y productividad; con este objetivo, organizing, they are cross-functional, and they work in iterations. Each Scrum Team has three roles: son auto-organizados, inter-funcionales y trabajan en iteraciones. Cada Equipo Scrum tiene tres 1) the ScrumMaster, who is responsible for ensuring the process is understood and followed; 2) the roles: 1) El ScrumMaster, quien es responsible de asegurar que el proceso se comprende y se Product Owner, who is responsible for maximizing the value of the work that the Scrum Team does; sigue; 2) el Product Owner, quien es responsable de maximizar el valor del trabajo que el Equipo and 3) the Team, which does the work. The Team consists of developers with all the skills to turn the Scrum realiza; y 3) el Equipo, que realiza el trabajo. El Equipo consiste en desarrolladores con todas las habilidades para convertir los requerimientos del Product Owner en un pedazado potencialmente Product Owners requirements into a potentially releasable piece of the product by the end of the liberable del producto al final del Sprint. Sprint.

El Scrum usa Espacios de Tiempo Fijo para crea regularidad. Los elementos del Scrum que son Espacios Fijos de Tiempo incluyen la Reunin de Planificacin de Release, la Reunin de Planificacin del Sprint, el Sprint, el Scrum Diario, la Revisin Sprint y la Retrospectiva Sprint. El corazn del Scrum es el Sprint, que es una iteracin de un mes menos y que es de duracin consistente a lo largo del esfuerzo de desarrolo. Todos los Sprints usan el mismo marco de referencia Scrum y todos los Sprints entregan un incremento del producto final que es potencialmente liberable. Un Sprint comienza inmediatamente despus del otro. 9 Scrum employs four principal artifacts. The Product Backlog is a prioritized list of everything that El Scrum emplea cuatro artefactos. El Product Backlog es una lista priorizada de todo lo que puede might be needed in the product. The Sprint Backlog is a list of tasks to turn the Product Backlog for ser necesario en el producto. El Sprint Backlog es una lista de tareas que convierten el Product one Sprint into an increment of potentially shippable product. A burndown is a measure of remaining Backlog en un incremento de producto potencialmente entregable para un Sprint. El burndown es backlog over time. A Release Burndown measures remaining Product Backlog across the time of a una medida del backlog remanente en el tiempo. Un Release Burndown mide el remanente del Product Backlog a lo largo del tiempo de un release plan. Un Sprint Burndown mide el remanente de release plan. A Sprint Burndown measures remaining Sprint Backlog items across the time of a los tems del Sprint Backlog a lo largo del tiempo de un Sprint. Sprint. 10 Rules bind together Scrums time-boxes, roles, and artifacts. Its rules are described throughout the body of this document. For example, it is a Scrum rule that only Team members - the people committed to turning the Product Backlog into an increment can talk during a Daily Scrum. Ways of implementing Scrum that are not rules but rather are suggestions are described in Tips boxes. Las reglas mantienen juntos los Espacios de Tiempo Fijo, roles y artefactos del Scrum. Las reglas del Scrum estn descritas a lo largo del cuerpo de este documento. Por ejemplo, es una regla Scrum que slo los integrantes del Equipo - las personas comprometidas en convertir el Product Backlog en un incremento - pueden hablar durante un Scrum Diario. Las formas de implementar el Scrum que no son reglas pero si sugerencias se describen como "Consejos".

8 Scrum employs time boxes to create regularity. Elements of Scrum that are time-boxed include the Release Planning Meeting, the Sprint Planning Meeting, the Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The heart of Scrum is a Sprint, which is an iteration of one month or less that is of consistent length throughout a development effort. All Sprints use the same Scrum framework, and all Sprints deliver an increment of the final product that is potentially releasable. One Sprint starts immediately after the other.

Tip 11 When rules are not stated, the users of Scrum are expected to figure out what to do. Dont 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 Scrums empirical nature will guide you. Scrum Rules 12 The Scrum Team consists of the ScrumMaster, the Product Owner, and the Team. Scrum Team members are called pigs. The Product Owner is the pig of the Product Backlog. The Team is the pig of the Sprint work. The ScrumMaster is the pig of the Scrum process. Everyone else is a chicken. Chickens cannot tell pigs how to do their work. Chickens and pigs come from the 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, I'd be committed, but you'd only be involved!"

Consejo Cuando no hay reglas explcitas, se espera que los usuarios del Scrum resuelvan qu hacer. No trate de crear una solucin perfecta, porque usualmente el problema cambia rpidamente. En vez de eso, trate algo y vea si funciona. Los mecanismos de inspeccciones-y-adaptar de la naturaleza emprica del Scrum le guiarn. Reglas del Scrum El Equipo Scrum consiste del ScrumMaster, el Product Owner y el Equipo. Los integrantes del Equipo Scrum se llaman "cerdos". El Product Owner es el "cerdo" del Product Backlog. El Equipo es el "cerdo" del trabajo del Sprint. El ScrumMaster es el "cerdo" del proceso Scrum. Cualquier persona adiciona es un "pollo". Los pollos no pueden decir a los "cerdos" cmo hacer su trabajo. Los pollos y los cerdos provienen de la historia, "Un pollo y un cerdo estn juntos y el pollo dice, "Comencemos un restaurante!" El cerdo lo piensa y dice, "Cmo llamaremos a este restaurante?" El pollo responde, "Jamn y Huevos!" El cerdo responde, "No gracias, yo estara comprometido, pero tu slo estaras involucrado!" Tip Consejo 13 The ScrumMaster works with the customers and management to identify and instantiate a Product El ScrumMaster trabaja con los clientes y gerencia para identificar e instancias un Product Owner. El Owner. The ScrumMaster teaches the Product Owner how to do his or her job. Product Owners are ScrumMaster ensea al Product Owner cmo hacer su trabajo. Se espera que los Product Owners sepan cmo gestionar para optimizar el valor usando Scrum. Si no sabem, hacemos que el expected to know how to manage to optimize value using Scrum. If they dont, we hold the ScrumMaster sea el encargo final de esto. ScrumMaster accountable. The ScrumMaster ScrumMaster 14 The ScrumMaster is responsible for ensuring that the Scrum Team adheres to Scrum values, El ScrumMaster es responsible de asegurar que el Equipo Scrum se adhiere a los valores, prcticas practices, and rules. The ScrumMaster helps the Scrum Team and the organization adopt Scrum. y reglas Scrum. El ScrumMaster ayuda al Equipo Scrum y a la organizacin a adoptar el Scrum. El The ScrumMaster teaches the Scrum Team by coaching and by leading it to be more productive and ScrumMaster ensea al Equipo Scrum mediante coaching y liderandolo para ser ms productivo y produce higher quality products. The ScrumMaster helps the Scrum Team understand and use self- producir productos de alta calidad. El ScrumMaster ayuda al Equipo Scrum a comprender y usar la organization and cross-functionality. The ScrumMaster also helps the Scrum Team do its best in an auto-organizacin e inter-disciplina. El ScrumMaster tambin ayuda al Equipo Scrum a hacer su organizational environment that may not yet be optimized for complex product development. When mejor esfuerzo en un entorno organizacional que puede no estar optimizado para el desarrollo de the ScrumMaster helps make these changes, this is called removing impediments. The productos complejos. Cuando el ScrumMaster ayuda a hacer estos cambios, se llama "remover ScrumMasters role is one of a servant-leader for the Scrum Team. impedimentos". El rol ScrumMaster es de un lder al servicio del Equipo Scrum. Tip Consejo

15 The ScrumMaster may be a member of the Team; for example, a developer performing Sprint tasks. El ScrumMaster puede ser un integrante del Equipo; por ejemplo, un desarrollador realizando tareas However, this often leads to conflicts when the ScrumMaster has to choose between removing Sprint. Sin embargo, frecuentemente esto conduce a conflictos cuando el ScrumMaster tiene que impediments and performing tasks. The ScrumMaster should never be the Product Owner. elegir entre remover impedimentos y realizar tareas. El ScrumMaster nunca debera ser el Product Owner. The Product Owner Product Owner 16 The Product Owner is the one and only person responsible for managing the Product Backlog and El Product Owner es una persona y es la nica responsible de gestionar el Product Backlog y ensuring the value of the work the Team performs. This person maintains the Product Backlog and asegurar el valor del trabajo que el Equipo realiza. Esta persona mantiene el Product Backlog y asegura que es visible a todos. Cada uno conoce cules tems tienen la ms alta prioridad, de modo ensures that it is visible to everyone. Everyone knows what items have the highest priority, so que todos conocen qu se trabajar. everyone knows what will be worked on. 17 The Product Owner is one person, not a committee. Committees may exist that advise or influence El Product Owner es una persona, no es un comit. Los comits pueden existir para aconsejar o influencias a esta persona, pero las personas quienes quieren cambiar la prioridad de un tem tienen this person, but people who want to change an items priority have to convince the Product Owner. que convencer al Product Owner. Las compaas que adoptan el Scrum pueden encontrar que este Companies that adopt Scrum may find it influences their methods for setting priorities and (el Scrum) influencia sus mtodos para establecer prioridades y requerimientos en el tiempo. requirements over time. Tip 18 For commercial development, the Product Owner may be the product manager. For in-house development efforts, the Product Owner could be the manager of the business function that is being automated. 19 For the Product Owner to succeed, everyone in the organization has to respect his or her decisions. No one is allowed to tell the Team to work from a different set of priorities, and Teams arent allowed to listen to anyone who says otherwise. The Product Owners 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 it makes the role of Product Owner both a demanding and a rewarding one. Tip 20 The Product Owner can be a Team member, also doing development work. This additional responsibility may cut into the Product Owners ability to work with stakeholders. However, the Product Owner can never be the ScrumMaster. The Team 21 Teams of developers turn Product Backlog into increments of potentially shippable functionality every Sprint. Teams are also cross-functional; Team members must have all of the skills necessary to create an increment of work. Team members often have specialized skills, such as programming, quality control, business analysis, architecture, user interface design, or data base design. However, the skills that Team member share that is, the skill of addressing a requirement and turning it into a usable product tend to be more important than the ones that they do not. People who refuse to code because they are architects or designers are not good fits for Teams. Everyone chips in, even if that requires learning new skills or remembering old ones. There are no titles on Teams, and there are no exceptions to this rule. Teams do not contain sub-Teams dedicated to particular domains like testing or business analysis, either. Consejo Para desarrollo comercial, el Product Owner puede ser el gerente de producto. Para esfuerzos internos de desarrollo, el Product Owner podra ser el gerente de la funcin de negocio que est siendo automatizada. Para que el Product Owner sea exitoso, todos en la organizacin tienen que respetar sus decisiones. Nadie est permitido decir al Equipo trabajar en un conjunto diferente de prioridades y los Equipos no estn permitidos de escuchar a persona alguna que diga lo contrario. Las decisiones del Product Owner son visibles en el contenido y priorizacin del Product Backlog. Esta visibilidad requiere que el Product Owner haga su mejor esfuerzo y hace del rol Product Owner un rol demandante y provechoso. Consejo El Product Owner puede ser un integrante del Equipo, tambin puede hacer trabajo de desarrollo. Esta responsabilidad adicional puede debilitar la habilidad del Product Owner de trabajar con los stakeholders. Sin embargo, el Product Owner nunca puede ser el ScrumMaster. El Equipo Los Equipos de desarrolladores convierten el Product Backlog en incrementos de funcionalidad potencialmente entregable cada Sprint. Los Equipos tambin son inter-funcionales; los integrantes del Equipo deben tener todas las habilidades necesarias para crear un incremento del trabajo. Los integrantes del Equipo tienen frecuentemente habilidades especializadas tales como programacin, control de calidad, anlisis de negocio, arquitectura, diseo de interfase usuario diseo de base de datos. Sin embargo, las habilidades que el integrante de Equipo comparte - es decir, la habilidad de resolver un requerimiento y convertirlo en un producto til - tiende a ser ms importante que aquellas que no tienen. Las personas quienes rehsan escribir cdigo porque son arquitectos o diseadores no son buenos para estar en un Equipo.Todos contribuyen, inclusive si esto requiere aprender nuevas habilidades o recordar antiguas. No hay ttulos en los Equipos y no hay excepciones a esta regla. Los Equipos no contienen sub-Equipos dedicados a dominios en particular como pruebas anlisis de dominio. Los Equipos tambin son auto-organizados. Nadie - inclusive el ScrumMaster - le dice al equipo cmo convertir el Product Backlog en incrementos de funcionalidad entregable. El Equipo resuelve esto solo. Cada integrante del Equipo aplica su pericia a todos los problemas. La sinergia que resulta mejora la eficiencia y efectividad integral del Equipo completo.

22 Teams are also self-organizing. No one not even the ScrumMaster - tells the Team how to turn Product Backlog into increments of shippable functionality. The Team figures this out on its own. Each Team member applies his or her expertise to all of the problems. The synergy that results improves the entire Teams overall efficiency and effectiveness.

23 The optimal size for a Team is seven people, plus or minus two. When there are fewer than five Team members, there is less interaction and as a result less productivity gain. Whats more, the Team may encounter skill constraints during parts of the Sprint and be unable to deliver a releasable piece of the product. If there are more than nine members, there is simply too much coordination required. Large Teams generate too much complexity for an empirical process to manage. However, we have encountered some successful Teams that have exceeded the upper and lower bounds of this size range. The Product Owner and ScrumMaster roles are not included in this count unless they are also pigs, working on tasks in the Sprint Backlog.

El tamao ptimo para un Equipo es siete personas, ms menos dos. Cuando hay menos de cinco integrantes en el Equipo, hay menos interaccin y como resultado se gana menos productividad. Lo que es ms importante sealar es que el Equipo puede encontrar restricciones a las habilidades durante partes del Sprint y puede ser incapaz de entregar un pedazo liberable del producto. Si hay ms de nueve integrantes, simplemente se requiere mucha coordinacin. Grandes Equipos generan mucha complejidad a gestionar para un proceso emprico. Sin embargo, hemos encontrado algunos Equipos exitosos que exceden los lmites superior e inferior de este rango de tamao. Los roles Product Owner y ScrumMaster no estn incluidos en este conteo a menos que tambin sean cerdos, trabajando en tareas del Sprint Backlog. La composicin del Equipo puede cambiar al final de un Sprint. Cada vez que cambia algn integrante del Equipo, la productividad ganada de la auto-organizacin se ve disminuida. Debe tenerse cuidado cuando se cambia la composicin del Equipo. Espacios de Tiempo Fijo (Time-Boxes) Los Espacios de Tiempo Fijo son la Reunin de Planificacin de Release, el Sprint, la Reunin de Planificacin del Sprint, la revisin del Sprint, la Retrospectiva del Sprint y el Scrum Diario. Reunin de Planificacin del Release El propsito de la planificacin del Release es establecer un plan y objetivos que el Equipo Scrum y el resto de las organizaciones puedan entender y comunicar. La planificacin del Release responde a las preguntas, "Cmo podemos convertir la visin en un producto ganador de la mejor manera posible? Cmo podemos satisfacer exceder la satisfaccin deseada del cliente y el Retorno de la Inversin?" El plan del Release establece el objetivo del Release, el Product Backlog de ms alta prioridad, los riesgos principales y las caractersticas y funcionalidad completas que el Release contendr. Tambin establece una fecha probable de entrega y el costo que debera mantenerse si nada cambia. La organizacin entonces puede inspeccionar el avance y realizar cambios a este plan del Release sobre una base de Sprint por Sprint.

24 Team composition may change at the end of a Sprint. Every time Team membership is changed, the productivity gained from self-organization is diminished. Care should be taken when changing Team composition. Time-Boxes 25 The Time-Boxes in Scrum are the Release Planning Meeting, the Sprint, the Sprint Planning Meeting, the Sprint Review, the Sprint Retrospective, and the Daily Scrum. Release Planning Meeting 26 The purpose of release planning is to establish a plan and goals that the Scrum Teams and the rest of the organizations can understand and communicate. Release planning answers the questions, How can we turn the vision into a winning product in best possible way? How can we meet or exceed the desired customer satisfaction and Return on Investment? The release plan establishes the goal of the release, the highest priority Product Backlog, the major risks, and the overall features and functionality that the release will contain. It also establishes a probable delivery date and cost that should hold if nothing changes. The organization can then inspect progress and make changes to this release plan on a Sprint-by-Sprint basis.

27 Release planning is entirely optional. If Scrum teams start work without the meeting, the absence of its artifacts will become apparent as an impediment that needs to be resolved. Work to resolve the impediment will become an item in the Product Backlog.

La planificacin del Release es compeltamente opcional. Si los Equipos Scrum comienzan a trabajar sin la reunin, la ausencia de sus artefactos se convertir en evidente como un impedimento que necesita ser resuelto. Trabajar para resolver el impedimento se convertir en un tem en el Product Backlog. 28 Products are built iteratively using Scrum, wherein each Sprint creates an increment of the product, Los Productos se construyen de manera iterativa usando Scrum, en el que cada Sprint crea un starting with the most valuable and riskiest. More and more Sprints create additional increments of incremento del producto, comenzando con al de mayor valor y riesgo. Ms y ms Sprints crean the product. Each increment is a potentially shippable slice of the entire product. When enough incrementos adicionales del producto. Cada incremento es un pedazo potencialmente entregable del producto completo. Cuando se han creado suficientes incrementos para el Producto, de valor, de increments have been created for the Product to be of value, of use to its investors, the product is uso para sus inversores, el producto se libera. released. 29 Most organizations already have a release planning process, and in most of these processes most of La mayora de organizaciones ya tienen un proceso de planificacin de release y en muchos de the planning is done at the beginning of the release and left unchanged as time passes. In Scrum estos procesos la mayora de la planificacin est hecha al inicio del release y permanece sin release planning, an overall goal and probable outcomes are defined. This release planning usually cambios conforme el tiempo pasa. En la planificacin Scrum del Release, se define un objetivo requires no more than 15-20% of the time an organization consumed to build a traditional release completo y probables resultados. Esta planificacin de Release requiere usualmente no ms del plan. However, a Scrum release performs just-in-time planning every Sprint Review and Sprint 15% a 20% del tiempo que una organizacin consume para construir un plan tradicional de release. Planning meeting, as well as daily just-in-time planning at every Daily Scrum meeting. Overall, Sin embargo, un release Scrum realiza planificacin just-in-time en cada reunin de Revisin Sprint Scrum release efforts probably consume slightly more effort than tradition release planning efforts. y reunin de Planificacin Sprint, as como planificacin diaria just-in-time en cada reunin Scrum Diario. De manera integral, los esfuerzos de un release Scrum probablemente consumen un poco ms esfuerzo que los esfuerzos de una planificacin tradicional de release. 30 Release planning requires estimating and prioritizing the Product Backlog for the Release. There are many techniques for doing so that lie outside the purview of Scrum but are nonetheless useful when used with it. The Sprint La planificacin del Release requiere estimacin y priorizacin del Product Backlog para el Release. Hay muchas tcnicas para hacer esto que estan fuera del alcance de la visin del Scrum pero no son tiles cuando se usan con Scrum. El Sprint

31 A Sprint is an iteration. Sprints are time-boxed. During the Sprint, the ScrumMaster ensures that no changes are made that would affect the Sprint Goal. Both Team composition and quality goals remain constant throughout the Sprint. Sprints contain and consist of the Sprint Planning meeting, the development work, the Sprint Review, and the Sprint Retrospective. Sprints occur one after another, with no time in between Sprints.

Un Sprint es una iteracin. Los Sprints son Espacios de Tiempo Fijo. Durante el Sprint, el ScrumMaster asegura que no se realizan cambios que afectaran el Objetivo del Sprint. Tanto la composicin del Equipo como los objetivos de calidad permanecen constantes a lo largo del Sprint. Los Sprints contienen y consisten en la Reunin de Planificacin del Sprint, el trabajo de desarrollo, la Revisin del Sprint, la Retrospectiva del Sprint. Los Sprints suceden uno despus de otro, no hay tiempo entre Sprints. 32 A project is used to accomplish something; in software development, it is used to build a product or Un proyecto se usa para lograr algo; en el desarrollo de softwsare, se usa para construir un producto o sistema. Cada proyecto consiste de una definicin de qu ser construido, un plan para system. Every project consists of a definition of what is to be built, a plan to build it, the work done according to the plan, and the resultant product. Every project has a horizon, which is to say the time construirlo, el trabajo hecho de acuerdo al plan y el producto resultante. Cada proyecto tiene un horizonte, que es lo mismo que decir el marzo de tiempo para el cual el plan es bueno. Si el frame for which the plan is good. If the horizon is too long, the definition may have changed, too horizonte es muy extenso, la definicin pueda cambiar, muchas variables pueden ingresar, el riesgo many variables may have entered in, the risk may be too great, etc. Scrum is a framework for a puede ser muy grande, etc. El Scrum es un marco de referencia para un proyecto cuyo horizonte no project whose horizon is no more than one month long, where there is enough complexity that a longer horizon is too risky. The predictability of the project has to be controlled at least each month, es mayor a un mes, donde hay suficiente complejidad tal que un horizonte ms extenso es muy and the risk that the project may go out of control or become unpredictable is contained at least each riesgoso. La predictibilidad del proyecto tiene que ser controlada al menos cada mes y el riesgo que el proyecto salga fuera de control o se convierta en impredecible est contenida al menos cada mes. month. Tip 33 If the Team senses that it has overcommitted, it meets with the Product Owner to remove or reduce the scope of Product Backlog selected for the Sprint. If the Team senses that it may have extra time, it can work with the Product Owner to select additional Product Backlog. 34 When a Team begins Scrum, two-week Sprints allow it to learn without wallowing in uncertainty. Sprints of this length can be synchronized with other Teams by adding two increments together. 35 Sprints can be cancelled before the Sprint time box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Team, or the ScrumMaster. Under what kind of circumstances might a Sprint need to be cancelled? Management may need to cancel a Sprint if the Sprint Goal becomes obsolete. This could occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. However, because of the short duration of Sprints, it rarely makes sense to do so. 36 When a Sprint is cancelled, any completed and done Product Backlog items are reviewed. They are accepted if they represent a potentially shippable increment. All other Product Backlog items are put back on the Product Backlog with their initial estimates. Any work done on them is assumed to be lost. Sprint terminations consume resources, since everyone has to regroup in another Sprint planning meeting to start another Sprint. Sprint terminations are often traumatic to the Team, and they are very uncommon. Sprint Planning Meeting 37 The Sprint Planning meeting is when the iteration is planned. It is time-boxed to eight hours for a one month Sprint. For shorter Sprints, allocate proportionately less of the total Sprint length to this meeting (for example, two weeks would be a four-hour Sprint Planning Meeting). The Sprint Planning Meeting consists of two parts. The first part is when what will be done in the Sprint is decided upon. The second part (a four-hour time-box for a monthly Sprint) is when the Team figures out how it is going to build this functionality into a product increment during the Sprint. Consejo Si el equipo siente que est sobre-comprometido, se rene con el Product Owner para remover reducir el alcance del Product Backlog seleccionado para el Sprint. Si el Equipo siente que puede tener tiempo adicional, puede trabajar con el Product Owner para seleccionar Product Backlog adicional. Cuando un Equipo comienza con Scrum, Sprints de dos semanas le permite aprender sin perderse en la incertidumbre. Los Sprints de esta duracin pueden sincronizarse con otros Equipos agregando dos incrementos a la vez. Los Sprints pueden cancelarse antes que el Espacio de Tiempo Fijo para el Sprint se termine. Slo el Product Owner tiene la autoridad para cancelar el Sprint, aunque l puede hacerlo bajo la influencia de los stakeholders, el Equipo o el ScrumMaster. Bajo cules circunstancias un Sprint debe ser cancelado? La gerencia puede necesitar cancelar un Sprint si el Objetivo del Sprint se convierte en obsoleto. Esto podra suceder si la compaa cambia de direccin o si las condiciones de mercado o tecnologa cambian. En general, un sprint debera ser cancelado si no tiene mas sentido dadas las circunstancias. Sin embargo, debido a la duracin corta de los Sprints, rara vez tiene sentido hacerlo. Cuando un Sprint se cancela, se revisa cualquier tem del Product Backlog listo. Estos se aceptan si representan un incremento potencialmente entregable. Todos los otros tems del product Backlog se colocan en el Product Backlog con sus estimaciones iniciales. Cualquier trabajo hecho sobre ellos se asume perdido. Las terminaciones de un Sprint consumen recursos, debido a que todos tienen que reagruparse en otra reunin de planificacin de Sprint para comenzar otro Sprint. Las temrinaciones de un Sprint son frecuentemente traumticas para el Equipo y son poco comunes. Reunin de Planificacin del Sprint La reunin de Planificacin del Sprint es cuando la iteracin se planifica. Es un espacio de tiempo fijo de ocho horas para un Sprint de un mes. Para Sprints ms cortos, asignar a esta reunin proporcionalmente menos del tiempo de la duracin total del Sprint (por ejemplo, para dos semanas sera una Reunin de Planificacin de Sprint de cuatro horas). La reunin de Planificacin del Sprint consiste en dos partes. La primera parte es cuando se decide qu ser hecho en el Sprint. La segunda parte (un espacio de tiempo fijo de cuatro horas para un Sprint de un mes) es cuando el Equipo resuelve c'omo va a construir esta funcionalidad en un incremento de producto durante el Sprint.

Hay dos partes en la Reunin de Planificacin del Sprint: la parte del Qu? y la parte del Cmo?. Algunos Equipos Scrum combinan las dos. En la primera parte, el Equipo Scrum resuelve la pregunta "Qu?". Aqu, el Product Owner presenta la prioridad ms alta del Product Backlog al Equipo. Ellos trabajan juntos para resolver cul funcionalidad ser desarrollada durante el siguiente Sprint. La entrada para esta reunin es el Product Backlog, el ltimo incremento del producto, la capacidad del Equipo y el desempeo pasado del Equipo. La cantidad de backlog que el Equipo selecciona es completa potestad del Equipo. Slo el Equipo puede evaluar qu puede lograr en el siguiente Sprint. 39 Having selected the Product Backlog, a Sprint Goal is crafted. The Sprint Goal is an objective that Habiendo seleccionado el Product Backlog, se plantea un Objetivo del Sprint. El Objetivo del Sprint will be met through the implementation of the Product Backlog. This is a statement that provides es un objetivo que ser satisfecho mediante la implementacin del product Backlog. Esta es una guidance to the Team on why it is building the increment. The Sprint Goal is a subset of the release declaracin que proporciona gua al Equipo en porqu est construyendo un incremento. El Objetivo goal. del Sprint es un subconjunto del objetivo del release. La razn para tener un Objetivo del Sprint es proporcionar al Equipo alguna referencia respecto a la 40 The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could also be: Automate the client account funcionalidad. Por ejemplo, el objetivo del Sprint podra ser: "Automatizar la funcionalidad de modificacin de la cuenta cliente a travs de una capacidad middleware transaccional segura y modification functionality through a secure, recoverable transaction middleware capability. As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and recuperable". Conforme el Equipo trabaja, mantiene en mente este objetivo. A fin de satisfacer el technology. If the work turns out to be harder than the Team had expected, then the Team objetivo, implementa la funcionalidad y tecnologa. Si el trabajo se hace ms difcil que lo que el collaborates with the Product Owner and only partially implement the functionality. Equipo esperaba, entonces el Equipo colabora con el Product Owner y slo implementa parcialmente la funcionalidad. En la segunda parte de la Reunin de Planificacin del Sprint, el Equipo resuelve la pregunta del 41 In the second part of the Sprint Planning Meeting, the Team addresses the question of How? During the second part of the Sprint Planning Meeting (four hour time-box for a monthly Sprint), the "Cmo?" Durante la segunda parte de la Reunin de Planificacin del Sprint (un espacio de tiempo Team figures out how it will turn the Product Backlog selected during Sprint Planning Meeting (What) fijo de cuatro horas para un Sprint de un mes), el Equipo resuelve cmo convertira el product into a done increment. The Team usually starts by designing the work. While designing, the Team Backlog seleccionado duranta la Reunin de Planificacin del Sprint (Qu) en un incremento listo. El identifies tasks. These tasks are the detailed pieces of work needed to convert the Product Backlog Equipo usualmente comienza diseando el trabajo. Mientras disea, el Equipo identifica tareas. Estas tareas son las piezas detalladas de trabajo necesarias para convertir el Product Backlog en into working software. Tasks should have decomposed so they can be done in less than one day. software que funcione. Las tareas deberan estas descompuestas de modo que puedan hacerse en This task list is called the Sprint Backlog. The Team self-organizes to undertake the work in the menos de un da. Esta lista de tareas se llama Sprint Backlog. El Equipo se auto-organiza para Sprint Backlog, either during the Sprint Planning meeting or just-in-time during the Sprint. comprometerse con el trabajo en el Sprint Backlog, ya sea durante la reunin de Planificacin del Sprint just-in-time durante el Sprint. Tip 42 Usually, only 60-70% of the total Sprint Backlog will be devised in the Sprint Planning meeting. The rest is stubbed out for later detailing, or given large estimates that will be decomposed later in the Sprint. 43 The Product Owner is present during the second part of the Sprint Planning Meeting to clarify the Product Backlog and to help make trade-offs. If the Team determines that it has too much or too little work, it may renegotiate the Product Backlog with the Product Owner. The Team may also invite other people to attend in order to provide technical or domain advice. A new Team often first realizes that it will either sink or swim as a Team, not individually, in this meeting. The Team realizes that it must rely on itself. As it realizes this, it starts to self-organize to take on the characteristics and behavior of a real Team. Consejo Usualmente, slo del 60% al 70% del total del Sprint Backlog ser elaborado en la reunin de Planificacin del Sprint. El resto es resuelto para detalle ms adelante se dan estimaciones grandes que sern descompuestas posteriormente en el Sprint. El Product Owner est presente durante la segunda parte de la Reunin de Planificacin del Sprint para clarificar el Product Backlog y ayudar a realizar negociaciones. Si el Equipo determina que hay mucho muy poco trabajo, puede renegociar el product Backlog con el Product Owner. El Equipo tambin puede invitar a otras personas que asistan a fin de proporcionar consejo tcnico o de dominio. Frecuentemente un Equipo nuevo primero se da cuenta que se hundir o flotar como Equipo, no individualmente en esta reunin. El Equipo se da cuenta que debe confiar en s mismo. Conforme se da cuenta de esto, comienza a auto-organizarse para tomar las caractersticas y comportamiento de un Equipo real. Sprint Review Revisin del Sprint 44 At the end of the Sprint, a Sprint Review meeting is held. This is a four hour time-boxed meeting for Al final del Sprint, se realiza una reunin de Revisin del Sprint. Esta es una reunin de espacio de one month Sprints. For Sprints of lesser duration, allocate proportionately less of the total Sprint tiempo fijo de cuatro horas para Sprints de un mes. Para Sprints de menos duracin, asignar length to this meeting (for example, two weeks would be a two-hour Sprint Review). During the Sprint proporcionalmente menos tiempo de la duracin total del Sprint a esta reunin (por ejemplo, para un Review, the Scrum Team and stakeholders collaborate about what was just done. Based on that and Sprint de dos semanas sera una Revisin del Sprint de dos horas). Durante la Revisin del Sprint, changes to the Product Backlog during the Sprint, they collaborate about what are the next things el Equipo Scrum y los stakeholders colaboran acerca de qu ha sido hecho. En base a esto y los that could be done. This is an informal meeting, with the presentation of the functionality intended to cambios al Product Backlog durante el Sprint, colaboran acerca de cules son las siguientes cosas foster collaboration about what to do next. que podran hacerse. Esta es una reunin informal, con la presentacin de la funcionalidad se pretende promover colaboracin acerca de qu hacer a continuacin.

38 There are two parts to the Sprint Planning Meeting: the What? part and the How? part. Some Scrum Teams combine the two. In the first part, the Scrum Team addresses the question of What? Here, the Product Owner presents the top priority Product Backlog to the Team. They work together to figure out what functionality is to be developed during the next Sprint. The input to this meeting is the Product Backlog, the latest increment of product, the capacity of the Team, and past performance of the Team. The amount of backlog the Team selects is solely up to the Team. Only the Team can assess what it can accomplish over the upcoming Sprint.

45 The meeting includes at least the following elements. The Product Owner identifies what has been done and what hasnt been done. The Team discusses what went well during the Sprint and what problems it ran into, and how it solved these problems. The Team then demonstrates the work that is done and answers questions. The Product Owner then discusses the Product Backlog as it stands. He or she projects likely completion dates with various velocity assumptions. The entire group then collaborates about what it has seen and what this means regarding what to do next. The Sprint Review provides valuable input to subsequent Sprint Planning meeting.

La reunin incluye al menos los siguientes elementos. El Product Owner identifica que ha sido hecho y que no ha sido hecho. El Equipo discute que sucedi bien durante el Sprint y cules se convirtieron en problemas y cmo resolvieron estos problemas. El Equipo entonces demuestra el trabajo hecho y responde preguntas. El Product Owner entonces discute el Product Backlog estando de pie. l(lla) proyecta las fechas de trmino probables con varias asumciones de velocidad. El grupo entero entonces colabora acerca de qu se ha visto y qu significa esto respecto a lo que se har a continuacin. La Revisin del Sprint proporciona informacin de entrada de valor para la siguiente reunin de Planificacin del Sprint. Retrospectiva del Sprint Despus de la Revisin del Sprint y antes de la siguiente reunin de Planificacin del Sprint, el Equipo Scrum tiene la reunin de Retrospectiva del Scrum. Esta es una reunin de espacio de tiempo fijo de tres horas para Sprints mensuales (asignar proporcionalmente menos tiempo de la duracin total del Sprint para esta reunin). En esta reunin, el ScrumMaster alienta al Equipo Scrum a revisar, dentro del marco de referencia de proceso Scrum y prcticas, su proceso de desarrollo para hacerlo ms efectivo y satisfactorio para el siguiente Sprint. Muchos libros documentan tcnicas que son de tiles para usar en Retrospectivas. El propsito de la Retrospectiva es inspeccionar cmo estuvo el ltimo Sprint respecto a las personas, relaciones, proceso y herramientas. La inspeccin debera identificar y priorizar los principales tems que estuvieron bien y aquellos tems que si se hicieran de manera diferente podran hacer que las cosas estn inclusive mejor. Esto incluye la composicin del Equipo Scrum, organizacin de reuniones, herramientas, definicin de "listo", mtodos de comunicacin y procesos para convertir tems del Product backlog en algo "listo". Al final de la Retrospectiva del Sprint, el Equipo Sprint debera haber identificado mtricas de mejora que generan accin a implementar en el siguiente Sprint. Estos cambios se convierten en la adaptacin a la inspeccin emprica. Scrum Diario Cada Equipo se rene diariamente para una reunin de inspeccin y adaptacin de 15 minutos llamada Scrum Diario. El Scrum Diario es a la misma hora y en el mismo lugar a lo largo de los Sprint. Durante la reunin, cada integrante del Equipo explica: 1. Qu ha logrado desde la ltima reunin? 2. Qu va a hacer antes de la siguiente reunin?, y 3. Qu obstculos estn en su camino? Los Scrum Diarios mejoran las comunicaciones, eliminan otras reuniones, identifican y remueven impedimentos para desarrollar, resaltan y promueven toma de decisiones rpidas y mejoran el nivel de conocimiento de todos del proyecto. El ScrumMaster asegura que el Equipo tiene la reunin. El Equipo es responsible de realizar el Scrum Diario. El ScrumMaster ensea al equipo a mantener el Scrum Diario breve forzando las reglas y asegurando que las personas hablan brevemente. El ScrumMaster tambin fuerza la regla que los pollos no estn permitidos hablar o interferir de forma alguna en el Scrum Diario. El Scrum Diario no es una reunin de estado. No es para cualquier persona, sino para las personas que transforman los tems del Product Backlog en un incremento (el Equipo). El Equipo s eha comprometido con un Objetivo del Sprint, y con estos tems del Product Backlog. El Scrum Diario es una inspeccin del avance hacia el Objetivo del Sprint (las tres preguntas). usualmente, las reuniones de seguimiento suceden para realizar adaptaciones al trabajo que viene a continuacin en el Sprint. La intencin es optimizar la probabilidad que el Equipo satisfacer su Objetivo. Esta es una reunin clave de inspeccin y adaptacin en el proceso emprico Scrum. Artefactos Scrum Los Artefactos Scrum son el Product Backlog, El Release Burndown, el Sprint Backlog y el Sprint Burndown. Product Backlog y Release Burndown

Sprint Retrospective 46 After the Sprint Review and prior to the next Sprint Planning meeting, the Scrum Team has a Sprint Retrospective meeting. This is a three hour, time-boxed meeting for monthly Sprints (allocate proportionately less of the total Sprint length to this meeting). At this meeting, the ScrumMaster encourages the Scrum Team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint. Many books document techniques that are helpful to use in Retrospectives.

47 The purpose of the Retrospective is to inspect how the last Sprint went in regards to people, relationships, process and tools. The inspection should identify and prioritize the major items that went well and those items that-if done differently-could make things even better. These include Scrum Team composition, meeting arrangements, tools, definition of done, methods of communication, and processes for turning Product Backlog items into something done. By the end of the Sprint Retrospective, the Scrum Team should have identified actionable improvement measures that it implements in the next Sprint. These changes become the adaptation to the empirical inspection. Daily Scrum 48 Each Team meets daily for a 15-minute inspect and adapt meeting called the Daily Scrum. The Daily Scrum is at the same time and same place throughout the Sprints. During the meeting, each Team member explains: 1. What he or she has accomplished since the last meeting; 2. What he or she is going to do before the next meeting; and 3. What obstacles are in his or her way. 49 Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve everyone's level of project knowledge. 50 The ScrumMaster ensures that the Team has the meeting. The Team is responsible for conducting the Daily Scrum. The ScrumMaster teaches the Team to keep the Daily Scrum short by enforcing the rules and making sure that people speak briefly. The ScrumMaster also enforces the rule that chickens are not allowed to talk or in anyway interfere with the Daily Scrum. 51 The Daily Scrum is not a status meeting. It is not for anyone but the people transforming the Product Backlog items into an increment (the Team). The Team has committed to a Sprint Goal, and to these Product Backlog items. The Daily Scrum is an inspection of the progress toward that Sprint Goal (the three questions). Follow-on meetings usually occur to make adaptations to the upcoming work in the Sprint. The intent is to optimize the probability that the Team will meet its Goal. This is a key inspect and adapt meeting in the Scrum empirical process.

Scrum Artifacts 52 Scrum Artifacts include the Product Backlog, the Release Burndown, the Sprint Backlog, and the Sprint Burndown. Product Backlog and Release Burndown

53 The requirements for the product that the Team(s) is developing are listed in the Product Backlog. The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization. Product Backlog is never complete. The initial cut at developing it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Backlog is dynamic in that it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, Product Backlog also exists.

Los requerimientos para el producto que el(los) Equipo(s) est(n) desarrollando se enumeran en el Product Backlog. El Product Owner es responsable del Product Backlog, su contenido, su disponibilidad y su priorizacin. El Product Backlog nunca est completo. El corte inicial en el desarrollo slo muestra el conocimiento inicial y el mejor entendimiento de los requerimiento. El Product Backlog evoluciona conforme el producto y entorno en el que ser usado evoluciona. El Backlog es dinmico en el sentido que cambia constantemente para identificar que es lo que el producto necesita para ser apropiado, competitivo y til. Mientras un producto exista, tambin existe el Product Backlog. 54 The Product Backlog represents everything necessary to develop and launch a successful product. It El Product Backlog representa todo lo necesario para desarrollar y lanzar un producto exitoso. Es is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the una lista de todas las caractersticas, funciones, tecnologas, mejoras y correcciones a errores que changes that will be made to the product for future releases. Product Backlog items have the constituyen los cambios que se harn al producto en futuros releases. Los tems del Product attributes of a description, priority, and estimate. Priority is driven by risk, value, and necessity. There Backlog tienen los atributos de una descripcin, prioridad y estimacin. La prioridad depende del are many techniques for assessing these attributes. riesgo, valor y necesidad. Hay muchas tcnicas para evaluar estos atributos. Tip 55 Product Backlog items are usually stated as User Stories. Use Cases are appropriate as well, but they are better for use in developing life- or mission-critical software. 56 Consejo Los tems del Product Backlog usualmente se expresan en User Stories. Los Casos de Uso tambin son apropiados, pero es mejor usarlos en el desarrollo de software de misin crtica o que afecta vida humana. El Product Backlog est ordenado por prioridad. Un Product Backlog de alta prioridad gua Product Backlog is sorted in order of priority. Top priority Product Backlog drives immediate inmediatamente actividades de desarrollo. Mientras ms alta es la prioridad, ms urgente es, ms development activities. The higher the priority, the more urgent it is, the more it has been thought about, and the more consensus there is regarding its value. Higher priority backlog is clearer and has tiempo lo hemos meditado, y hay ms consenso respecto a su valor. Un backlog de alta prioridad es more detailed information than lower priority backlog. Better estimates are made based on the ms claro y tiene ms informacin detallada que el backlog de menor prioridad. Mejores greater clarity and increased detail. The lower the priority, the less the detail, until you can barely estimaciones se hacen en base a gran claridad y ms detalle. Mientras mas baja es la prioridad, make out the item. menos detalle, hasta que podamos completar algo del item. As a product is used, as its value increases, and as the marketplace provides feedback, the Conforme un producto se usa, su valor aumenta y el mercado proporciona retroalimentacin, el backlog del producto emerge en una lista grande y ms exhaustiva. Los requerimientos nunca paran products backlog emerges into a larger and more exhaustive list. Requirements never stop de cambiar. El Product Backlog es un documento vivo. Los cambios en los requerimientos de changing. Product Backlog is a living document. Changes in business requirements, market conditions, technology, and staffing cause changes in the Product Backlog. To minimize rework, only negocio, condiciones de mercado, tecnologa y personal producen cambios en el Product Backlog. Para minimizar el re-trabajo, slo los tems de ms alta prioridad necesitan ser detallados. Los tems the highest priority items need to be detailed out. The Product Backlog items that will occupy the Teams for the upcoming several Sprints are fine-grained, having been decomposed so that any one del Product Backlog que ocuparn a los Equipos en los siguientes diferentes Sprints estn detallados finamente, han sido descompuestos de modo que cualquier tem puede hacerse dentro item can be done within the duration of the Sprint. de la duracin del Sprint. Tip Consejo Scrum Teams often spend 10% of each Sprint grooming the product backlog to meet the above Los Equipos Scrum frecuentemente invierten 10% de cada Sprint en preparar el Product Backlog definition of the Product Backlog. When groomed to this level of granularity, the Product Backlog para satisfacer la definicin previa del Product Backlog. Cuando se prepara a este nivel de items at the top of the Product Backlog (highest priority, greatest value) are decomposed so they fit granularidad, los tems del Product Backlog al inicio del Product Backlog (ms alta prioridad, mayor within one Sprint. They have been analyzed and thought through during the grooming process. valor) estn descompuestos de modo que caben dentro de un Sprint. Han sido analizados y When the Sprint Planning meeting occurs, these top priority Product Backlog items are well pensados a lo largo del proceso de preparacin. Cuando la reunin de Planificacin del Sprint understood and easily selected. sucede, estos tems de la ms alta prioridad del Product Backlog estn bien comprendidos y son fcilmente seleccionados. Multiple Scrum Teams often work together on the same product. One Product Backlog is used to Frecuentemente mltiples Equipos Scrum trabajan juntos en el mismo producto. Se usa un Product describe the upcoming work on the Product. A Product Backlog attribute that groups items is then Backlog para describir el trabajo prximo en el Producto. Se usa un atributo que agrupa items en el employed. Grouping can occur by feature set, technology, or architecture, and it is often used as a Product Backlog. El agrupamiento puede suceder por conjunto de caractersticas, tecnologa way to organize work by Scrum Team. arquitectura y frecuentemente se usa como una forma de organizar el trabajo del Equipo Scrum.

57

58

59

Consejo 60 Acceptance tests are often used as another Product Backlog item attribute. They can often supplant Las pruebas de aceptacin se usan frecuentemente como otro atributo de un item del Product more detailed text descriptions with a testable description of what the Product Backlog item must do Backlog. Frecuentemente pueden reemplazar descripciones de texto ms detalladas con una when completed. descripcin verificable de lo que el tem del Product Backlog debe hacer cuando est completo. 61 The Release Burndown graph records the sum of remaining Product Backlog estimated effort across El grfico Release Burndown registra la suma del esfuerzo estimado restante del product Backlog a time. The estimated effort is in whatever unit of work the Scrum Team and organization have lo largo del tiempo. El esfuerzo estimado est en cualquier unidad de trabajo que el Equipo Scrum y decided upon. The units of time are usually Sprints. la organizacin han decidido. Las unidades de tiempo son usualmente Sprints.

62 Product Backlog item estimates are calculated initially during Release Planning, and thereafter as they are created. During Product Backlog grooming they are reviewed and revised. However, they can be updated at any time. The Team is responsible for all estimates. The Product Owner may influence the Team by helping understand and select trade-offs, but the final estimate is made by the Team. The Product Owner keeps an updated Product Backlog list Release Backlog Burndown posted at all times. A trend line can be drawn based on the change in remaining work.

Las estimaciones de un item de Product Backlog se calculan inicialmente durante la Planificacin del Release y poco despus que el tem se crea. Durante la preparacin del Product Backlog se revisan y actualizan. Sin embargo, pueden actualizarse en cualquier momento. El Equipo es responsable de todas las estimaciones. El Product Owner puede influenciar al Equipo ayudando a entender y seleccionar alternativas / negociar, pero la estimacin final es hecha por el Equipo. El Product Owner mantiene una lista actualizada de Product Backlog y un Release Backlog Burndown publicado todo el tiempo. Una lnea de tendencia puede dibujarse en base al cambio en el trabajo remanente. Tip Consejo 63 In some organizations, more work is added to the backlog than is completed. This may create a En algunas organizaciones, se agrega ms trabajo al backlog que lo que se completa. Esto puede trend line that is flat or even slopes upwards. To compensate for this and retain transparency, a new crear una lnea de tendencia horizontal o inclusive que sube un poco. Para compensar esto y ser floor may be created when work is added or subtracted. The floor should add or remove only transparentes, puede crearse un nuevo piso cuando se agrega o retira trabajo. El piso debera significant changes and should be well documented. agregarse o removerse slo con cambio significativos y debera estar bien documentado. 64 The trend line may be unreliable for the first two to three Sprints of a release unless the Teams have La lnea de tendencia puede no ser confiable para los primeros dos tres Sprints de un release a worked together before, know the product well, and understand the underlying technology. menos que los Equipos hayan trabajado juntos antes, conozcan bien el producto y comprendan la tecnologa base. Sprint Backlog and Sprint Burndown Sprint Backlog y Sprint Burndown 65 The Sprint Backlog consists of the tasks the Team performs to turn Product Backlog items into a El Sprint Backlog consiste en las tareas que el Equipo realiza para convertir los tems del Product done increment. Many are developed during the Sprint Planning Meeting. It is all of the work that Backlog en un incremento "listo". Muchas se desarrollan durante la Reunin de Planificacin del the Team identifies as necessary to meet the Sprint goal. Sprint Backlog items must be Sprint. Es todo el trabajo que el Equipo identifica como necesario para satisfacer el objetivo del decomposed. The decomposition is enough so changes in progress can be understood in the Daily Sprint. Los tems del Sprint Backlog deben estar descompuestos. La descomposicin es suficiente Scrum. One day or less is a usual size for a Sprint Backlog item that is being worked on. de modo que los cambios en el avance pueden entenderse en el Scrum Diario. Un da o menos es un tamao usual para un tem del Sprint Backlog sobre el que se est trabajando. 66 The Team modifies Sprint Backlog throughout the Sprint, as well as Sprint Backlog emerging during the Sprint. As it gets into individual tasks, it may find out that more or fewer tasks are needed, or that a given task will take more or less time than had been expected. As new work is required, the Team adds it to the Sprint Backlog. As tasks are worked on or completed, the estimated remaining work for each task is updated. When tasks are deemed unnecessary, they are removed. Only the Team can change its Sprint Backlog during a Sprint. Only the Team can change the contents or the estimates. The Sprint Backlog is a highly visible, real time picture of the work that the Team plans to accomplish during the Sprint, and it belongs solely to the Team. El Equipo modifica el Sprint Backlog a lo largo del Sprint, as como el Sprint Backlog emerge durante el Sprint. Conforme se transforma en tareas individuales, se descubren ms o menos tareas necesarias, o que una tarea determinada tomar ms o menos tiempo que el esperado. Conforme se requiere nuevo trabajo, el Equipo lo agrega al Sprint Backlog. Conforme se trabaja en las tareas o se completan, la estimacin del trabajo remanente para cada tarea se actualiza. Cuando se considera que las tareas son innecesrias, se remueven. Slo el Equipo puede cambiar su Sprint Backlog durante un Sprint. Slo el Equipo puede cambiar el contenido o las estimaciones. El Sprint Backlog es una foto altamente visible, en tiempo real del trabajo que el Equipo planea lograr durante el Sprint y le permanece exclusivamente al Equipo. El Sprint Backlog Burndown es un grfico de la cantidad de trabajo remanente del Sprint Backlog en un Sprint a lo largo del tiempo en el Sprint. Para crear este grfico, determinar cunto trabajo permanece sumando las estimaciones del backlog de cada da del Sprint. La cantidad de trabajo remanente para un Sprint es la suma del trabajo remanente para todo el Sprint Backlog. Mantenga seguimiento de estas sumas da a da y uselas para crear un grfico que muestre el trabajo remanente en el tiempo. Dibujando una lnea a travs de los puntos en el grfico, el Equipo puede gestionar su avance en completar el trabajo del Sprint. La duracin no se considera en Scrum. El trabajo remanente y la fecha son las nicas variables de inters. Consejo Siempre que sea posible, dibuje a mano el grfico burndown en una hoja de papel grande y mustrela en el rea de trabajo del Equipo. Los Equipos prefieren ver un grfico grande, visible en vez de ver el grfico Sprint burndown en excel o en una herramienta. Una de las reglas del Scrum se refiere al propsito de cada Sprint, que es entregar incrementos de funcionalidad potencialmente entregable que se adhiere a una definicion de trabajo de "listo". Listo (Done)

67 Sprint Backlog Burndown is a graph of the amount of Sprint Backlog work remaining in a Sprint across time in the Sprint. To create this graph, determine how much work remains by summing the backlog estimates every day of the Sprint. The amount of work remaining for a Sprint is the sum of the work remaining for all of Sprint Backlog. Keep track of these sums by day and use them to create a graph that shows the work remaining over time. By drawing a line through the points on the graph, the Team can manage its progress in completing a Sprints work. Duration is not considered in Scrum. Work remaining and date are the only variables of interest.

Tip 68 Whenever possible, hand draw the burndown chart on a big sheet of paper displayed in the Team's work area. Teams are more likely to see a big, visible chart than they are to look at Sprint burndown chart in Excel or a tool. 69 One of Scrum's rules pertains to the purpose of each Sprint, which is to deliver increments of potentially shippable functionality that adheres to a working definition of done. Done

70 Scrum requires Teams to build an increment of product functionality every Sprint. This increment must be potentially shippable, for Product Owner may choose to immediately implement the functionality. To do so, the increment must be a complete slice of the product. It must be done. Each increment should be additive to all prior increments and thoroughly tested, ensuring that all increments work together.

El Scrum requiere que el Equipo construya un incremento de la funcionalidad del producto cada Sprint. Este incremento debe ser potencialmente entregable, el Product Owner puede elegir implementar inmediatamente la funcionaldad. Para hacer esto, el incremento debe ser una porcin completa del producto. Debe estar "listo" ("hecho"). Cada incremento debera ser adicional a los incrementos previos y completamente probado, asegurando que todos los incrementos trabajan juntos {integrados}. 71 In product development, asserting that functionality is done might lead someone to assume that it is En el desarrollo de productos, afirmar que la funcionalidad est hecha puede hacer que alguien at least cleanly coded, refactored, unit tested, built, and acceptance tested. Someone else might asuma que al menos es cdigo limpio, refactorizado, probado unitariamente, construido y con assume only that the code has been built. If everyone doesnt know what the definition of done is, pruebas de aceptacin exitosas. Alguien ms puede asumir que slo se ha construido el cdigo. Si the other two legs of empirical process control dont work. When someone describes something as nadie conoce cul es la definicin de "listo", las otras dos piernas del control emprico de proceso no funcionan. Cuando alguien describe que algo est hecho, todos deben comprender qu significa done, everyone must understand what done means. hecho (listo). 72 Done defines what the Team means when it commits to doing a Product Backlog item in a Sprint. Listo define lo que el Equipo dice cuando se compromete con "hacer" un tem del Product Backlog Some products do not contain documentation, so the definition of done does not include en un Sprint. Algunos productos no contienen documentacin, de modo que la definicin de "listo" documentation. A completely done increment includes all of the analysis, design, refactoring, no incluye documentacin. Un incremento completo "listo" incluye todo el anlisis, diseo, programming, documentation and testing for the increment and all Product Backlog items in the refactoring, programacin, documentacin y pruebas para el incremento y todos los items den increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests Product Backlog en el incremento. Las pruebas incluyen pruebas unitarias, pruebas de sistema, such as performance, stability, security, and integration. Done includes any internationalization. pruebas de usuario y pruebas de regresin, as como las pruebas no funcionales tales como tiempo Some Teams arent yet able to include everything required for implementation in their definition of de respuesta, estabilidad, seguridad e integracin. Listo incluye cualquier internacionalizacin. done. This must be clear to the Product Owner. This remaining work will have to be done before the Algunos Equipos aun no son capaces de incluir todo lo requerido para la implementacin en su product can be implemented and used. definicin de listo. Esto debe estar claro para el Product Owner. Este trabajo remanente tendr que ser hecho antes que el producto puede implementarse y usarse. Tip 73 Undone work is often accumulated in a Product Backlog item called Undone Work or Implementation Work. As this work accumulates, the Product Backlog burndown remains more accurate than if it werent accumulated. 74 Some organizations are incapable of building a complete increment within one Sprint. They may not yet have the automated testing infrastructure to complete all of the testing. In this case, two categories are created for each increment: the done work and the undone work. The undone work is the portion of each increment that will have to be completed at a later time. The Product Owner knows exactly what he or she is inspecting at the end of the Sprint because the increment meets the definition of done and the Product Owner understands the definition. Undone work is added to a Product Backlog item named undone work so it accumulates and correctly reflects on the Release Burndown graph. This technique creates transparency in progress toward a release. The inspect and adapt in the Sprint Review is as accurate as this transparency. 75 For instance, if a Team is not able to do performance, regression, stability, security, and integration testing for each Product Backlog item, the proportion of this work to the work that can be done (analysis, design, refactoring, programming, documentation, unit and user testing) is calculated. Lets say that this proportion is six pieces of done and four pieces on undone. If the Team finishes a Product Backlog item of six units of work (the Team is estimating based on what it knows how to do), four is added to the undone work Product Backlog item when they are finished. Consejo El trabajo "no listo" frecuentemente se acumula en un tem del Product Backlog llamado "Trabajo No Listo" "Trabajo de Implementacin". Conforme este trabajo se acumule, el Product Backlog burndown es ms preciso que si no se acumula. Algunas organizaciones son incapaces de construir un incremento completo dentro de un Sprint. Pueden no tener an la infraestructura de pruebas automatizadas para completar todas las pruebas. En este caso, se crean dos categoras para cada incremento: el trabajo "listo" y el trabajo "no listo". El trabajo "no listo" es la porcin de cada incremento que tendr que completarse posteriormente. El Product Owner sabe exactamente lo que est inspeccionando al final del Sprint porque el incremento satisface la definicin de "listo" y el Product Owner comprende la definicin. El trabajo "no listo" se agrega al tem del Product Backlog denominado "trabajo no listo", se acumula y se refleja correctamente en el grfico Release Burndown. Esta tcnica crea transparencia en el avance hacia un release. La inspeccin y adaptacin en el Sprint Review es precisa y transparente. Por ejemplo, si un Equipo no es capaz de realizar pruebas de tiempo de respuesta, regresin, estabilidad, seguridad e integracin para cada tem del Product Backlog, se calcula la proporcin de este trabajo con respecto al trabajo que puede hacerse (anlisis, diseo, refactoring, programacin, documentacin, pruebas unitarias y pruebas de usuario). Digamos que esta proporcin es seis pedazos de "listo" y cuatro pedazos en "no listo". Si el Equipo termina un item del Product Backlog de seis unidades de trabajo (el Equipo est estimando en base a lo que conoce cmo "hacer"), cuatro se agregan al tem "trabajo no listo" del Product Backlog cuando se terminan. De Sprint en Sprint, el trabajo "no listo" de cada incremento se acumula y debe resolverse antes de la libreacin del producto. Est trabajo se acumula linealmente aun cuando realmente hay alguna suerte de acumulacin exponencial que depende de las caractersticas de cada organizacin. Sprints de libreacin se agregan al final de cualquier release para completar este trabajo "no listo". El nmero de Sprints es impredecible en la medida que la acumulacin del trabajo "no listo" no es lineal.

76 Sprint by Sprint, the undone work of each increment is accumulated and must be addressed prior to releasing the product. This work is accumulated linearly although it actually has some sort of exponential accumulation that is dependent on each organizations characteristics. Release Sprints are added to the end of any release to complete this undone work. The number of Sprints is unpredictable to the degree that the accumulation of undone work is not linear.