La Gu铆a de Scrum
La Gu铆a Definitiva de Scrum: Las Reglas del Juego
Ken Schwaber & Jeff Sutherland
Noviembre de 2020
Prop贸sito de la Gu铆a Scrum
Desarrollamos Scrum a principios de la d茅cada de 1990. Escribimos la primera versi贸n de la Gu铆a Scrum en 2010 para ayudar a las personas de todo el mundo a comprender Scrum. Hemos desarrollado la Gu铆a desde entonces a trav茅s de peque帽as actualizaciones funcionales. Juntos, la respaldamos.
La Gu铆a de Scrum contiene la definici贸n de Scrum. Cada elemento del marco de trabajo tiene un prop贸sito espec铆fico que es esencial para el valor general y los resultados obtenidos con Scrum. Cambiar el dise帽o o las ideas esenciales de Scrum, omitir elementos o no seguir las reglas de Scrum, oculta los problemas y limita los beneficios de Scrum, e incluso potencialmente lo vuelve in煤til.
Seguimos el uso creciente de Scrum dentro de un mundo complejo en constante crecimiento. Nos sentimos honrados de ver que Scrum est谩 siendo adoptado en muchos dominios que tienen un trabajo esencialmente complejo, m谩s all谩 del desarrollo de productos de software donde Scrum tiene sus ra铆ces. A medida que se extiende el uso de Scrum, los desarrolladores, investigadores, analistas, cient铆ficos y otros especialistas hacen el trabajo. Usamos la palabra "desarrolladores" en Scrum no para excluir, sino para simplificar. Si obtiene valor de Scrum, consid茅rese incluido.
A medida que se utiliza Scrum, se pueden encontrar, aplicar y dise帽ar patrones, procesos y enfoques que se ajusten al marco de trabajo Scrum como se describe en este documento. Su descripci贸n va m谩s all谩 del prop贸sito de la Gu铆a Scrum porque son sensibles al contexto y difieren ampliamente entre los usos de Scrum. Tales t谩cticas para usar dentro del marco de trabajo Scrum var铆an ampliamente y se describen en otra parte.
Ken Schwaber y Jeff Sutherland, Noviembre de 2020
漏 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share鈥怉like license of Creative Commons, accessible at http://creativecommons.org/licenses/by鈥恠a/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by鈥恠a/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share鈥怉like license of Creative Commons.
Tabla de Contenidos
- La Gu铆a de Scrum
- La Gu铆a Definitiva de Scrum: Las Reglas del Juego
- Prop贸sito de la Gu铆a Scrum
- Tabla de Contenidos
- Definici贸n de Scrum
- Teor铆a de Scrum
- Valores de Scrum
- Scrum Team
- Eventos de Scrum
- Artefactos de Scrum
- Nota final
- Agradecimientos
- Cambios de la Gu铆a Scrum 2017 a la Gu铆a Scrum 2020
- A煤n menos prescriptiva
- Un equipo, enfocado en un producto
- Introducci贸n del Objetivo del Producto
- Un hogar para el Objetivo del Sprint, la Definici贸n de Terminado y el Objetivo del Producto
- Autogesti贸n sobre autoorganizaci贸n
- Tres temas de la Sprint Planning
- Simplificaci贸n general del lenguaje para una audiencia m谩s amplia
Definici贸n de Scrum
Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a trav茅s de soluciones adaptativas para problemas complejos.
En pocas palabras, Scrum requiere un Scrum Master para fomentar un entorno donde:
- Un Product Owner ordena el trabajo de un problema complejo en un Product Backlog.
- El Scrum Team convierte una selecci贸n del trabajo en un Increment de valor durante un Sprint.
- El Scrum Team y sus interesados inspeccionan los resultados y se adaptan para el pr贸ximo Sprint.
- Repita
Scrum es simple. Pru茅belo como est谩 y determine si su filosof铆a, teor铆a y estructura ayudan a lograr objetivos y crear valor. El marco de trabajo Scrum es incompleto de manera intencional, solo define las partes necesarias para implementar la teor铆a de Scrum. Scrum se basa en la inteligencia colectiva de las personas que lo utilizan. En lugar de proporcionar a las personas instrucciones detalladas, las reglas de Scrum gu铆an sus relaciones e interacciones.
En este marco de trabajo pueden emplearse varios procesos, t茅cnicas y m茅todos. Scrum envuelve las pr谩cticas existentes o las hace innecesarias. Scrum hace visible la eficacia relativa de las t茅cnicas actuales de gesti贸n, entorno y trabajo, de modo que se puedan realizar mejoras.
Teor铆a de Scrum
Scrum se basa en el empirismo y el pensamiento Lean. El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado. El pensamiento Lean reduce el desperdicio y se enfoca en lo esencial.
Scrum emplea un enfoque iterativo e Incremental para optimizar la previsibilidad y controlar el riesgo. Scrum involucra a grupos de personas que colectivamente tienen todas las habilidades y experiencia para hacer el trabajo y compartir o adquirir dichas habilidades seg煤n sea necesario.
Scrum combina cuatro eventos formales para inspecci贸n y adaptaci贸n dentro de un evento contenedor, el Sprint. Estos eventos funcionan porque implementan los pilares emp铆ricos de Scrum de transparencia, inspecci贸n y adaptaci贸n.
Transparencia
El proceso y el trabajo emergentes deben ser visibles tanto para quienes realizan el trabajo como para quienes lo reciben. Con Scrum, las decisiones importantes se basan en el estado percibido de sus tres artefactos formales. Los artefactos que tienen poca transparencia pueden llevar a decisiones que disminuyan el valor y aumenten el riesgo.
La transparencia permite la inspecci贸n. La inspecci贸n sin transparencia es enga帽osa y derrochadora.
Inspecci贸n
Los artefactos de Scrum y el progreso hacia los objetivos acordados deben inspeccionarse con frecuencia y con diligencia para detectar variaciones o problemas potencialmente indeseables. Para ayudar con la inspecci贸n, Scrum proporciona cadencia en forma de sus cinco eventos.
La inspecci贸n permite la adaptaci贸n. La inspecci贸n sin adaptaci贸n se considera in煤til. Los eventos Scrum est谩n dise帽ados para provocar cambios.
Adaptaci贸n
Si alg煤n aspecto de un proceso se desv铆a fuera de los l铆mites aceptables o si el producto resultante es inaceptable, el proceso que se aplica o los materiales que se producen deben ajustarse. El ajuste debe realizarse lo antes posible para minimizar una mayor desviaci贸n.
La adaptaci贸n se vuelve m谩s dif铆cil cuando las personas involucradas no est谩n empoderadas ni se autogestionan. Se espera que un Scrum Team se adapte en el momento en que aprenda algo nuevo a trav茅s de la inspecci贸n.
Valores de Scrum
El uso exitoso de Scrum depende de que las personas se vuelvan m谩s competentes en vivir cinco valores:
Compromiso, Foco, Franqueza, Respeto y Coraje
El Scrum Team se compromete a lograr sus objetivos y a apoyarse mutuamente. Su foco principal est谩 en el trabajo del Sprint para lograr el mejor progreso posible hacia estos objetivos. El Scrum Team y sus interesados son francos sobre el trabajo y los desaf铆os. Los miembros del Scrum Team se respetan entre s铆 para ser personas capaces e independientes, y son respetados como tales por las personas con las que trabajan. Los miembros del Scrum Team tienen el coraje de hacer lo correcto, para trabajar en problemas dif铆ciles.
Estos valores dan direcci贸n al Scrum Team con respecto a su trabajo, acciones y comportamiento. Las decisiones que se tomen, los pasos que se den y la forma en que se use Scrum deben reforzar estos valores, no disminuirlos ni socavarlos. Los miembros del Scrum Team aprenden y exploran los valores mientras trabajan con los eventos y artefactos Scrum. Cuando el Scrum Team y las personas con las que trabajan incorporan estos valores, los pilares emp铆ricos de Scrum de transparencia, inspecci贸n y adaptaci贸n cobran vida y generan confianza.
Scrum Team
La unidad fundamental de Scrum es un peque帽o equipo de personas, un Scrum Team. El Scrum Team consta de un Scrum Master, un Product Owner y Developers. Dentro de un Scrum Team, no hay subequipos ni jerarqu铆as. Es una unidad cohesionada de profesionales enfocados en un objetivo a la vez, el Objetivo del Producto.
Los Scrum Teams son multifuncionales, lo que significa que los miembros tienen todas las habilidades necesarias para crear valor en cada Sprint. Tambi茅n se autogestionan, lo que significa que deciden internamente qui茅n hace qu茅, cu谩ndo y c贸mo.
El Scrum Team es lo suficientemente peque帽o como para seguir siendo 谩gil y lo suficientemente grande como para completar un trabajo significativo dentro de un Sprint, generalmente 10 personas o menos. En general, hemos descubierto que los equipos m谩s peque帽os se comunican mejor y son m谩s productivos. Si los Scrum Teams se vuelven demasiado grandes, deber铆an considerar reorganizarse en m煤ltiples Scrum Teams cohesivos, cada uno enfocado en el mismo producto. Por lo tanto, deben compartir el mismo Objetivo del Producto, el Product Backlog y el Product Owner.
El Scrum Team es responsable de todas las actividades relacionadas con el producto, desde la colaboraci贸n de los interesados, la verificaci贸n, el mantenimiento, la operaci贸n, la experimentaci贸n, la investigaci贸n y el desarrollo, y cualquier otra cosa que pueda ser necesaria. Est谩n estructurados y empoderados por la organizaci贸n para gestionar su propio trabajo. Trabajar en Sprints a un ritmo sostenible mejora el enfoque y la consistencia del Scrum Team.
Todo el Scrum Team es responsable de crear un Increment valioso y 煤til en cada Sprint. Scrum define tres responsabilidades espec铆ficas dentro del Scrum Team: los Developers, el Product Owner y el Scrum Master.
Developers
Las personas del Scrum Team que se comprometen a crear cualquier aspecto de un Increment utilizable en cada Sprint son Developers.
Las habilidades espec铆ficas que necesitan los Developers suelen ser amplias y variar谩n seg煤n el 谩mbito de trabajo. Sin embargo, los Developers siempre son responsables de:
- Crear un plan para el Sprint, el Sprint Backlog;
- Inculcar calidad al adherirse a una Definici贸n de Terminado;
- Adaptar su plan cada d铆a hacia el Objetivo del Sprint; y,
- Responsabilizarse mutuamente como profesionales.
Product Owner
El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del Scrum Team. La forma en que esto se hace puede variar ampliamente entre organizaciones, Scrum Teams e individuos.
El Product Owner tambi茅n es responsable de la gesti贸n efectiva del Product Backlog, lo que incluye:
- Desarrollar y comunicar expl铆citamente el Objetivo del Producto;
- Crear y comunicar claramente los elementos del Product Backlog;
- Ordenar los elementos del Product Backlog; y,
- Asegurarse de que el Product Backlog sea transparente, visible y se entienda.
El Product Owner puede realizar el trabajo anterior o puede delegar la responsabilidad en otros. Independientemente de ello, el Product Owner sigue siendo el responsable de que el trabajo se realice.
Para que los Product Owners tengan 茅xito, toda la organizaci贸n debe respetar sus decisiones. Estas decisiones son visibles en el contenido y el orden del Product Backlog, y a trav茅s del Increment inspeccionable en la Sprint Review.
El Product Owner es una persona, no un comit茅. El Product Owner puede representar las necesidades de muchos interesados en el Product Backlog. Aquellos que quieran cambiar el Product Backlog pueden hacerlo intentando convencer al Product Owner.
Scrum Master
El Scrum Master es responsable de establecer Scrum como se define en la Gu铆a de Scrum. Lo hace ayudando a todos a comprender la teor铆a y la pr谩ctica de Scrum, tanto dentro del Scrum Team como de la organizaci贸n.
El Scrum Master es responsable de lograr la efectividad del Scrum Team. Lo hace apoyando al Scrum Team en la mejora de sus pr谩cticas, dentro del marco de trabajo de Scrum.
Los Scrum Masters son verdaderos l铆deres que sirven al Scrum Team y a la organizaci贸n en general.
El Scrum Master sirve al Scrum Team de varias maneras, que incluyen:
- Guiar a los miembros del equipo en ser autogestionados y multifuncionales;
- Ayudar al Scrum Team a enfocarse en crear Increments de alto valor que cumplan con la Definici贸n de Terminado;
- Procurar la eliminaci贸n de impedimentos para el progreso del Scrum Team; y,
- Asegurarse de que todos los eventos de Scrum se lleven a cabo y sean positivos, productivos y se mantengan dentro de los l铆mites de tiempo recomendados en esta Gu铆a.
El Scrum Master sirve al Product Owner de varias maneras, que incluyen:
- Ayudar a encontrar t茅cnicas para una definici贸n efectiva de Objetivos del Producto y la gesti贸n del Product Backlog;
- Ayudar al Scrum Team a comprender la necesidad de tener elementos del Product Backlog claros y concisos;
- Ayudar a establecer una planificaci贸n emp铆rica de productos para un entorno complejo; y,
- Facilitar la colaboraci贸n de los interesados seg煤n se solicite o necesite.
El Scrum Master sirve a la organizaci贸n de varias maneras, que incluyen:
- Liderar, capacitar y guiar a la organizaci贸n en su adopci贸n de Scrum;
- Planificar y asesorar implementaciones de Scrum dentro de la organizaci贸n;
- Ayudar a los empleados y los interesados a comprender y aplicar un enfoque emp铆rico para el trabajo complejo; y,
- Eliminar las barreras entre los interesados y los Scrum Teams.
Eventos de Scrum
El Sprint es un contenedor para todos los dem谩s eventos. Cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar los artefactos Scrum. Estos eventos est谩n dise帽ados espec铆ficamente para habilitar la transparencia requerida. No operar cualquier evento seg煤n lo prescrito resulta en la p茅rdida de oportunidades para inspeccionar y adaptarse. Los eventos se utilizan en Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum.
Lo 贸ptimo es que todos los eventos se celebren al mismo tiempo y en el mismo lugar para reducir la complejidad.
El Sprint
Los Sprints son el coraz贸n de Scrum, donde las ideas se convierten en valor.
Son eventos de duraci贸n fija de un mes o menos para crear consistencia. Un nuevo Sprint comienza inmediatamente despu茅s de la conclusi贸n del Sprint anterior.
Todo el trabajo necesario para lograr el Objetivo del Producto, incluido la Sprint Planning, Daily Scrums, Sprint Review y Sprint Retrospective, ocurre dentro de los Sprints.
Durante el Sprint:
- No se realizan cambios que pongan en peligro el Objetivo del Sprint;
- La calidad no disminuye;
- El Product Backlog se refina seg煤n sea necesario; y,
- El alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende m谩s.
Los Sprints permiten la previsibilidad al garantizar la inspecci贸n y adaptaci贸n del progreso hacia un Objetivo del Producto al menos cada mes calendario. Cuando el horizonte de un Sprint es demasiado largo, el Objetivo del Sprint puede volverse inv谩lido, la complejidad puede crecer y el riesgo puede aumentar. Se pueden emplear Sprints m谩s cortos para generar m谩s ciclos de aprendizaje y limitar el riesgo de costo y esfuerzo a un per铆odo de tiempo menor. Cada Sprint puede considerarse un proyecto corto.
Existen varias pr谩cticas para pronosticar el progreso, como el trabajo pendiente (burn鈥恉owns), trabajo completado (burn鈥恥ps) o flujos acumulativos (cumulative flows). Si bien han demostrado su utilidad, no reemplazan la importancia del empirismo. En entornos complejos, se desconoce lo que suceder谩. Solo lo que ya ha sucedido se puede utilizar para la toma de decisiones con miras al futuro.
Un Sprint podr铆a cancelarse si el Objetivo del Sprint se vuelve obsoleto. Solo el Product Owner tiene la autoridad para cancelar el Sprint.
Sprint Planning
La Sprint Planning inicia el Sprint al establecer el trabajo que se realizar谩 para el Sprint. El Scrum Team crea este plan resultante mediante trabajo colaborativo.
El Product Owner se asegura de que los asistentes est茅n preparados para discutir los elementos m谩s importantes del Product Backlog y c贸mo se relacionan con el Objetivo del Producto. El Scrum Team tambi茅n puede invitar a otras personas a asistir a la Sprint Planning para brindar asesoramiento.
La Sprint Planning aborda los siguientes temas:
Tema uno: 驴Por qu茅 es valioso este Sprint?
El Product Owner propone c贸mo el producto podr铆a Incrementar su valor y utilidad en el Sprint actual. Luego, todo el Scrum Team colabora para definir un Objetivo del Sprint que comunica por qu茅 el Sprint es valioso para los interesados. El Objetivo del Sprint debe completarse antes de que termine la Sprint Planning.
Tema dos: 驴Qu茅 se puede hacer en este Sprint?
A trav茅s de una conversaci贸n con el Product Owner, los Developers seleccionan elementos del Product Backlog para incluirlos en el Sprint actual. El Scrum Team puede refinar estos elementos durante este proceso, lo que aumenta la comprensi贸n y la confianza.
Seleccionar cu谩nto se puede completar dentro de un Sprint puede ser un desaf铆o. Sin embargo, cuanto m谩s sepan los Developers sobre su desempe帽o pasado, su capacidad actual y su Definici贸n de Terminado, m谩s confiados estar谩n en sus pron贸sticos para el Sprint.
Tema tres: 驴C贸mo se realizar谩 el trabajo elegido?
Para cada elemento del Product Backlog seleccionado, los Developers planifican el trabajo necesario para crear un Increment que cumpla con la Definici贸n de Terminado. A menudo, esto se hace descomponiendo los elementos del Product Backlog en elementos de trabajo m谩s peque帽os de un d铆a o menos. La forma de hacerlo queda a criterio exclusivo de los Developers. Nadie m谩s les dice c贸mo convertir los elementos del Product Backlog en Increments de valor.
El Objetivo del Sprint, los elementos del Product Backlog seleccionados para el Sprint, m谩s el plan para entregarlos se denominan juntos Sprint Backlog.
La Sprint Planning tiene un l铆mite de tiempo de m谩ximo ocho horas para un Sprint de un mes. Para Sprints m谩s cortos, el evento suele ser de menor duraci贸n.
Daily Scrum
El prop贸sito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog seg煤n sea necesario, ajustando el trabajo planificado entrante.
La Daily Scrum es un evento de 15 minutos para los Developers del Scrum Team. Para reducir la complejidad, se lleva a cabo a la misma hora y en el mismo lugar todos los d铆as h谩biles del Sprint. Si el Product Owner o Scrum Master est谩n trabajando activamente en elementos del Sprint Backlog, participan como Developers.
Los Developers pueden seleccionar la estructura y las t茅cnicas que deseen, siempre que su Daily Scrum se centre en el progreso hacia el Objetivo del Sprint y produzca un plan viable para el siguiente d铆a de trabajo. Esto crea enfoque y mejora la autogesti贸n.
Las Daily Scrums mejoran la comunicaci贸n, identifican impedimentos, promueven la toma r谩pida de decisiones y, en consecuencia, eliminan la necesidad de otras reuniones.
La Daily Scrum no es el 煤nico momento en el que los Developers pueden ajustar su plan. A menudo se re煤nen durante el d铆a para discusiones m谩s detalladas sobre c贸mo adaptar o volver a planificar el resto del trabajo del Sprint.
Sprint Review
El prop贸sito de la Sprint Review es inspeccionar el resultado del Sprint y determinar futuras adaptaciones. El Scrum Team presenta los resultados de su trabajo a los interesados clave y se discute el progreso hacia el Objetivo del Producto.
Durante el evento, el Scrum Team y los interesados revisan lo que se logr贸 en el Sprint y lo que ha cambiado en su entorno. Con base en esta informaci贸n, los asistentes colaboran sobre qu茅 hacer a continuaci贸n. El Product Backlog tambi茅n se puede ajustar para satisfacer nuevas oportunidades. La Sprint Review es una sesi贸n de trabajo y el Scrum Team debe evitar limitarla a una presentaci贸n.
La Sprint Review es el pen煤ltimo evento del Sprint y tiene un l铆mite de tiempo de m谩ximo cuatro horas para un Sprint de un mes. Para Sprints m谩s cortos, el evento suele ser de menor duraci贸n.
Sprint Retrospective
El prop贸sito de la Sprint Retrospective es planificar formas de aumentar la calidad y la efectividad.
El Scrum Team inspecciona c贸mo fue el 煤ltimo Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definici贸n de Terminado. Los elementos inspeccionados suelen variar seg煤n el 谩mbito del trabajo. Se identifican los supuestos que los llevaron por mal camino y se exploran sus or铆genes. El Scrum Team analiza qu茅 sali贸 bien durante el Sprint, qu茅 problemas encontr贸 y c贸mo se resolvieron (o no) esos problemas.
El Scrum Team identifica los cambios m谩s 煤tiles para mejorar su efectividad. Las mejoras m谩s impactantes se abordan lo antes posible. Incluso se pueden agregar al Sprint Backlog para el pr贸ximo Sprint.
La Sprint Retrospective concluye el Sprint. Tiene un tiempo limitado a m谩ximo tres horas para un Sprint de un mes. Para Sprints m谩s cortos, el evento suele ser de menor duraci贸n.
Artefactos de Scrum
Los artefactos de Scrum representan trabajo o valor. Est谩n dise帽ados para maximizar la transparencia de la informaci贸n clave. Por lo tanto, todas las personas que los inspeccionan tienen la misma base de adaptaci贸n.
Cada artefacto contiene un compromiso para garantizar que proporcione informaci贸n que mejore la transparencia y el enfoque frente al cual se pueda medir el progreso:
- Para el Product Backlog, es el Objetivo del Producto.
- Para el Sprint Backlog, es el Objetivo del Sprint.
- Para el Increment es la Definici贸n de Terminado.
Estos compromisos existen para reforzar el empirismo y los valores de Scrum para el Scrum Team y sus interesados.
Product Backlog
El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la 煤nica fuente del trabajo realizado por el Scrum Team.
Los elementos del Product Backlog que el Scrum Team puede dar por Terminados dentro de un Sprint se consideran preparados para ser seleccionados en un evento de Sprint Planning. Suelen adquirir este grado de transparencia tras las actividades de refinamiento. El refinamiento del Product Backlog es el acto de dividir y definir a煤n m谩s los elementos del Product Backlog en elementos m谩s peque帽os y precisos. Esta es una actividad continua para agregar detalles, como una descripci贸n, orden y tama帽o. Los atributos suelen variar seg煤n el 谩mbito del trabajo.
Los Developers que realizar谩n el trabajo son responsables del dimensionamiento. El Product Owner puede influir en los Developers ayud谩ndolos a entender y seleccionar sus mejores alternativas.
Compromiso: Objetivo del Producto
El Objetivo del Producto describe un estado futuro del producto que puede servir como un objetivo para que el Scrum Team planifique. El Objetivo del Producto est谩 en el Product Backlog. El resto del Product Backlog emerge para definir "qu茅" cumplir谩 con el Objetivo del Producto.
Un producto es un veh铆culo para entregar valor. Tiene un l铆mite claro, personas interesadas conocidas, usuarios o clientes bien definidos. Un producto puede ser un servicio, un producto f铆sico o algo m谩s abstracto.
El Objetivo del Producto es el objetivo a largo plazo del Scrum Team. Ellos deben cumplir (o abandonar) un objetivo antes de asumir el siguiente.
Sprint Backlog
El Sprint Backlog se compone del Objetivo del Sprint (por qu茅), el conjunto de elementos del Product Backlog seleccionados para el Sprint (qu茅), as铆 como un plan de acci贸n para entregar el Increment (c贸mo).
El Sprint Backlog es un plan realizado por y para los Developers. Es una imagen muy visible y en tiempo real del trabajo que los Developers planean realizar durante el Sprint para lograr el Objetivo del Sprint. En consecuencia, el Sprint Backlog se actualiza a lo largo del Sprint a medida que se aprende m谩s. Debe tener suficientes detalles para que puedan inspeccionar su progreso en la Daily Scrum.
Compromiso: Objetivo del Sprint
El Objetivo del Sprint es el 煤nico prop贸sito del Sprint. Si bien el Objetivo del Sprint es un compromiso de los Developers, proporciona flexibilidad en t茅rminos del trabajo exacto necesario para lograrlo. El Objetivo del Sprint tambi茅n crea coherencia y enfoque, lo que alienta al Scrum Team a trabajar en conjunto en lugar de en iniciativas separadas.
El Objetivo del Sprint se crea durante el evento Sprint Planning y se agrega al Sprint Backlog. Mientras los Developers trabajan durante el Sprint, tienen en mente el Objetivo del Sprint. Si el trabajo resulta ser diferente de lo que esperaban, colaboran con el Product Owner para negociar el alcance del Sprint Backlog dentro del Sprint sin afectar el Objetivo del Sprint.
Increment
Un Increment es un pelda帽o concreto hacia el Objetivo del Producto. Cada Increment se suma a todos los Increments anteriores y se verifica minuciosamente, lo que garantiza que todos los Increments funcionen juntos. Para proporcionar valor, el Increment debe ser utilizable.
Se pueden crear m煤ltiples Increments dentro de un Sprint. La suma de los Increments se presenta en la Sprint Review apoyando as铆 el empirismo. Sin embargo, se puede entregar un Increment a los interesados antes del final del Sprint. La Sprint Review nunca debe considerarse una puerta para liberar valor.
El trabajo no puede considerarse parte de un Increment a menos que cumpla con la Definici贸n de Terminado.
Compromiso: Definici贸n de Terminado
La Definici贸n de Terminado es una descripci贸n formal del estado del Increment cuando cumple con las medidas de calidad requeridas para el producto.
En el momento en que un elemento del Product Backlog cumple con la Definici贸n de Terminado, nace un Increment.
La Definici贸n de Terminado crea transparencia al brindar a todos un entendimiento compartido de qu茅 trabajo se complet贸 como parte del Increment. Si un elemento del Product Backlog no cumple con la Definici贸n de Terminado, no se puede publicar ni presentar en la Sprint Review. En su lugar, vuelve al Product Backlog para su consideraci贸n futura.
Si la Definici贸n de Terminado para un Increment es parte de los est谩ndares de la organizaci贸n, todos los Scrum Teams deben seguirla como m铆nimo. Si no es un est谩ndar organizacional, el Scrum Team debe crear una Definici贸n de Terminado apropiada para el producto.
Los Developers deben adherirse a la Definici贸n de Terminado. Si hay varios Scrum Teams trabajando juntos en un producto, deben definir y cumplir mutuamente la misma Definici贸n de Terminado.
Nota final
Scrum es gratuito y se ofrece en esta Gu铆a. El marco de trabajo Scrum, como se describe aqu铆, es inmutable. Si bien es posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum existe solo en su totalidad y funciona bien como un contenedor para otras t茅cnicas, metodolog铆as y pr谩cticas.
Agradecimientos
Personas
De los miles de personas que han contribuido a Scrum, debemos destacar a las que fueron fundamentales al principio: Jeff Sutherland trabaj贸 con Jeff McKenna y John Scumniotales, y Ken Schwaber trabaj贸 con Mike Smith y Chris Martin, y todos ellos trabajaron juntos. Muchos otros contribuyeron en los a帽os siguientes y sin su ayuda Scrum no estar铆a refinado como lo est谩 hoy.
Historia de la Gu铆a de Scrum
Ken Schwaber y Jeff Sutherland copresentaron Scrum por primera vez en la Conferencia OOPSLA en 1995. B谩sicamente, document贸 el aprendizaje que Ken y Jeff adquirieron en los a帽os anteriores y public贸 la primera definici贸n formal de Scrum.
La Gu铆a de Scrum documenta Scrum como se ha desarrollado, evolucionado y sostenido durante m谩s de 30 a帽os por Jeff Sutherland y Ken Schwaber. Otras fuentes proporcionan patrones, procesos y enfoques que complementan el marco de trabajo Scrum. Estos pueden aumentar la productividad, el valor, la creatividad y la satisfacci贸n con los resultados.
La historia completa de Scrum se describe en otros lugares. Para honrar los primeros sitios donde se prob贸 y comprob贸, reconocemos a Individual Inc., Newspage, Fidelity Investments e IDX (ahora GE Medical).
Traducci贸n
Esta gu铆a ha sido traducida de la versi贸n original en ingl茅s proporcionada por Ken Schwaber y Jeff Sutherland. Las personas que han contribuido en la traducci贸n son: Marcelo L贸pez, Marcelo Garc铆a, Jorge Abad, Fabian Schwartz y Lucho Salazar.
Informaci贸n de contacto:
- Nombre: Lucho Salazar
- Correo electr贸nico: lucho.salazar@gmail.com
- Sitio Web: http://www.gazafatonarioit.com
- LinkedIn: http://www.linkedin.com/in/luchosalazar
Cambios de la Gu铆a Scrum 2017 a la Gu铆a Scrum 2020
A煤n menos prescriptiva
A lo largo de los a帽os, la Gu铆a Scrum comenz贸 a ser un poco m谩s prescriptiva. La versi贸n 2020 ten铆a como objetivo que Scrum volviera a ser un marco de trabajo m铆nimamente suficiente al eliminar o suavizar el lenguaje prescriptivo. Por ejemplo, elimin贸 las preguntas de la Daily Scrum, suaviz贸 el lenguaje sobre los atributos de los PBI, suaviz贸 el lenguaje sobre los elementos retro en el Sprint Backlog, acort贸 la secci贸n de cancelaci贸n de Sprint y m谩s.
Un equipo, enfocado en un producto
El objetivo era eliminar el concepto de un equipo separado dentro de un equipo que ha llevado a un comportamiento de "proxy" o de "nosotros y ellos" entre el PO y el Equipo de Desarrollo. Ahora solo hay un Scrum Team enfocado en el mismo objetivo, con tres diferentes conjuntos de responsabilidades: PO, SM y Developers.
Introducci贸n del Objetivo del Producto
La Gu铆a Scrum 2020 introduce el concepto de Objetivo del Producto para proporcionar enfoque al Scrum Team hacia un objetivo valioso m谩s grande. Cada Sprint deber铆a acercar el producto al Objetivo del Producto general.
Un hogar para el Objetivo del Sprint, la Definici贸n de Terminado y el Objetivo del Producto
Las Gu铆as Scrum anteriores describ铆an el Objetivo del Sprint y la Definici贸n de Terminado sin realmente darles una identidad. No eran del todo artefactos, pero estaban algo unidos a los artefactos. Con la incorporaci贸n del Objetivo del Producto, la versi贸n 2020 proporciona m谩s claridad al respecto. Cada uno de los tres artefactos ahora contiene "compromisos" con ellos. Para el Product Backlog es el Objetivo del Producto, el Sprint Backlog tiene el Objetivo del Sprint y el Increment tiene la Definici贸n de Terminado (ahora sin las comillas). Existen para aportar transparencia y enfocarse en el progreso de cada artefacto.
Autogesti贸n sobre autoorganizaci贸n
Las Gu铆as Scrum anteriores se refer铆an a los Equipos de Desarrollo como autoorganizados, eligiendo qui茅n y c贸mo hacer el trabajo. Con un enfoque m谩s en el Scrum Team, la versi贸n 2020 enfatiza un Scrum Team autogestionado, eligiendo qui茅n, c贸mo y en qu茅 trabajar.
Tres temas de la Sprint Planning
Adem谩s de los temas de la Sprint Planning de "Qu茅" y "C贸mo", la Gu铆a de Scrum 2020 pone 茅nfasis en un tercer tema, "Por qu茅", en referencia al Objetivo del Sprint.
Simplificaci贸n general del lenguaje para una audiencia m谩s amplia
La Gu铆a Scrum 2020 ha hecho hincapi茅 en eliminar declaraciones redundantes y complejas, as铆 como en eliminar cualquier inferencia restante al trabajo de TI (por ejemplo, pruebas, sistema, dise帽o, requisito, etc.). La Gu铆a Scrum ahora tiene menos de 13 p谩ginas.