Guía Scrum
El propósito de la Guía Scrum
Desarrollamos Scrum a principios de la década de 1990.
En 2010 escribimos la primera versión de la Guía Scrum para ayudar a las personas de todo el mundo a entender Scrum.
Desde entonces, hemos seguido mejorando la guía mediante pequeñas actualizaciones funcionales.
La apoyamos y respaldamos conjuntamente.
La Guía Scrum contiene la definición oficial de Scrum.
Cada elemento de Scrum tiene un propósito específico que es esencial para el valor total y los resultados que se pueden obtener con este marco.
Modificar el núcleo o las ideas fundamentales de Scrum, eliminar elementos o no seguir sus reglas oculta problemas, reduce los beneficios y puede incluso volver Scrum inútil.
Observamos cómo Scrum se aplica cada vez más en un mundo de creciente complejidad.
Nos sentimos honrados de ver cómo se utiliza en numerosos campos del trabajo complejo más allá del desarrollo de software, donde Scrum tiene sus orígenes.
A medida que su uso se expande, esta labor es llevada a cabo por desarrolladores, investigadores, analistas, científicos y otros especialistas.
En Scrum utilizamos el término “desarrolladores” no para excluir a nadie, sino para simplificar el lenguaje.
Cualquiera que se beneficie del uso de Scrum debe sentirse incluido.
Al aplicar Scrum, pueden surgir patrones, procesos y conocimientos que se ajusten al marco descrito en este documento.
Su descripción va más allá del propósito de la Guía Scrum, ya que dependen del contexto y pueden variar considerablemente según cómo se implemente Scrum.
Estas tácticas y prácticas de aplicación dentro del marco Scrum se detallan en otros lugares.
Ken Schwaber & Jeff Sutherland, noviembre de 2020
Definición de Scrum
Scrum es un marco de trabajo ligero que ayuda a las personas, equipos y organizaciones a generar valor mediante soluciones adaptativas a problemas complejos.
En pocas palabras, Scrum requiere que un Scrum Master fomente un entorno en el que:
- un Product Owner organice el trabajo relacionado con un problema complejo dentro de un Product Backlog;
- el equipo Scrum seleccione parte de ese trabajo y, durante un Sprint, cree un incremento de valor;
- el equipo Scrum y sus stakeholders revisen los resultados y realicen ajustes para el siguiente Sprint;
- estos pasos se repitan continuamente.
Scrum es sencillo.
Pruébalo tal como es y descubre si su filosofía, teoría y estructura ayudan a alcanzar tus objetivos y generar valor.
El marco Scrum es intencionadamente incompleto y solo define los elementos necesarios para aplicar su teoría.
Scrum se basa en la inteligencia colectiva de las personas que lo practican.
En lugar de dar instrucciones detalladas, las reglas de Scrum guían las relaciones e interacciones entre los miembros del equipo.
Dentro del marco, pueden emplearse distintos procesos, técnicas y métodos.
Scrum puede incorporar prácticas existentes o hacer que dejen de ser necesarias.
Además, hace visible la efectividad relativa de la gestión actual, del entorno y de las técnicas de trabajo, lo que permite implementar mejoras continuas.
Teoría de Scrum
Scrum se basa en la empiria y en el pensamiento Lean.
La empiria significa que el conocimiento se obtiene a partir de la experiencia y que las decisiones se toman basándose en la observación.
El pensamiento Lean busca eliminar el desperdicio y centrarse en lo esencial.
Scrum utiliza un enfoque iterativo e incremental para optimizar la capacidad de previsión y controlar los riesgos.
Se apoya en equipos que, en conjunto, poseen todas las habilidades y conocimientos necesarios para realizar el trabajo, y que comparten o adquieren nuevas competencias cuando es necesario.
Scrum combina cuatro eventos formales de inspección y adaptación dentro de un evento principal: el Sprint.
Estos eventos funcionan porque implementan los tres pilares empíricos de Scrum: transparencia, inspección y adaptación.
Transparencia
El proceso en desarrollo y el trabajo resultante deben ser visibles tanto para quienes lo ejecutan como para quienes lo reciben.
En Scrum, las decisiones importantes se basan en la percepción del estado de sus tres artefactos formales.
Cuando los artefactos carecen de transparencia, pueden tomarse decisiones que reduzcan el valor y aumenten el riesgo.
La transparencia permite la inspección.
Una inspección sin transparencia resulta engañosa y genera desperdicio.
Inspección
Los artefactos de Scrum y el progreso hacia los objetivos acordados deben revisarse con frecuencia y de forma minuciosa para detectar posibles desviaciones o problemas.
Para facilitar esta inspección, Scrum establece una cadencia mediante sus cinco eventos.
La inspección permite la adaptación.
Una inspección sin adaptación se considera inútil.
Los eventos de Scrum están diseñados precisamente para impulsar el cambio.
Adaptación
Cuando ciertos aspectos de un proceso se desvían de los límites aceptables o cuando el producto resultante no cumple con las expectativas, el proceso aplicado o los resultados producidos deben ajustarse.
Esta adaptación debe realizarse lo antes posible para minimizar futuras desviaciones.
La adaptación se vuelve más difícil cuando las personas involucradas no están empoderadas o no pueden autogestionarse.
Se espera que un equipo Scrum se adapte en el momento en que, a través de la inspección, aprende algo nuevo.
Valores de Scrum
La aplicación exitosa de Scrum depende de que las personas sean cada vez más capaces de vivir según cinco valores fundamentales:
- Compromiso
- Enfoque
- Apertura
- Respeto
- Coraje
El equipo Scrum se compromete a alcanzar sus objetivos y a apoyarse mutuamente.
Su enfoque principal está en el trabajo del Sprint, para lograr el mayor progreso posible hacia esos objetivos.
El equipo Scrum y sus stakeholders son abiertos con respecto al trabajo y los desafíos que enfrentan.
Los miembros del equipo Scrum se respetan entre sí como personas capaces e independientes, y son respetados como tales por quienes colaboran con ellos.
Además, los miembros del equipo tienen el coraje de hacer lo correcto y de enfrentar los problemas difíciles.
Estos valores orientan al equipo Scrum en su trabajo, sus acciones y su comportamiento.
Las decisiones que se tomen, los pasos que se den y la forma en que se aplique Scrum deben fortalecer estos valores, no debilitarlos.
Los miembros del equipo Scrum aprenden y exploran estos valores mientras trabajan en los eventos y con los artefactos de Scrum.
Cuando estos valores son vividos tanto por el equipo Scrum como por quienes colaboran con él, los pilares empíricos de Scrum —transparencia, inspección y adaptación— cobran vida y generan confianza.
Equipo Scrum
El componente central de Scrum es un pequeño grupo de personas: el equipo Scrum.
Está formado por un(a) Scrum Master, un(a) Product Owner y los Desarrolladores.
Dentro de un equipo Scrum no existen subequipos ni jerarquías.
Es una unidad cohesionada de profesionales que se centra en un único objetivo: la meta del producto.
Los equipos Scrum son interdisciplinarios, lo que significa que sus miembros poseen todas las habilidades necesarias para generar valor en cada Sprint.
Además, son autoorganizados, lo que implica que deciden internamente quién hace qué, cuándo y cómo.
El equipo Scrum es lo suficientemente pequeño para mantenerse ágil y lo suficientemente grande para completar un trabajo significativo dentro de un Sprint —generalmente 10 personas o menos—.
Por lo general, los equipos más pequeños se comunican mejor y son más productivos.
Si un equipo Scrum se vuelve demasiado grande, se recomienda dividirlo en varios equipos que trabajen en el mismo producto, compartiendo la meta del producto, el Product Backlog y el Product Owner.
El equipo Scrum es responsable de la implementación de todas las actividades relacionadas con el producto: colaboración con los stakeholders, verificación, mantenimiento, operación, experimentación, investigación, desarrollo y cualquier otra tarea necesaria.
Está estructurado y empoderado por la organización para gestionar su propio trabajo.
Trabajar en Sprints con un ritmo sostenible mejora el enfoque y la continuidad del equipo.
Todo el equipo Scrum es responsable del resultado, es decir, de crear en cada Sprint un incremento de valor y utilidad.
Scrum define tres responsabilidades específicas dentro del equipo: Desarrolladores, Product Owner y Scrum Master.
Desarrolladores
Los Desarrolladores son las personas dentro del equipo Scrum que se comprometen a crear, en cada Sprint, todos los aspectos de un incremento utilizable.
Las habilidades necesarias varían según el contexto de trabajo, pero los Desarrolladores siempre son responsables de:
- crear un plan para el Sprint, el Sprint Backlog;
- garantizar la calidad siguiendo la Definition of Done;
- ajustar su plan diariamente para alcanzar la meta del Sprint; y
- rendirse cuentas mutuamente como profesionales.
Product Owner
El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del equipo Scrum.
La forma de hacerlo puede variar según la organización, el equipo y la persona.
También es responsable de una gestión efectiva del Product Backlog, lo que incluye:
- desarrollar y comunicar claramente la meta del producto;
- crear y comunicar de forma clara los elementos del Product Backlog;
- establecer el orden de los elementos del Product Backlog; y
- asegurar que el Product Backlog sea transparente, visible y comprendido.
El Product Owner puede delegar parte de este trabajo, pero sigue siendo el responsable último del resultado.
Para tener éxito, toda la organización debe respetar las decisiones del Product Owner, que se reflejan en el contenido y la priorización del Product Backlog, así como en el incremento verificable mostrado en la Sprint Review.
El Product Owner es una sola persona, no un comité.
Puede tener en cuenta las necesidades de múltiples stakeholders en el Product Backlog.
Aquellos que deseen cambiar el Backlog deben convencer al Product Owner.
Scrum Master
El Scrum Master es responsable de implantar Scrum tal como se define en la Guía Scrum.
Lo hace ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del equipo como en toda la organización.
El Scrum Master es responsable de la efectividad del equipo Scrum, lo cual logra facilitando la mejora continua de sus prácticas dentro del marco de trabajo de Scrum.
Los Scrum Masters son líderes al servicio que ayudan tanto al equipo Scrum como a la organización.
El Scrum Master sirve al equipo Scrum, entre otras formas, mediante:
- la formación del equipo en autogestión y colaboración interdisciplinaria;
- el apoyo para centrarse en crear incrementos de alta calidad que cumplan la Definition of Done;
- la eliminación de obstáculos (impediments) que bloqueen el progreso del equipo; y
- la garantía de que todos los eventos de Scrum se realicen, sean positivos, productivos y se mantengan dentro del tiempo asignado (timebox).
El Scrum Master sirve al Product Owner, entre otras formas, mediante:
- la ayuda para encontrar técnicas efectivas para definir la meta del producto y gestionar el Product Backlog;
- el apoyo al equipo Scrum para comprender la necesidad de elementos del Product Backlog claros y precisos;
- la asistencia en la planificación empírica del producto en entornos complejos; y
- la facilitación de la colaboración con los stakeholders según sea necesario.
El Scrum Master sirve a la organización, entre otras formas, mediante:
- la guía, formación y asesoramiento en la adopción de Scrum;
- la planificación y recomendación de implementaciones de Scrum dentro de la organización;
- el apoyo a empleados y stakeholders para comprender y aplicar un enfoque empírico al trabajo complejo; y
- la eliminación de barreras entre los stakeholders y los equipos Scrum.
Eventos de Scrum
El Sprint es un contenedor que incluye 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 diseñados específicamente para ofrecer la transparencia necesaria.
Si un evento no se realiza según lo previsto, se pierde la oportunidad de inspeccionar y ajustar.
Los eventos se utilizan en Scrum para generar regularidad y reducir la necesidad de reuniones adicionales no definidas en el marco.
Idealmente, todos los eventos se llevan a cabo en el mismo momento y lugar para reducir la complejidad.
El Sprint
Los Sprints son el latido del corazón de Scrum, donde las ideas se transforman en valor.
Son eventos de duración fija —de un mes o menos— que aportan consistencia.
Un nuevo Sprint comienza inmediatamente después de finalizar el anterior.
Todo el trabajo necesario para alcanzar la meta del producto, incluyendo la planificación del Sprint, los Daily Scrums, la revisión y la retrospectiva, tiene lugar dentro del Sprint.
Durante el Sprint
- No se realizan cambios que pongan en riesgo la meta del Sprint.
- La calidad no disminuye.
- El Product Backlog se refina según sea necesario.
- El alcance puede aclararse y renegociarse con el Product Owner a medida que se adquiere más conocimiento.
Los Sprints permiten la predictibilidad, ya que garantizan una revisión y adaptación del progreso hacia la meta del producto al menos una vez al mes.
Si un Sprint es demasiado largo, la meta puede perder relevancia, la complejidad aumentar y el riesgo crecer.
Los Sprints más cortos permiten ciclos de aprendizaje más frecuentes y reducen el riesgo en tiempo y coste.
Cada Sprint puede considerarse como un proyecto breve.
Existen distintas herramientas para predecir el progreso, como burn-down charts, burn-up charts o diagramas de flujo acumulativo (cumulative flow).
Aunque son útiles, no reemplazan la importancia del enfoque empírico: en entornos complejos, solo lo que ya ha ocurrido puede usarse para tomar decisiones informadas.
Un Sprint puede cancelarse si su meta se vuelve obsoleta.
Solo el Product Owner tiene autoridad para hacerlo.
Planificación del Sprint (Sprint Planning)
La planificación del Sprint inicia el Sprint estableciendo el trabajo que se realizará.
El plan resultante se crea mediante la colaboración de todo el equipo Scrum.
El Product Owner se asegura de que los participantes estén preparados para discutir los elementos más importantes del Product Backlog y cómo se relacionan con la meta del producto.
El equipo Scrum puede invitar a otras personas para aportar asesoramiento durante la planificación del Sprint.
La planificación del Sprint aborda tres temas principales:
Tema 1: ¿Por qué este Sprint es valioso?
El Product Owner propone cómo el producto puede aumentar su valor y utilidad en el Sprint actual.
El equipo Scrum colabora para definir una meta del Sprint que refleje por qué el Sprint es valioso para los stakeholders.
Esta meta debe definirse antes de finalizar la sesión de planificación.
Tema 2: ¿Qué se puede completar en este Sprint?
En diálogo con el Product Owner, los desarrolladores seleccionan los elementos del Product Backlog que se incluirán en el Sprint actual.
Durante este proceso, el equipo puede refinar los elementos, lo que aumenta la comprensión y la confianza.
Determinar cuánto trabajo puede completarse es un desafío, pero a medida que los desarrolladores conocen mejor su rendimiento anterior, su capacidad futura y la Definition of Done, sus predicciones se vuelven más precisas.
Tema 3: ¿Cómo se completará el trabajo seleccionado?
Para cada elemento del Product Backlog seleccionado, los desarrolladores planifican el trabajo necesario para crear un incremento que cumpla con la Definition of Done.
A menudo, esto implica dividir los elementos en tareas más pequeñas, de uno o menos días de duración.
El cómo se haga depende exclusivamente de los desarrolladores; nadie más decide cómo transformar los elementos del Backlog en incrementos de valor.
La meta del Sprint, los elementos seleccionados del Product Backlog y el plan de entrega constituyen el Sprint Backlog.
La planificación del Sprint tiene una duración máxima de ocho horas para un Sprint de un mes, siendo normalmente más corta para Sprints de menor duración.
Daily Scrum
El propósito del Daily Scrum o Daily Stand-up es inspeccionar el progreso hacia la meta del Sprint y ajustar el Sprint Backlog según sea necesario para planificar el próximo día de trabajo.
Es un evento de 15 minutos para los desarrolladores del equipo Scrum.
Para reducir la complejidad, se celebra cada día laboral del Sprint a la misma hora y en el mismo lugar.
Si el Product Owner o el Scrum Master trabajan activamente en elementos del Sprint Backlog, participan como desarrolladores.
Los desarrolladores pueden elegir libremente la estructura y las técnicas del Daily Scrum, siempre que se centren en el progreso hacia la meta y generen un plan de acción para el siguiente día.
Esto fomenta el enfoque y la autogestión.
Los Daily Scrums mejoran la comunicación, identifican obstáculos, promueven decisiones rápidas y eliminan la necesidad de otras reuniones.
Sin embargo, no son la única oportunidad para ajustar el plan; los desarrolladores suelen reunirse varias veces al día para discutir y reajustar el trabajo restante del Sprint.
Revisión del Sprint (Sprint Review)
El propósito de la revisión del Sprint es inspeccionar el resultado del Sprint y decidir posibles adaptaciones futuras.
El equipo Scrum presenta su trabajo a los stakeholders y se revisa el progreso hacia la meta del producto.
Durante este evento, el equipo y los stakeholders revisan lo que se logró y los cambios ocurridos en el entorno.
Con esta información, colaboran para decidir los próximos pasos y pueden ajustar el Product Backlog para reflejar nuevas oportunidades.
La revisión del Sprint es un evento de trabajo colaborativo, no una simple presentación.
Tiene una duración máxima de cuatro horas para un Sprint de un mes, siendo más corta en Sprints de menor duración.
Retrospectiva del Sprint (Sprint Retrospective)
El propósito de la retrospectiva del Sprint es planificar maneras de aumentar la calidad y la efectividad del equipo.
El equipo Scrum analiza cómo fue el último Sprint en términos de individuos, interacciones, procesos, herramientas y la Definition of Done.
Los temas revisados varían según el contexto de trabajo.
Se identifican las suposiciones incorrectas y se examinan sus causas.
El equipo discute lo que funcionó bien, los problemas que surgieron y cómo se resolvieron o no.
A partir de esto, el equipo identifica los cambios más útiles para mejorar su efectividad.
Las mejoras más importantes se abordan lo antes posible y pueden incluso incluirse en el Sprint Backlog del siguiente Sprint.
La retrospectiva cierra el Sprint.
Tiene una duración máxima de tres horas para un Sprint de un mes, y suele ser más corta en Sprints más breves.
Artefactos de Scrum
Los artefactos de Scrum representan trabajo o valor.
Están diseñados para maximizar la transparencia de la información clave, de modo que todos los que los inspeccionan compartan la misma base para realizar ajustes.
Cada artefacto incluye un compromiso (commitment) que garantiza la entrega de información que mejore la transparencia y el enfoque, permitiendo medir el progreso:
- Para el Product Backlog, el compromiso es la meta del producto.
- Para el Sprint Backlog, el compromiso es la meta del Sprint.
- Para el Incremento, el compromiso es la Definition of Done.
Estos compromisos refuerzan la empiria y los valores de Scrum tanto para el equipo como para los stakeholders.
Product Backlog
El Product Backlog es una lista emergente y priorizada de todo lo que se necesita para mejorar el producto.
Es la única fuente de trabajo para el equipo Scrum.
Los elementos del Product Backlog que pueden completarse dentro de un Sprint se consideran listos para su selección durante la planificación.
Este nivel de transparencia se logra normalmente mediante actividades de refinamiento, en las cuales los elementos se dividen en partes más pequeñas y se definen con mayor precisión.
El refinamiento es una actividad continua que agrega detalles como descripciones, orden y tamaño; estos atributos varían según el contexto de trabajo.
Los desarrolladores, que son quienes realizan el trabajo, son responsables de estimar el esfuerzo.
El Product Owner puede influir ayudando a comprender los elementos y negociando prioridades.
Compromiso: Meta del Producto
La meta del producto describe un estado futuro del producto y sirve como objetivo de planificación para el equipo Scrum.
Se encuentra dentro del Product Backlog, y el resto del Backlog se construye en torno a lo que sea necesario para alcanzar esa meta.
Un producto es un medio para generar valor.
Tiene límites claros, stakeholders definidos y usuarios o clientes identificados.
Puede tratarse de un servicio, un producto físico o algo más abstracto.
La meta del producto es el objetivo a largo plazo del equipo Scrum.
El equipo debe completar (o abandonar) una meta antes de comenzar con la siguiente.
Sprint Backlog
El Sprint Backlog incluye la meta del Sprint (por qué), los elementos seleccionados del Product Backlog (qué) y un plan viable para entregar el incremento (cómo).
Es un plan creado por y para los desarrolladores.
Representa una imagen actualizada en tiempo real del trabajo que los desarrolladores realizarán durante el Sprint para alcanzar la meta.
Por lo tanto, se actualiza continuamente a medida que se aprende más.
Debe contener suficiente detalle para que el equipo pueda revisar su progreso durante el Daily Scrum.
Compromiso: Meta del Sprint
La meta del Sprint es el único objetivo del Sprint.
Aunque es un compromiso de los desarrolladores, ofrece flexibilidad en cuanto al trabajo específico necesario para alcanzarla.
Crea cohesión y enfoque, fomentando que el equipo Scrum trabaje unido en lugar de en iniciativas separadas.
La meta del Sprint se establece durante la planificación y se añade al Sprint Backlog.
Durante el Sprint, los desarrolladores la mantienen siempre presente.
Si descubren que el trabajo difiere de lo esperado, colaboran con el Product Owner para ajustar el alcance del Sprint Backlog sin afectar la meta del Sprint.
Incremento
Un Incremento es un paso concreto hacia la meta del producto.
Cada incremento se suma a los anteriores y se verifica cuidadosamente para garantizar que todos funcionen juntos.
Para generar valor, un incremento debe ser utilizable.
Durante un Sprint pueden crearse varios incrementos, y su conjunto se presenta en la revisión del Sprint, reforzando la empiria.
Un incremento puede entregarse a los stakeholders antes de finalizar el Sprint.
La revisión del Sprint nunca debe considerarse una barrera para entregar valor.
El trabajo no puede considerarse parte de un incremento hasta que cumpla con la Definition of Done.
Compromiso: Definition of Done
La Definition of Done es una descripción formal del estado del incremento cuando cumple las medidas de calidad requeridas para el producto.
En el momento en que un elemento del Product Backlog cumple con la Definition of Done, se convierte en un incremento.
La Definition of Done aporta transparencia, proporcionando un entendimiento común sobre qué trabajo se ha completado como parte del incremento.
Si un elemento no cumple con esta definición, no puede entregarse ni presentarse en la revisión del Sprint, y vuelve al Product Backlog para su consideración futura.
Si la Definition of Done forma parte de los estándares de la organización, todos los equipos Scrum deben cumplirla como mínimo.
Si no existe un estándar, el equipo Scrum debe crear una definición adecuada para su producto.
Los desarrolladores deben adherirse a la Definition of Done.
Cuando varios equipos Scrum trabajan en el mismo producto, deben compartir una Definition of Done común y cumplirla colectivamente.
Nota final
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 algunas partes, el resultado no es Scrum.
Scrum solo existe en su totalidad y funciona bien como contenedor para otras técnicas, metodologías y prácticas.
Agradecimientos
Personas
De las miles de personas que han contribuido a Scrum, queremos destacar a quienes tuvieron un papel fundamental al principio:
Jeff Sutherland trabajó con Jeff McKenna y John Scumniotales, y Ken Schwaber colaboró con Mike Smith y Chris Martin —y todos ellos trabajaron juntos—.
Muchos otros han contribuido a lo largo de los años.
Sin su ayuda, Scrum no sería tan refinado como lo es hoy.
Historia de la Guía Scrum
Ken Schwaber y Jeff Sutherland presentaron Scrum juntos por primera vez en la conferencia OOPSLA en 1995.
Esa presentación documentó los aprendizajes que ambos habían obtenido durante los años previos aplicando Scrum y representó la primera publicación formal de su definición.
La Guía Scrum documenta Scrum tal como ha sido desarrollado, ampliado y mantenido por Jeff Sutherland y Ken Schwaber durante más de 30 años.
Otras fuentes proporcionan patrones, procesos y conocimientos que complementan el marco de Scrum y 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.
Queremos reconocer a las primeras organizaciones donde se probó y demostró su eficacia: Individual Inc., Newspage, Fidelity Investments e IDX (ahora GE Medical).
© 2020 Ken Schwaber y Jeff Sutherland
Esta publicación está disponible bajo la licencia Creative Commons Attribution Share-Alike, accesible en
https://creativecommons.org/licenses/by-sa/4.0/legalcode
y resumida en https://creativecommons.org/licenses/by-sa/4.0/.
Al utilizar esta Guía Scrum, reconoces y aceptas los términos de dicha licencia.
Cambios respecto a la versión 2017
Fueron resumidos por Sohrab Salimi, CEO de Scrum Academy, en el artículo
“Cambios en la Guía Scrum 2020”.
Esta versión (3.2) es una nueva traducción completa, publicada con motivo del lanzamiento de la Guía Scrum 2020.
Fecha: 03.12.2020
Traducción
Esta guía fue traducida del texto original en inglés proporcionado por Ken Schwaber y Jeff Sutherland.