Esta versión HTML de la Guía Scrum es una copia directa de la versión de noviembre de 2020 disponible en PDF aquí.
- La Guía Scrum 2020™
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 entender Scrum. Desde entonces, hemos evolucionado la Guía a través de pequeñas actualizaciones funcionales. Juntos, la respaldamos.
La Guía 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 y los resultados generales logrados con Scrum. Cambiar el diseño central o las ideas de Scrum, omitir elementos o no seguir las reglas de Scrum, cubre problemas y limita los beneficios de Scrum, potencialmente hasta hacerlo inútil.
Seguimos el uso creciente de Scrum en un mundo cada vez más complejo. Nos sentimos honrados de ver a Scrum siendo adoptado en muchos dominios que manejan trabajo esencialmente complejo, más allá del desarrollo de productos de software donde Scrum tiene sus raíces. A medida que el uso de Scrum se expande, los desarrolladores, investigadores, analistas, científicos y otros especialistas realizan el trabajo. Utilizamos la palabra "desarrolladores" en Scrum no para excluir, sino para simplificar. Si obtienes valor de Scrum, considérate incluido.
A medida que se utiliza Scrum, pueden encontrarse, aplicarse y diseñarse patrones, procesos e ideas que se ajusten al marco de trabajo de Scrum tal como se describe en este documento. Su descripción está más allá del propósito de la Guía Scrum porque son contextuales y varían ampliamente entre los usos de Scrum. Tales tácticas para usar dentro del marco de trabajo de Scrum varían ampliamente y se describen en otros lugares.
Scrum es un marco de trabajo ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos.
En resumen, Scrum requiere un Scrum Master para fomentar un entorno donde:
- Un Product Owner ordena el trabajo para un problema complejo en un Product Backlog.
- El Scrum Team convierte una selección del trabajo en un Incremento de valor durante un Sprint.
- El Scrum Team y sus interesados inspeccionan los resultados y ajustan para el próximo Sprint.
- Repetir
Scrum es simple. Pruébalo tal como es y determina si su filosofía, teoría y estructura ayudan a alcanzar objetivos y crear valor. El marco de trabajo de Scrum es intencionalmente incompleto, definiendo solo las partes requeridas para implementar la teoría de Scrum. Scrum se construye sobre la inteligencia colectiva de las personas que lo usan. En lugar de proporcionar instrucciones detalladas, las reglas de Scrum guían sus relaciones e interacciones.
Varios procesos, técnicas y métodos pueden emplearse dentro del marco de trabajo. Scrum se adapta a prácticas existentes o las hace innecesarias. Scrum hace visible la eficacia relativa de las técnicas actuales de gestión, entorno y trabajo, para que se puedan realizar mejoras.
Scrum se basa en el empirismo y el pensamiento lean. El empirismo afirma que el conocimiento proviene de la experiencia y de tomar decisiones basadas en lo que se observa. 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 la experiencia para realizar el trabajo y comparten o adquieren tales habilidades según sea necesario.
Scrum combina cuatro eventos formales para la inspección y adaptación dentro de un evento contenedor, el Sprint. Estos eventos funcionan porque implementan los pilares empíricos de Scrum: transparencia, inspección y adaptación.
El proceso emergente y el trabajo deben ser visibles para quienes realizan el trabajo y para quienes reciben el trabajo. Con Scrum, las decisiones importantes se basan en el estado percibido de sus tres artefactos formales. Los artefactos con baja 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 desperdiciada.
Los artefactos de Scrum y el progreso hacia los objetivos acordados deben inspeccionarse frecuentemente y con diligencia para detectar variaciones o problemas 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 de Scrum están diseñados para provocar el cambio.
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 aplicado o los materiales producidos deben ajustarse. El ajuste debe hacerse 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 o autogestionadas. Se espera que un equipo Scrum se adapte en el momento en que aprende algo nuevo a través de la inspección.
El uso exitoso de Scrum depende de que las personas se vuelvan más competentes en vivir cinco valores:
Compromiso, Enfoque, Apertura, Respeto y Coraje
El equipo Scrum se compromete a alcanzar sus objetivos y a apoyarse mutuamente. Su enfoque principal está en el trabajo del Sprint para hacer el mejor progreso posible hacia estos objetivos. El equipo Scrum y sus interesados son abiertos sobre el trabajo y los desafíos. Los miembros del equipo Scrum se respetan mutuamente como personas capaces e independientes y son respetados como tales por las personas con las que trabajan. Los miembros del equipo Scrum tienen el coraje de hacer lo correcto, trabajar en problemas difíciles.
Estos valores dan dirección al equipo Scrum en cuanto a su trabajo, acciones y comportamiento. Las decisiones que se toman, los pasos que se dan y la forma en que se utiliza Scrum deben reforzar estos valores, no disminuirlos ni socavarlos. Los miembros del equipo Scrum aprenden y exploran los valores mientras trabajan con los eventos y artefactos de Scrum. Cuando estos valores son encarnados por el equipo Scrum y las personas con las que trabajan, los pilares empíricos de Scrum de transparencia, inspección y adaptación cobran vida construyendo confianza.
La unidad fundamental de Scrum es un pequeño equipo de personas, un equipo Scrum. El equipo Scrum consiste en un Scrum Master, un Product Owner y Desarrolladores. Dentro de un equipo Scrum, no hay sub-equipos ni jerarquías. Es una unidad cohesionada de profesionales enfocados en un objetivo a la vez, el Objetivo del Producto.
Los equipos Scrum son multifuncionales, lo que significa que los miembros tienen todas las habilidades necesarias para crear valor en cada Sprint. También son auto-gestionados, lo que significa que internamente deciden quién hace qué, cuándo y cómo.
El equipo Scrum es lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para completar un trabajo significativo dentro de un Sprint, típicamente 10 personas o menos. En general, hemos encontrado que los equipos más pequeños se comunican mejor y son más productivos. Si los equipos Scrum se vuelven demasiado grandes, deben considerar reorganizarse en múltiples equipos Scrum 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 equipo Scrum es responsable de todas las actividades relacionadas con el producto, desde la colaboración con los interesados, verificación, mantenimiento, operación, experimentación, investigación y desarrollo, y cualquier otra cosa que pueda ser requerida. 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 equipo Scrum.
El equipo Scrum completo es responsable de crear un Incremento valioso y útil cada Sprint. Scrum define tres responsabilidades específicas dentro del equipo Scrum: los Desarrolladores, el Product Owner y el Scrum Master.
Los Desarrolladores son las personas en el equipo Scrum que están comprometidas a crear cualquier aspecto de un Incremento utilizable cada Sprint.
Las habilidades específicas necesarias para los Desarrolladores suelen ser amplias y variarán según el dominio del trabajo. Sin embargo, los Desarrolladores siempre son responsables de:
- Crear un plan para el Sprint, el Sprint Backlog;
- Instalar calidad al adherirse a una Definición de Hecho;
- Adaptar su plan cada día hacia el Objetivo del Sprint; y,
- Mantenerse mutuamente responsables como profesionales.
El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del equipo Scrum. Cómo se hace esto puede variar ampliamente entre organizaciones, equipos Scrum 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,
- Asegurar que el Product Backlog sea transparente, visible y comprendido.
El Product Owner puede realizar el trabajo anterior o puede delegar la responsabilidad a otros. Independientemente, el Product Owner sigue siendo responsable.
Para que los Product Owners tengan éxito, toda la organización debe respetar sus decisiones. Estas decisiones son visibles en el contenido y orden del Product Backlog y a través del Incremento 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 deseen cambiar el Product Backlog pueden hacerlo tratando de convencer al Product Owner.
El Scrum Master es responsable de establecer Scrum tal como se define en la Guía Scrum. Hacen esto ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del equipo Scrum como en la organización.
El Scrum Master es responsable de la efectividad del equipo Scrum. Hacen esto habilitando al equipo Scrum para mejorar sus prácticas, dentro del marco de trabajo de Scrum.
Los Scrum Masters son verdaderos líderes que sirven al equipo Scrum y a la organización en general.
El Scrum Master sirve al equipo Scrum de varias maneras, incluyendo:
- Entrenando a los miembros del equipo en auto-gestión y multifuncionalidad;
- Ayudando al equipo Scrum a enfocarse en crear Incrementos de alto valor que cumplan con la Definición de Hecho;
- Provocando la eliminación de impedimentos para el progreso del equipo Scrum; y,
- Asegurando que todos los eventos de Scrum ocurran y sean positivos, productivos y se mantengan dentro del timebox.
El Scrum Master sirve al Product Owner de varias maneras, incluyendo:
- Ayudando a encontrar técnicas para una definición efectiva del Objetivo del Producto y la gestión del Product Backlog;
- Ayudando al equipo Scrum a entender la necesidad de elementos claros y concisos en el Product Backlog;
- Ayudando a establecer una planificación empírica de productos para un entorno complejo; y,
- Facilitando la colaboración de los interesados según sea solicitado o necesario.
El Scrum Master sirve a la organización de varias maneras, incluyendo:
- Liderando, entrenando y entrenando a la organización en su adopción de Scrum;
- Planificando y asesorando las implementaciones de Scrum dentro de la organización;
- Ayudando a los empleados y a los interesados a comprender y adoptar un enfoque empírico para trabajos complejos; y,
- Eliminando barreras entre los interesados y los equipos 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 de Scrum. Estos eventos están específicamente diseñados para permitir la transparencia requerida. La falta de operación de cualquier evento como se prescribe resulta en oportunidades perdidas para inspeccionar y adaptar. Los eventos se utilizan en Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum.
Óptimamente, todos los eventos se llevan a cabo al mismo tiempo y lugar para reducir la complejidad.
Los Sprints son el latido del 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, incluyendo la planificación del Sprint, los Daily Scrums, la Sprint Review y la 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 puede aclararse y renegociarse con el Product Owner a medida que se aprende más.
Los Sprints permiten la previsibilidad al asegurar 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 aumentar y el riesgo puede incrementarse. Los Sprints más cortos pueden emplearse para generar más ciclos de aprendizaje y limitar el riesgo de costo y esfuerzo a un marco de tiempo más pequeño. Cada Sprint puede considerarse un proyecto corto.
Existen varias prácticas para predecir el progreso, como burn-downs, burn-ups o flujos acumulativos. Aunque son útiles, estas no reemplazan la importancia del empirismo. En entornos complejos, lo que sucederá es desconocido. Solo lo que ya ha sucedido puede usarse para la toma de decisiones prospectivas.
Un Sprint podría cancelarse si el Objetivo del Sprint se vuelve obsoleto. Solo el Product Owner tiene la autoridad para cancelar el Sprint.
La Planificación del Sprint inicia el Sprint trazando el trabajo a realizar para el Sprint. Este plan resultante es creado por el trabajo colaborativo de todo el equipo Scrum.
El Product Owner asegura 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 equipo Scrum también puede invitar a otras personas a asistir a la planificación del Sprint para proporcionar asesoramiento.
La planificación del Sprint aborda los siguientes temas:
El Product Owner propone cómo el producto podría aumentar su valor y utilidad en el Sprint actual. Todo el equipo Scrum colabora para definir un Objetivo del Sprint que comunique por qué el Sprint es valioso para los interesados. El Objetivo del Sprint debe finalizarse antes de terminar la planificación del Sprint.
A través de la discusión con el Product Owner, los Desarrolladores seleccionan elementos del Product Backlog para incluir en el Sprint actual. El equipo Scrum 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 Desarrolladores sobre su rendimiento pasado, su capacidad futura y su Definición de Hecho, más confianza tendrán en sus pronósticos del Sprint.
Para cada elemento del Product Backlog seleccionado, los Desarrolladores planifican el trabajo necesario para crear un Incremento que cumpla con la Definición de Hecho. Esto a menudo se hace descomponiendo los elementos del Product Backlog en elementos de trabajo más pequeños de un día o menos. Cómo se hace esto es a discreción exclusiva de los Desarrolladores. Nadie más les dice cómo convertir los elementos del Product Backlog en Incrementos de valor.
El Objetivo del Sprint, los elementos del Product Backlog seleccionados para el Sprint, además del plan para entregarlos, se denominan en conjunto el Sprint Backlog.
La planificación del Sprint está limitada a un máximo de ocho horas para un Sprint de un mes. Para Sprints más cortos, el evento es generalmente más corto.
El propósito del Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario, ajustando el trabajo planificado.
El Daily Scrum es un evento de 15 minutos para los Desarrolladores del equipo Scrum. Para reducir la complejidad, se lleva a cabo a la misma hora y lugar todos los días hábiles del Sprint. Si el Product Owner o el Scrum Master están trabajando activamente en elementos del Sprint Backlog, participan como Desarrolladores.
Los Desarrolladores pueden seleccionar la estructura y técnicas que deseen, siempre que su Daily Scrum se centre en el progreso hacia el Objetivo del Sprint y produzca un plan de acción para el próximo día de trabajo. Esto crea enfoque y mejora la auto-gestión.
Los Daily Scrums mejoran la comunicación, identifican impedimentos, promueven la toma rápida de decisiones y, en consecuencia, eliminan la necesidad de otras reuniones.
El Daily Scrum no es el único momento en que los Desarrolladores pueden ajustar su plan. A menudo se reúnen a lo largo del día para discutir en detalle la adaptación o replanificación del resto del trabajo del Sprint.
El propósito de la Sprint Review es inspeccionar el resultado del Sprint y determinar futuras adaptaciones. El equipo Scrum presenta los resultados de su trabajo a los interesados clave y se discute el progreso hacia el Objetivo del Producto.
Durante el evento, el equipo Scrum 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 puede ajustarse para cumplir con nuevas oportunidades. La Sprint Review es una sesión de trabajo y el equipo Scrum debe evitar limitarla a una presentación.
La Sprint Review es el penúltimo evento del Sprint y está limitada a un máximo de cuatro horas para un Sprint de un mes. Para Sprints más cortos, el evento es generalmente más corto.
El propósito de la Sprint Retrospective es planificar formas de aumentar la calidad y la efectividad.
El equipo Scrum inspecciona cómo fue el último Sprint en relación con individuos, interacciones, procesos, herramientas y su Definición de Hecho. Los elementos inspeccionados a menudo varían con el dominio del trabajo. Se identifican las suposiciones que los llevaron por mal camino y se exploran sus orígenes. El equipo Scrum discute qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no).
El equipo Scrum identifica los cambios más útiles para mejorar su efectividad. Las mejoras más impactantes se abordan lo antes posible. Incluso pueden añadirse al Sprint Backlog para el próximo Sprint.
La Sprint Retrospective concluye el Sprint. Está limitada a un máximo de tres horas para un Sprint de un mes. Para Sprints más cortos, el evento es generalmente más corto.
Los artefactos de Scrum representan trabajo o valor. Están diseñados para maximizar la transparencia de la información clave. Así, todos los que los inspeccionan tienen la misma base para la adaptación.
Cada artefacto contiene un compromiso para asegurar que proporciona información que mejora la transparencia y el enfoque contra el cual se puede medir el progreso:
- Para el Product Backlog es el Objetivo del Producto.
- Para el Sprint Backlog es el Objetivo del Sprint.
- Para el Incremento es la Definición de Hecho.
Estos compromisos existen para reforzar el empirismo y los valores de Scrum para el equipo Scrum y sus interesados.
El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la única fuente de trabajo emprendida por el equipo Scrum.
Los elementos del Product Backlog que pueden ser completados por el equipo Scrum dentro de un Sprint se consideran listos para su selección en un evento de planificación del Sprint. Generalmente adquieren este grado de transparencia después de actividades de refinamiento. El refinamiento del Product Backlog es el acto de descomponer y definir más los elementos del Product Backlog en elementos más pequeños y precisos. Esta es una actividad continua para añadir detalles, como una descripción, orden y tamaño. Los atributos a menudo varían con el dominio del trabajo.
Los Desarrolladores que harán el trabajo son responsables del tamaño. El Product Owner puede influir en los Desarrolladores ayudándoles a comprender y seleccionar compensaciones/estimaciones.
El Objetivo del Producto describe un estado futuro del producto que puede servir como objetivo para el equipo Scrum al planificar. El Objetivo del Producto está en el Product Backlog. El resto del Product Backlog surge para definir "qué" cumplirá el Objetivo del Producto.
Un producto es un vehículo para entregar valor. Tiene un límite claro, interesados conocidos, usuarios o clientes bien definidos. Un producto podría ser un servicio, un producto físico o algo más abstracto.
El Objetivo del Producto es el objetivo a largo plazo del equipo Scrum. Deben cumplir (o abandonar) un objetivo antes de asumir el siguiente.
El Sprint Backlog está compuesto por el 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 Incremento (cómo).
El Sprint Backlog es un plan hecho por y para los Desarrolladores. Es una imagen en tiempo real y altamente visible del trabajo que los Desarrolladores planean lograr durante el Sprint para alcanzar el Objetivo del Sprint. Por lo tanto, el Sprint Backlog se actualiza a lo largo del Sprint a medida que se aprende más. Debe tener suficiente detalle para que puedan inspeccionar su progreso en el Daily Scrum.
El Objetivo del Sprint es el único objetivo para el Sprint. Aunque el Objetivo del Sprint es un compromiso de los Desarrolladores, proporciona flexibilidad en términos del trabajo exacto necesario para lograrlo. El Objetivo del Sprint también crea coherencia y enfoque, alentando al equipo Scrum a trabajar juntos en lugar de en iniciativas separadas.
El Objetivo del Sprint se crea durante el evento de planificación del Sprint y luego se añade al Sprint Backlog. A medida que los Desarrolladores 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.
Un Incremento es un paso concreto hacia el Objetivo del Producto. Cada Incremento se suma a todos los Incrementos anteriores y se verifica a fondo, asegurando que todos los Incrementos funcionen juntos. Para proporcionar valor, el Incremento debe ser utilizable.
Pueden crearse múltiples Incrementos dentro de un Sprint. La suma de los Incrementos se presenta en la Sprint Review, apoyando así el empirismo. Sin embargo, un Incremento puede entregarse a los interesados antes del final del Sprint. La Sprint Review nunca debe considerarse una barrera para liberar valor.
El trabajo no puede considerarse parte de un Incremento a menos que cumpla con la Definición de Hecho.
La Definición de Hecho es una descripción formal del estado del Incremento 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 Hecho, nace un Incremento.
La Definición de Hecho crea transparencia al proporcionar a todos una comprensión compartida de qué trabajo se completó como parte del Incremento. Si un elemento del Product Backlog no cumple con la Definición de Hecho, no puede ser liberado ni siquiera presentado en la Sprint Review. En su lugar, vuelve al Product Backlog para su futura consideración.
Si la Definición de Hecho para un Incremento es parte de los estándares de la organización, todos los equipos Scrum deben seguirla como mínimo. Si no es un estándar organizacional, el equipo Scrum debe crear una Definición de Hecho apropiada para el producto.
Los Desarrolladores están obligados a cumplir con la Definición de Hecho. Si hay múltiples equipos Scrum trabajando juntos en un producto, deben definir y cumplir mutuamente con la misma Definición de Hecho.
Scrum es gratuito y se ofrece en esta Guía. El marco de trabajo de Scrum, tal como se describe aquí, es inmutable. Aunque 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.
De las miles de personas que han contribuido a Scrum, debemos destacar a aquellos que fueron instrumentales 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 tan refinado como lo está hoy.
Ken Schwaber y Jeff Sutherland presentaron por primera vez Scrum en la Conferencia OOPSLA en 1995. Documentó esencialmente el aprendizaje que Ken y Jeff habían adquirido en los años anteriores y hizo pública la primera definición formal de Scrum.
La Guía Scrum documenta Scrum tal como fue desarrollado, evolucionado y mantenido durante más de 30 años por Jeff Sutherland y Ken Schwaber. Otras fuentes proporcionan patrones, procesos y conocimientos que complementan el marco de trabajo de 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 lugares donde se probó y demostró, reconocemos a Individual Inc., Newspage, Fidelity Investments e IDX (ahora GE Medical).
© 2020 Ken Schwaber y Jeff Sutherland Esta publicación se ofrece bajo licencia bajo la licencia Attribution Share-Alike de Creative Commons, accesible en https://creativecommons.org/licenses/by-sa/4.0/legalcode y también descrita en forma resumida en https://creativecommons.org/licenses/by-sa/4.0/. Al utilizar esta Guía Scrum, reconoces y aceptas que has leído y aceptas estar obligado por los términos de la licencia Attribution Share-Alike de Creative Commons.