La Guía Scrum 2020TM
Propósito de la Guía Scrum
Desarrollamos Scrum a principios de los años 1990. Escribimos la primera versión de la Guía Scrum en 2010 para ayudar a personas de todo el mundo a comprender Scrum. Desde entonces, hemos evolucionado la Guía a través de pequeñas actualizaciones funcionales. Juntos lo respaldamos.
La Guía Scrum contiene la definición de Scrum. Cada elemento del marco tiene un propósito específico que es esencial para el valor general y los resultados obtenidos con Scrum. Cambiar el diseño central o las ideas de Scrum, omitir elementos o no seguir las reglas de Scrum, encubre problemas y limita los beneficios de Scrum, potencialmente incluso haciéndolo inútil.
Seguimos el creciente uso de Scrum dentro de un mundo cada vez más complejo. Nos sentimos honrados de ver que Scrum se adopta en muchos dominios que involucran trabajos esencialmente complejos, más allá del desarrollo de productos de software donde Scrum tiene sus raíces. A medida que se difunde 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 e idear patrones, procesos e ideas que se ajusten al marco de 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. Estas tácticas para usar dentro del marco de Scrum varían ampliamente y se describen en otra parte.
Definición de Scrum
Scrum es un marco liviano que ayuda a 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 para un problema complejo en un Product Backlog.
- El Equipo Scrum convierte una selección del trabajo en un Incremento de valor durante un Sprint.
- El equipo Scrum y sus partes interesadas inspeccionan los resultados y los ajustan para el próximo Sprint.
- Repetir
Scrum es simple. Pruébelo tal como está y determine si su filosofía, teoría y estructura ayudan a alcanzar objetivos y crear valor. El marco de Scrum es intencionalmente incompleto y 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.
Dentro del marco se pueden emplear varios procesos, técnicas y métodos. Scrum envuelve las prácticas existentes o las hace innecesarias. Scrum hace visible la eficacia relativa de la gestión, el entorno y las técnicas de trabajo actuales, para 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 basadas en lo observado. El pensamiento Lean reduce el desperdicio y se centra 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 transparencia, inspección y adaptación de Scrum.
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 conducir a decisiones que disminuyen el valor y aumentan 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 diligencia para detectar variaciones o problemas potencialmente indeseables. Para ayudar con la inspección, Scrum proporciona cadencia en forma de 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, se debe ajustar el proceso que se aplica o los materiales que se producen. 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 son autogestionadas. Se espera que un equipo Scrum 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, enfoque, apertura, respeto y coraje
El Equipo Scrum se compromete a lograr sus objetivos y a apoyarse mutuamente. Su enfoque principal es el trabajo del Sprint para lograr el mejor progreso posible hacia estos objetivos. El Scrum Team y sus partes interesadas están abiertos al trabajo y los desafíos. Los miembros del Scrum Team se respetan entre sí por ser personas capaces e independientes, y como tales son respetados por las personas con las que trabajan. Los miembros del Scrum Team tienen el coraje de hacer lo correcto, de trabajar en problemas difíciles.
Estos valores dan dirección al Equipo Scrum con respecto a su trabajo, acciones y comportamiento. Las decisiones que se toman, los pasos dados 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 transparencia, inspección y adaptación de Scrum cobran vida generando confianza.
Equipo Scrum
La unidad fundamental de Scrum es un pequeño equipo de personas, un Scrum Team. El Scrum Team está formado por un Scrum Master, un Product Owner y desarrolladores. Dentro de un Scrum Team, no existen subequipos ni jerarquías. Es una unidad cohesiva de profesionales centrados en un objetivo a la vez, la Meta 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 autogestionados, lo que significa que deciden internamente quién hace qué, cuándo y cómo.
El equipo Scrum 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 de 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 equipos Scrum se vuelven demasiado grandes, deberían considerar reorganizarse en múltiples equipos Scrum cohesivos, cada uno centrado en el mismo producto. Por lo tanto, deben compartir el mismo objetivo de producto, cartera de productos y propietario de producto.
El Equipo Scrum es responsable de todas las actividades relacionadas con el producto, desde la colaboración de las partes interesadas, 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 facultados 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 Equipo Scrum es responsable de crear un Incremento valioso y útil en cada Sprint. Scrum define tres responsabilidades específicas dentro del Scrum Team: los Desarrolladores, el Product Owner y el Scrum Master.
Desarrolladores
Los desarrolladores son las personas del Equipo Scrum que se comprometen a crear cualquier aspecto de un Incremento utilizable en cada Sprint.
Las habilidades específicas que necesitan los desarrolladores suelen ser amplias y variarán según el ámbito de trabajo. Sin embargo, los Desarrolladores siempre son responsables de:
- Crear un plan para el Sprint, el Sprint Backlog;
- Inculcar calidad adhiriéndose a una definición de hecho;
- Adaptar su plan cada día hacia el objetivo del Sprint; y,
- Responsabilizarnos unos a otros como profesionales.
Propietario del producto
El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del Scrum Team. La forma en que se hace esto puede variar ampliamente entre organizaciones, equipos Scrum e individuos.
El propietario del producto también es responsable de la gestión eficaz del backlog del producto, que incluye:
- Desarrollar y comunicar explícitamente el objetivo del producto;
- Crear y comunicar claramente elementos del Product Backlog;
- Pedido de elementos de la cartera de productos; y,
- Asegurar que el Product Backlog sea transparente, visible y comprendido.
El propietario del producto puede realizar el trabajo anterior o puede delegar la responsabilidad a otros. De todos modos, el propietario del producto 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 el orden del Product Backlog, y a través del Incremento inspeccionable en la Sprint Review.
El propietario del producto es una persona, no un comité. El Product Owner puede representar las necesidades de muchas partes interesadas 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 Scrum. Lo hacen 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 eficacia del Scrum Team. Lo hacen permitiendo que el Equipo Scrum mejore sus prácticas, dentro del marco 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 Scrum Team de varias maneras, incluyendo:
- Coaching a los miembros del equipo en autogestión y funcionalidad cruzada;
- Ayudar al Equipo Scrum a centrarse en crear Incrementos de alto valor que cumplan con la Definición de Hecho;
- Provocar la eliminación de impedimentos al progreso del Equipo Scrum; y,
- Asegurar que todos los eventos de Scrum se lleven a cabo y sean positivos, productivos y se mantengan dentro del plazo establecido.
El Scrum Master sirve al Product Owner de varias maneras, entre ellas:
- Ayudar a encontrar técnicas para la definición eficaz de los objetivos del producto y la gestión del Backlog del producto;
- Ayudar al equipo Scrum a comprender la necesidad de elementos claros y concisos del Product Backlog;
- Ayudar a establecer una planificación empírica de productos para un entorno complejo; y,
- Facilitar la colaboración de las partes interesadas según se solicite o sea necesario.
El Scrum Master sirve a la organización de varias maneras, entre ellas:
- Liderar, capacitar y asesorar 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 partes interesadas a comprender y aplicar un enfoque empírico para trabajos complejos; y,
- Eliminar barreras entre las partes interesadas y los equipos Scrum.
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 de Scrum. Estos eventos están diseñados específicamente para permitir la transparencia requerida. No operar cualquier evento según lo prescrito da como resultado 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 ideal es que todos los eventos se lleven a cabo 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 coherencia. Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.
Todo el trabajo necesario para lograr el objetivo del producto, incluida la planificación del Sprint, los Scrums diarios, la revisión del Sprint y la retrospectiva del Sprint, se realiza dentro de los Sprints.
Durante el sprint:
- No se realizan cambios que puedan poner en peligro el objetivo del Sprint;
- La calidad no disminuye;
- El Product Backlog se perfecciona según sea necesario; y,
- El alcance se puede aclarar y renegociar con el propietario del producto 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 de producto al menos cada mes calendario. Cuando el horizonte de un Sprint es demasiado largo, el objetivo del Sprint puede dejar de ser válido, la complejidad puede aumentar 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 más corto. Cada Sprint puede considerarse un proyecto corto.
Existen varias prácticas para pronosticar el progreso, como burn-downs, burn-ups o flujos acumulativos. Si bien han demostrado ser útiles, no reemplazan la importancia del empirismo. En entornos complejos, se desconoce qué sucederá. Sólo lo que ya ha sucedido puede utilizarse para la toma de decisiones con visión de futuro.
Un Sprint podría cancelarse si el objetivo del Sprint queda obsoleto. Sólo el Product Owner tiene la autoridad para cancelar el Sprint.
Planificación de sprint
La planificación del Sprint inicia el Sprint estableciendo el trabajo que se realizará para el Sprint. Este plan resultante se crea mediante el trabajo colaborativo de todo el Equipo Scrum.
El propietario del producto se asegura de que los asistentes estén preparados para discutir los elementos más importantes del backlog del producto y cómo se relacionan con el objetivo del producto. El Scrum Team también puede invitar a otras personas a asistir a Sprint Planning para brindar asesoramiento.
La planificación de Sprint aborda los siguientes temas:
Tema uno: ¿Por qué es valioso este Sprint?
El Product Owner propone cómo el producto podría aumentar su valor y utilidad en el Sprint actual. Luego, todo el equipo Scrum colabora para definir un objetivo de Sprint que comunique por qué el Sprint es valioso para las partes interesadas. El objetivo del Sprint debe finalizarse antes del final de la planificación del Sprint.
Tema dos: ¿Qué se puede hacer en este Sprint?
A través de la discusión con el Propietario del Producto, los Desarrolladores seleccionan elementos del Backlog del Producto para incluirlos en el Sprint actual. El Equipo Scrum puede perfeccionar 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 desempeño pasado, su capacidad futura y su definición de hecho, más confianza tendrán en sus pronósticos de Sprint.
Tema tres: ¿Cómo se realizará el trabajo elegido?
Para cada elemento seleccionado del Backlog del Producto, 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. La forma de hacerlo queda a exclusivo criterio de los Desarrolladores. Nadie más les dice cómo convertir elementos del Product Backlog en Incrementos de valor.
El objetivo del Sprint, los elementos del Product Backlog seleccionados para el Sprint, más el plan para entregarlos se denominan en conjunto Sprint Backlog.
La planificación de Sprint tiene un límite de tiempo de un máximo de ocho horas para un Sprint de un mes. Para Sprints más cortos, el evento suele ser más corto.
Scrum diario
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 próximo 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 Scrum Master están trabajando activamente en elementos del Sprint Backlog, participan como Desarrolladores.
Los Desarrolladores pueden seleccionar cualquier estructura y técnica que deseen, siempre y cuando su Scrum Diario se centre en el progreso hacia el Objetivo del Sprint y produzca un plan viable para el siguiente día de trabajo. Esto crea concentración y mejora la autogestión.
Daily Scrums mejora las comunicaciones, identifica impedimentos, promueve la toma rápida de decisiones y, en consecuencia, elimina la necesidad de otras reuniones.
El Daily Scrum no es el único momento en el que los desarrolladores pueden ajustar su plan. A menudo se reúnen a lo largo del día para discusiones más detalladas sobre cómo adaptar o replanificar el resto del trabajo del Sprint.
Revisión de sprint
El propósito de la Revisión del Sprint es inspeccionar el resultado del Sprint y determinar adaptaciones futuras. El Equipo Scrum presenta los resultados de su trabajo a las partes interesadas clave y se discute el progreso hacia el Objetivo del Producto.
Durante el evento, el Equipo Scrum y las partes interesadas revisan lo que se logró en el Sprint y lo que ha cambiado en su entorno. A partir de esta información, los asistentes colaboran sobre qué hacer a continuación. El Product Backlog también puede ajustarse para aprovechar nuevas oportunidades. El Sprint Review es una sesión de trabajo y el Scrum Team debe evitar limitarla a una presentación.
La Revisión del Sprint es el penúltimo evento del Sprint y tiene un límite de tiempo de un máximo de cuatro horas para un Sprint de un mes. Para Sprints más cortos, el evento suele ser más corto.
Retrospectiva de Sprint
El propósito de la Retrospectiva de Sprint es planificar formas de aumentar la calidad y la eficacia.
El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Hecho. Los elementos inspeccionados a menudo varían según el ámbito de trabajo. Se identifican las suposiciones que los llevaron por mal camino y se exploran sus orígenes. El Equipo Scrum analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.
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 agregarse al Sprint Backlog para el próximo Sprint.
La Retrospectiva del Sprint concluye el Sprint. Tiene un límite de tiempo de un máximo de tres horas para un Sprint de un mes. Para Sprints más cortos, el evento suele ser más corto.
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, todos los que los inspeccionan tienen las mismas bases de adaptación.
Cada artefacto contiene el compromiso de garantizar que proporcione información que mejore la transparencia y el enfoque con el que se pueda medir el progreso:
- Para el Product Backlog es el Objetivo del Producto.
- Para el Sprint Backlog es el Sprint Goal.
- 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 partes interesadas.
Reserva de productos
El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la única fuente de trabajo realizada por el Scrum Team.
Los elementos del Backlog del Producto que el Equipo Scrum puede realizar dentro de un Sprint se consideran listos para su selección en un evento de Planificación del Sprint. Suelen adquirir este grado de transparencia tras las actividades de refinado. El refinamiento del Product Backlog es el acto de desglosar 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 a menudo varían según el ámbito del trabajo.
Los Desarrolladores que realizarán el trabajo son responsables del dimensionamiento. El Propietario del Producto puede influir en los Desarrolladores ayudándolos a comprender y seleccionar compensaciones.
Compromiso: Objetivo del producto
El objetivo del producto describe un estado futuro del producto que puede servir como objetivo para que el equipo Scrum planifique. 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, partes interesadas conocidas, usuarios o clientes bien definidos. Un producto podría ser un servicio, un producto físico o algo más abstracto.
La Meta del Producto es el objetivo a largo plazo para el Equipo Scrum. Deben cumplir (o abandonar) un objetivo antes de emprender el siguiente.
Trabajo pendiente de sprint
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 procesable para entregar el Incremento (cómo).
El Sprint Backlog es un plan hecho por y para los Desarrolladores. Es una imagen muy visible y en tiempo real del trabajo que los Desarrolladores 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 el Daily Scrum.
Compromiso: Objetivo del Sprint
El Sprint Goal es el único objetivo del Sprint. Aunque el Sprint Goal es un compromiso de los Desarrolladores, proporciona flexibilidad en términos del trabajo exacto necesario para lograrlo. El Sprint Goal también crea coherencia y enfoque, animando al Scrum Team 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 agrega al Sprint Backlog. Mientras los desarrolladores trabajan durante el Sprint, tienen en cuenta el objetivo del Sprint. Si el trabajo resulta diferente a lo que esperaban, colaboran con el Product Owner para negociar el alcance del Sprint Backlog dentro del Sprint sin afectar el Sprint Goal.
Incremento
Un incremento es un trampolín concreto hacia el objetivo del producto. Cada Incremento se suma a todos los Incrementos anteriores y se verifica minuciosamente, lo que garantiza que todos los Incrementos funcionen juntos. Para proporcionar valor, el Incremento debe ser utilizable.
Se pueden crear múltiples incrementos dentro de un Sprint. La suma de los Incrementos se presenta en el Sprint Review apoyando así el empirismo. Sin embargo, se puede entregar un Incremento a las partes interesadas antes del final del Sprint. La Sprint Review nunca debe considerarse una puerta para liberar valor.
El trabajo no puede considerarse parte de un Incremento a menos que cumpla con la Definición de Realizado.
Compromiso: 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 brindarles 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 Terminado, no se puede publicar ni siquiera presentar en la Sprint Review. En cambio, regresa al Product Backlog para su consideración futura.
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 deben cumplir con la Definición de Hecho. Si hay varios Equipos Scrum trabajando juntos en un producto, deben definir y cumplir mutuamente con la misma Definición de Hecho.
Nota final
Scrum es gratuito y se ofrece en esta guía. El marco de Scrum, como se describe aquí, es inmutable. Si bien solo es posible implementar partes de Scrum, el resultado no es Scrum. Scrum existe sólo 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, debemos destacar a aquellos 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 sería refinado como lo es hoy.
Historial de la Guía Scrum
Ken Schwaber y Jeff Sutherland presentaron conjuntamente Scrum por primera vez en la Conferencia OOPSLA en 1995. Básicamente, documentó el aprendizaje que Ken y Jeff obtuvieron durante los años anteriores e hizo pública la primera definición formal de Scrum.
La Guía Scrum documenta Scrum desarrollado, evolucionado y sostenido 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 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 otra parte. Para honrar los primeros lugares donde fue probado y comprobado, reconocemos a Individual Inc., Newspage, Fidelity Investments e IDX (ahora GE Medical).
© 2020 Ken Schwaber y Jeff Sutherland Esta publicación se ofrece bajo la licencia Attribution Share-Alike de Creative Commons, accesible en https://creativecommons.org/licenses/by-sa/4.0/legalcode y también se describe en forma resumida en
