La Guía Scrum 2020Marca registrada
Propósito de la Guía Scrum
Desarrollamos Scrum a principios de los 90. Redactamos la primera versión de la Guía de Scrum en 2010 para ayudar a personas de todo el mundo a comprenderlo. Desde entonces, hemos ido evolucionando la Guía mediante pequeñas actualizaciones funcionales. Juntos, la respaldamos.
La Guía de Scrum contiene la definición de Scrum. Cada elemento del marco cumple un propósito específico, esencial para el valor general y los resultados obtenidos con Scrum. Cambiar el diseño o las ideas centrales de Scrum, omitir elementos o no seguir las reglas de Scrum, encubre problemas y limita sus beneficios, incluso volviéndolo potencialmente inútil.
Seguimos el creciente uso de Scrum en un mundo cada vez más complejo. Nos honra ver su adopción en numerosos ámbitos que abarcan tareas esencialmente complejas, más allá del desarrollo de productos de software, donde Scrum tiene sus raíces. A medida que se extiende su uso, desarrolladores, investigadores, analistas, científicos y otros especialistas realizan el trabajo. En Scrum, usamos el término "desarrolladores" no para excluir, sino para simplificar. Si Scrum te aporta valor, considérate incluido.
A medida que se utiliza Scrum, se pueden encontrar, aplicar y diseñar patrones, procesos e ideas que se ajusten al marco de Scrum, tal como se describe en este documento. Su descripción excede el propósito de la Guía de Scrum, ya que son contextuales y difieren considerablemente entre los usos de Scrum. Estas tácticas para su uso dentro del marco de Scrum varían considerablemente y se describen en otras secciones.
Definición de Scrum
Scrum es un marco ligero 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 que un Scrum Master fomente un entorno donde:
- Un propietario de producto ordena el trabajo para resolver 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 cual y determine si su filosofía, teoría y estructura ayudan a alcanzar objetivos y a crear valor. El marco de Scrum es intencionalmente incompleto, ya que solo define las partes necesarias para implementar la teoría de Scrum. Scrum se construye gracias a la inteligencia colectiva de quienes lo utilizan. En lugar de proporcionar instrucciones detalladas a las personas, las reglas de Scrum guían sus relaciones e interacciones.
Se pueden emplear diversos procesos, técnicas y métodos dentro del marco. Scrum integra 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, 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 basada en la observación. 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, en conjunto, poseen todas las habilidades y la experiencia necesarias para realizar el trabajo y comparten o adquieren dichas habilidades según sea necesario.
Scrum combina cuatro eventos formales de 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.
Transparencia
El proceso y el trabajo emergentes deben ser visibles tanto para quienes lo realizan 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 baja transparencia pueden conducir a decisiones que disminuyen el valor y aumentan el riesgo.
La transparencia facilita 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 posibles variaciones o problemas indeseables. Para facilitar la inspección, Scrum proporciona una cadencia en forma de cinco eventos.
La inspección facilita 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.
Adaptación
Si algún aspecto de un proceso se desvía de los límites aceptables o si el producto resultante es inaceptable, se debe ajustar el proceso aplicado o los materiales producidos. El ajuste debe realizarse lo antes posible para minimizar cualquier desviación adicional.
La adaptación se vuelve más difícil cuando las personas involucradas no están empoderadas ni se autogestionan. Se espera que un equipo Scrum se adapte en cuanto aprende algo nuevo mediante 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 alcanzar sus objetivos y a apoyarse mutuamente. Su enfoque principal es el trabajo del Sprint para lograr el mayor progreso posible hacia estos objetivos. El Equipo Scrum y sus partes interesadas son transparentes con respecto al trabajo y los desafíos. Los miembros del Equipo Scrum se respetan mutuamente por ser personas capaces e independientes, y como tales son respetados por quienes trabajan con ellos. Los miembros del Equipo Scrum tienen la valentía de hacer lo correcto y de trabajar en problemas complejos.
Estos valores orientan al Equipo Scrum en cuanto a su trabajo, acciones y comportamiento. Las decisiones, los pasos y la forma de utilizar Scrum deben reforzar estos valores, no disminuirlos ni socavarlos. Los miembros del Equipo Scrum aprenden y exploran los valores al trabajar con los eventos y artefactos de Scrum. Cuando el Equipo Scrum y las personas con las que colabora encarnan estos valores, los pilares empíricos de Scrum: transparencia, inspección y adaptación, cobran vida y generan confianza.
Equipo Scrum
La unidad fundamental de Scrum es un pequeño equipo de personas: el Equipo Scrum. El Equipo Scrum está compuesto por un Scrum Master, un Dueño de Producto y Desarrolladores. Dentro de un Equipo Scrum, no hay subequipos 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 sus miembros poseen todas las habilidades necesarias para generar valor en cada sprint. Además, se autogestionan, 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 mantenerse ágil y lo suficientemente grande como para completar trabajo significativo dentro de un Sprint, típicamente de 10 personas o menos. En general, hemos observado 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 varios Equipos Scrum cohesionados, cada uno enfocado en el mismo producto. Por lo tanto, deberían compartir el mismo Objetivo de Producto, el mismo Backlog de Producto y el mismo Dueño de Producto.
El Equipo Scrum es responsable de todas las actividades relacionadas con el producto, desde la colaboración con las partes interesadas, la verificación, el mantenimiento, la operación, la experimentación, la investigación y el desarrollo, hasta cualquier otra que pueda requerirse. La organización los estructura y les otorga la autoridad para gestionar su propio trabajo. Trabajar en sprints a un ritmo sostenible mejora la concentración y la consistencia del Equipo Scrum.
Todo el equipo Scrum es responsable de crear un incremento valioso y útil en cada Sprint.Scrum define tres responsabilidades específicas dentro del Equipo Scrum: los Desarrolladores, el Propietario del Producto y el Scrum Master.
Desarrolladores
Los desarrolladores son las personas del equipo Scrum que están comprometidas a crear cualquier aspecto de un incremento utilizable en cada sprint.
Las habilidades específicas que necesitan los desarrolladores suelen ser amplias y varían según el ámbito de trabajo. Sin embargo, los desarrolladores siempre son responsables de:
- Creación de un plan para el Sprint, el Sprint Backlog;
- Inculcar calidad mediante la adhesión a una Definición de Hecho;
- Adaptar su plan cada día hacia el objetivo del Sprint; y,
- Haciéndonos responsables unos a otros como profesionales.
Propietario del producto
El Dueño del Producto es responsable de maximizar el valor del producto resultante del trabajo del Equipo Scrum. La forma de lograrlo puede variar considerablemente entre organizaciones, Equipos Scrum e individuos.
El propietario del producto también es responsable de la gestión eficaz del Product Backlog, que incluye:
- Desarrollar y comunicar explícitamente el Objetivo del Producto;
- Crear y comunicar claramente los elementos del Product Backlog;
- Ordenar elementos del Product Backlog; y,
- Asegurarse de que el Product Backlog sea transparente, visible y comprendido.
El Dueño del Producto puede realizar el trabajo mencionado o delegar la responsabilidad a otros. En cualquier caso, el Dueño del Producto sigue siendo responsable.
Para que los Product Owners tengan éxito, toda la organización debe respetar sus decisiones. Estas decisiones se reflejan en el contenido y el orden del Product Backlog, y mediante el Incremento inspeccionable en la Revisión del Sprint.
El Dueño del Producto es una sola persona, no un comité. Puede representar las necesidades de muchas partes interesadas en el Backlog del Producto. Quienes deseen cambiar el Backlog del Producto pueden hacerlo intentando convencer al Dueño del Producto.
Scrum Master
El Scrum Master es responsable de establecer Scrum según 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 Equipo Scrum como en la organización.
El Scrum Master es responsable de la efectividad del Equipo Scrum. Lo hace al permitir 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 equipo Scrum de varias maneras, entre ellas:
- Capacitar a los miembros del equipo en autogestión y transversalidad;
- Ayudar al equipo Scrum a centrarse en la creación de incrementos de alto valor que cumplan con la definición de terminado;
- Provocar la eliminación de impedimentos al progreso del Equipo Scrum; y,
- Asegurarse de 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 contar con elementos claros y concisos en el 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 entrenar 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 a las partes interesadas a comprender y aplicar un enfoque empírico para el trabajo complejo; y
- Eliminando barreras entre las partes interesadas y los equipos Scrum.
Eventos Scrum
El Sprint es un contenedor para todos los demás eventos. Cada evento en Scrum representa una oportunidad formal para inspeccionar y adaptar los artefactos de Scrum. Estos eventos están diseñados específicamente para permitir la transparencia requerida. Si no se ejecuta algún evento según lo prescrito, se pierden oportunidades de inspección y adaptación. 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 transforman en valor.
Son eventos de duración fija, de un mes o menos, para mantener la consistencia. Un nuevo sprint comienza inmediatamente después de la conclusión del sprint anterior.
Todo el trabajo necesario para alcanzar 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 pongan 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 facilitan la previsibilidad al garantizar la inspección y adaptación del progreso hacia un Objetivo de Producto al menos una vez al mes. 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. Se pueden emplear sprints más cortos para generar más ciclos de aprendizaje y limitar el riesgo de costo y esfuerzo a un plazo más corto. Cada sprint puede considerarse un proyecto corto.
Existen diversas prácticas para pronosticar el progreso, como las quemas, las quemas al alza o los flujos acumulativos. Si bien han demostrado su utilidad, estas no reemplazan la importancia del empirismo. En entornos complejos, se desconoce qué sucederá. Solo lo que ya ha sucedido puede utilizarse para la toma de decisiones prospectiva.
Un Sprint podría cancelarse si el Objetivo del Sprint queda obsoleto. Solo el Dueño del Producto tiene la autoridad para cancelar el Sprint.
Planificación de sprints
La Planificación del Sprint inicia el Sprint definiendo el trabajo a realizar. Este plan resultante se crea mediante el trabajo colaborativo de todo el Equipo Scrum.
El Dueño del Producto se asegura de que los asistentes estén preparados para debatir los elementos más importantes del Backlog del Producto y su relación con el Objetivo del Producto. El Equipo Scrum también puede invitar a otras personas a la Planificación del Sprint para que brinden asesoramiento.
La planificación del sprint aborda los siguientes temas:
Tema uno: ¿Por qué es valioso este Sprint?
El Dueño del Producto propone cómo el producto podría aumentar su valor y utilidad en el Sprint actual. A continuación, todo el Equipo Scrum colabora para definir un Objetivo del Sprint que comunique el valor del Sprint a las partes interesadas. El Objetivo del Sprint debe definirse antes de finalizar la Planificación del Sprint.
Tema dos: ¿Qué se puede hacer en este sprint?
Tras hablar con el Dueño del Producto, los Desarrolladores seleccionan elementos del Backlog del Producto para incluirlos en el Sprint actual. El Equipo Scrum puede refinarlos durante este proceso, lo que aumenta la comprensión y la confianza.
Determinar cuánto se puede completar en un sprint puede ser un desafío. Sin embargo, cuanto mejor conozcan los desarrolladores sobre su rendimiento pasado, su capacidad futura y su Definición de Finalizado, más seguros estarán de sus pronósticos para el sprint.
Tema tres: ¿Cómo se realizará el trabajo elegido?
Para cada elemento del Product Backlog seleccionado, los desarrolladores planifican el trabajo necesario para crear un incremento que cumpla con la definición de terminado.Esto suele lograrse 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 discreción exclusiva de los desarrolladores. Nadie más les indica 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 y el plan para entregarlos se denominan en conjunto Sprint Backlog.
La planificación del sprint tiene una duración máxima 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 simplificar, se realiza a la misma hora y en el mismo lugar todos los días laborables del Sprint. Si el Dueño del Producto o el Scrum Master trabajan activamente en elementos del Backlog del Sprint, participan como Desarrolladores.
Los Desarrolladores pueden seleccionar la estructura y las técnicas que deseen, siempre que su Scrum Diario se centre en el progreso hacia el Objetivo del Sprint y genere un plan viable para el siguiente día de trabajo. Esto fomenta la concentración y mejora la autogestión.
Los Scrums diarios mejoran las comunicaciones, identifican impedimentos, promueven la toma de decisiones rápida y, en consecuencia, eliminan la necesidad de otras reuniones.
El Scrum Diario no es el único momento en que los Desarrolladores pueden ajustar su plan. Suelen reunirse a lo largo del día para debatir con mayor detalle sobre la adaptación o replanificación del resto del trabajo del Sprint.
Revisión del sprint
El propósito de la Revisión del Sprint es inspeccionar los resultados del Sprint y determinar futuras adaptaciones. 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 los logros del Sprint y los cambios en su entorno. Con base en esta información, los asistentes colaboran para determinar los pasos a seguir. El Product Backlog también puede ajustarse para abordar nuevas oportunidades. La Revisión del Sprint es una sesión de trabajo y el Equipo Scrum debe evitar limitarla a una presentación.
La Revisión del Sprint es el penúltimo evento del Sprint y tiene una duración máxima de cuatro horas para un Sprint de un mes. Para Sprints más cortos, el evento suele ser más corto.
Retrospectiva del sprint
El propósito de la Retrospectiva del Sprint es planificar formas de aumentar la calidad y la eficacia.
El Equipo Scrum inspecciona el desarrollo del último Sprint en cuanto a individuos, interacciones, procesos, herramientas y su Definición de Terminado. Los elementos inspeccionados suelen variar según el dominio de trabajo. Se identifican las suposiciones que los llevaron al error y se exploran sus orígenes. El Equipo Scrum analiza qué salió bien durante el Sprint, qué problemas se encontraron 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 implementan lo antes posible. Incluso pueden añadirse al Backlog del Sprint para el siguiente Sprint.
La Retrospectiva del Sprint concluye el Sprint. Su duración máxima es 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, quienes los inspeccionan tienen la misma base para la adaptación.
Cada artefacto contiene el compromiso de garantizar que proporciona información que mejora la transparencia y el enfoque con el que 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 partes interesadas.
Backlog del producto
El Product Backlog es una lista emergente y ordenada de lo necesario para mejorar el producto. Es la única fuente de trabajo del Equipo Scrum.
Los elementos del Product Backlog 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. Generalmente, adquieren este grado de transparencia tras actividades de refinamiento. El refinamiento del Product Backlog consiste en desglosar y definir con mayor precisión los elementos del Product Backlog en elementos más pequeños y precisos. Esta es una actividad continua para agregar detalles, como la descripción, el orden y el tamaño. Los atributos suelen variar según el dominio de trabajo.
Los desarrolladores que realizarán el trabajo son responsables del dimensionamiento. El Dueño del Producto puede influir en los desarrolladores ayudándolos a comprender y seleccionar las compensaciones.
Compromiso: Objetivo del producto
El Objetivo del Producto describe un estado futuro del producto que puede servir como meta para que el Equipo Scrum planifique. El Objetivo del Producto se encuentra en el Backlog del Producto. El resto del Backlog del Producto define qué permitirá alcanzar el Objetivo del Producto.
Un producto es un vehículo para generar valor. Tiene un límite claro, partes interesadas conocidas y 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 Equipo Scrum. Deben cumplir (o abandonar) un objetivo antes de abordar el siguiente.
Backlog del 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 de acción para entregar el Incremento (cómo).
El Backlog del Sprint es un plan creado por y para los Desarrolladores. Ofrece una visión clara y en tiempo real del trabajo que los Desarrolladores planean realizar durante el Sprint para alcanzar el Objetivo del Sprint. Por consiguiente, el Backlog del Sprint se actualiza a lo largo del Sprint a medida que se aprende más. Debe ser lo suficientemente detallado como para que puedan inspeccionar su progreso en el Scrum Diario.
Compromiso: Objetivo del sprint
El Objetivo del Sprint es el único objetivo del Sprint. Si bien es un compromiso de los Desarrolladores, proporciona flexibilidad en cuanto al trabajo exacto necesario para lograrlo. Además, genera coherencia y enfoque, animando al Equipo Scrum a trabajar en conjunto en lugar de en iniciativas separadas.
El Objetivo del Sprint se crea durante la Planificación del Sprint y luego se añade al Backlog del Sprint. Durante el Sprint, los Desarrolladores tienen presente el Objetivo del Sprint. Si el trabajo resulta diferente a lo previsto, colaboran con el Dueño del Producto para negociar el alcance del Backlog del Sprint sin afectar el Objetivo del Sprint.
Incremento
Un Incremento es un paso concreto hacia el Objetivo del Producto. Cada Incremento se suma a todos los anteriores y se verifica exhaustivamente, lo que garantiza que todos funcionen en conjunto. Para aportar valor, el Incremento debe ser utilizable.
Se pueden crear múltiples incrementos dentro de un sprint. La suma de los incrementos se presenta en la revisión del sprint, lo que respalda el empirismo.Sin embargo, se puede entregar un Incremento a las partes interesadas antes de la finalización del Sprint. La Revisión del Sprint 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 Terminado.
Compromiso: Definición de Hecho
La Definición de Terminado 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 Terminado, nace un Incremento.
La Definición de Terminado genera transparencia al proporcionar a todos un entendimiento común del trabajo completado como parte del Incremento. Si un elemento del Backlog del Producto no cumple con la Definición de Terminado, no puede publicarse ni presentarse en la Revisión del Sprint. En su lugar, regresa al Backlog del Producto para su posterior consideración.
Si la Definición de Terminado para un incremento forma parte de los estándares de la organización, todos los Equipos Scrum deben seguirla como mínimo. Si no es un estándar de la organización, el Equipo Scrum debe crear una Definición de Terminado adecuada para el producto.
Los desarrolladores deben cumplir con la Definición de Terminado. Si varios equipos Scrum trabajan juntos en un producto, deben definir y cumplir mutuamente con la misma Definición de Terminado.
Nota final
Scrum es gratuito y se ofrece en esta Guía. El marco de Scrum, tal 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 contenedor de otras técnicas, metodologías y prácticas.
Expresiones de gratitud
Gente
De las miles de personas que han contribuido a Scrum, debemos destacar a quienes fueron fundamentales en sus inicios: 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 posteriores y, sin su ayuda, Scrum no se habría perfeccionado como lo es hoy.
Historia de la Guía Scrum
Ken Schwaber y Jeff Sutherland presentaron Scrum por primera vez en la Conferencia OOPSLA en 1995. En esencia, documentaron el aprendizaje que Ken y Jeff adquirieron durante los años anteriores e hicieron pública la primera definición formal de Scrum.
La Guía de Scrum documenta el desarrollo, la evolución y la sostenibilidad de Scrum durante más de 30 años por Jeff Sutherland y Ken Schwaber. Otras fuentes proporcionan patrones, procesos y perspectivas 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 a los primeros lugares donde se probó y demostró su eficacia, 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 https://creativecommons.org/licenses/by-sa/4.0/Al utilizar esta Guía de Scrum, usted reconoce y acepta haber leído y estar sujeto a los términos de la licencia Atribución-Compartir-Igual de Creative Commons.
