La guía Scrum 2020MT.
Propósito de la Guía Scrum
Desarrollamos Scrum a principios de los años 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 a través de pequeñas actualizaciones funcionales. Juntos, la respaldamos.
La Guía de Scrum contiene la definición de Scrum. Cada elemento del marco cumple un propósito específico que es esencial para el valor general y los resultados obtenidos con Scrum. Cambiar el diseño o las ideas centrales de Scrum, omitir elementos o no seguir las reglas de Scrum, encubre problemas y limita los beneficios de Scrum, incluso puede volverlo inútil.
Seguimos de cerca el uso creciente de Scrum en un mundo cada vez más complejo. Nos sentimos honrados de ver que Scrum se está adoptando en muchos dominios que implican un trabajo esencialmente complejo, más allá del desarrollo de productos de software, donde Scrum tiene sus raíces. A medida que se extiende el uso de Scrum, los desarrolladores, investigadores, analistas, científicos y otros especialistas hacen el trabajo. En Scrum, utilizamos la palabra "desarrolladores" no para excluir, sino para simplificar. Si obtiene valor de Scrum, considérese incluido.
A medida que se utiliza Scrum, se pueden encontrar, aplicar y diseñar patrones, procesos y conocimientos 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 de Scrum porque son sensibles al contexto y difieren ampliamente entre los usos de Scrum. Estas tácticas para usar dentro del marco de trabajo de Scrum varían ampliamente y se describen en otras partes.
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 como está y determine si su filosofía, teoría y estructura ayudan a lograr objetivos y 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 a partir de 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.
Se pueden emplear diversos procesos, técnicas y métodos dentro del marco. 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, 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 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, en conjunto, tienen todas las habilidades y la experiencia para hacer 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 para quienes realizan el trabajo y 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 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 una 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 cambios.
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 que se producen. El ajuste debe realizarse lo antes posible para minimizar las desviaciones futuras.
La adaptación se vuelve más difícil cuando las personas involucradas no están empoderadas o no se autogestionan. Se espera que un equipo Scrum se adapte en el momento en que aprende 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 alcanzar sus objetivos y a apoyarse mutuamente. Su principal objetivo es el trabajo del Sprint para lograr el mayor progreso posible hacia estos objetivos. El equipo Scrum y sus partes interesadas son abiertos respecto del trabajo y los desafíos. Los miembros del equipo Scrum se respetan entre sí por ser 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, de trabajar en problemas difíciles.
Estos valores orientan al equipo Scrum en lo que respecta a su trabajo, sus acciones y su 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 a medida que trabajan con los eventos y artefactos de Scrum. Cuando estos valores están incorporados 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 y generan confianza.
Equipo Scrum
La unidad fundamental de Scrum es un pequeño equipo de personas, un Equipo Scrum. El Equipo Scrum está formado 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 tienen todas las habilidades necesarias para crear valor en cada sprint. También se autogestionan, lo que significa que deciden internamente quién hace qué, cuándo y cómo.
El 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, normalmente 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 la posibilidad de reorganizarse en varios equipos Scrum cohesivos, cada uno centrado en el mismo producto. Por lo tanto, deberían compartir el mismo objetivo de producto, el mismo backlog de producto y el mismo propietario del 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 cosa que pueda ser necesaria. La organización los estructura y les otorga la autoridad para gestionar su propio trabajo. Trabajar en sprints a un ritmo sostenible mejora el enfoque y la coherencia 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 propietario del producto es responsable de maximizar el valor del producto resultante del trabajo del equipo Scrum. La forma de hacerlo puede variar ampliamente 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;
- Solicitar elementos del Product Backlog; y,
- Asegurarse de que el Product Backlog sea transparente, visible y comprendido.
El propietario del producto puede realizar el trabajo mencionado anteriormente o puede delegar la responsabilidad a otros. En cualquier caso, 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 Revisión del Sprint.
El Product Owner 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.
Maestro Scrum
El Scrum Master es responsable de establecer Scrum tal como se define en la Guía de Scrum. Lo hace ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Equipo Scrum como de la organización.
El Scrum Master es responsable de la eficacia del equipo Scrum y lo hace permitiendo que el equipo 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 multifuncionalidad;
- 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,
- Garantizar 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
- Eliminar 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 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. Si no se ejecutan los eventos 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 lugar para reducir la complejidad.
El sprint
Los sprints son el corazón de Scrum, donde las ideas se convierten en valor.
Son eventos de duración fija de un mes o menos para crear consistencia. Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.
Todo el trabajo necesario para 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 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 volverse invá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 marco de tiempo más pequeño. Cada sprint puede considerarse un proyecto corto.
Existen diversas prácticas para pronosticar el progreso, como el burn-down, el burn-up o los flujos acumulativos. Si bien han demostrado ser útiles, no reemplazan la importancia del empirismo. En entornos complejos, se desconoce lo que sucederá. Solo lo que ya sucedió puede usarse para tomar decisiones con visión de futuro.
Se podría cancelar un Sprint si el Objetivo del Sprint se vuelve 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 estableciendo el trabajo que se realizará durante el mismo. El 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 analizar 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 participar en la planificación del sprint para brindar asesoramiento.
La planificación del sprint aborda los siguientes temas:
Tema uno: ¿Por qué es valioso este Sprint?
El propietario del producto 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 del sprint que comunique por qué el sprint es valioso para las partes interesadas. El objetivo del sprint debe definirse antes de que finalice la planificación del sprint.
Tema dos: ¿Qué se puede hacer en este sprint?
A través de una conversación con el Product Owner, los desarrolladores seleccionan elementos del Product Backlog para incluirlos 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 en 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 Finalizado, más confianza tendrán en sus pronósticos para el Sprint.
Tema tres: ¿Cómo se realizará el trabajo elegido?
Para cada elemento seleccionado del Product Backlog, los desarrolladores planifican el trabajo necesario para crear un incremento que cumpla con la definición de terminado.Esto se hace a menudo descomponiendo los elementos del Product Backlog en elementos de trabajo más pequeños de un día o menos. La forma de hacerlo queda a criterio exclusivo de los 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 y el plan para entregarlos se denominan en conjunto Sprint Backlog.
La planificación del sprint tiene un límite de tiempo máximo de ocho horas para un sprint de un mes. En el caso de sprints más cortos, el evento suele ser más breve.
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 en el mismo 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 las técnicas que deseen, siempre que su Daily Scrum se centre en el progreso hacia el objetivo del sprint y produzca un plan viable para el siguiente día de trabajo. Esto genera concentración y mejora la autogestión.
Los Scrums diarios mejoran las comunicaciones, identifican impedimentos, promueven una toma de decisiones rápida y, en consecuencia, eliminan 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 debatir con más detalle sobre la adaptación o la replanificación del resto del trabajo del Sprint.
Revisión de Sprint
El objetivo de la revisión del sprint es inspeccionar el resultado del sprint y determinar las adaptaciones futuras. El equipo Scrum presenta los resultados de su trabajo a las partes interesadas clave y se analiza 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 cambió 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 satisfacer 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 en el caso de los sprints de un mes. En el caso de los sprints más cortos, el evento suele ser más breve.
Retrospectiva del sprint
El propósito de la Retrospectiva del Sprint es planificar formas de aumentar la calidad y la eficacia.
El equipo Scrum examina cómo se desarrolló el último Sprint en lo que respecta a las personas, las interacciones, los procesos, las herramientas y su definición de finalizado. Los elementos inspeccionados suelen variar según el dominio de trabajo. Se identifican los supuestos que los llevaron por mal camino 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 eficacia. Las mejoras más impactantes se abordan lo antes posible. Incluso pueden añadirse al Sprint Backlog para el próximo Sprint.
La retrospectiva del sprint concluye el sprint. Su duración máxima es de tres horas en el caso de los sprints de un mes. En el caso de los sprints más cortos, el evento suele ser más breve.
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 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.
Cartera de productos
El Product Backlog es una lista ordenada y emergente de lo que se necesita para mejorar el producto. Es la única fuente de trabajo que lleva a cabo el equipo Scrum.
Los elementos del Product Backlog que el equipo Scrum puede realizar en un sprint se consideran listos para su selección en un evento de planificación del sprint. Por lo general, adquieren este grado de transparencia después de las actividades de refinamiento. El refinamiento del Product Backlog es el acto de dividir y definir con más detalle los elementos del Product Backlog en elementos más pequeños y precisos. Se trata de una actividad continua para agregar detalles, como una descripción, un orden y un tamaño. Los atributos suelen variar según el dominio 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 las 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 se encuentra en el Product Backlog. El resto del Product Backlog surge para definir “qué” cumplirá con el objetivo del producto.
Un producto es un vehículo para ofrecer 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 asumir el siguiente.
Lista de tareas pendientes 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. 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 Backlog del Sprint se actualiza durante el Sprint a medida que se aprende más. Debe tener suficiente detalle para que puedan inspeccionar su progreso en el Scrum Diario.
Compromiso: Objetivo del sprint
El objetivo del sprint es el único objetivo del sprint. Aunque 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 en conjunto en lugar de hacerlo en iniciativas separadas.
El objetivo del sprint se crea durante el evento de planificación del sprint y luego se agrega al backlog del sprint. A medida que los desarrolladores trabajan durante el sprint, tienen en cuenta el objetivo del sprint. Si el trabajo resulta ser diferente de lo esperado, colaboran con el propietario del producto para negociar el alcance del backlog del sprint dentro 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 incrementos anteriores y se verifica minuciosamente, lo que garantiza que todos los incrementos funcionen en conjunto. 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 la Revisión del Sprint, lo que respalda el empirismo.Sin embargo, se puede entregar un Incremento a las partes interesadas antes de que finalice el 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 crea transparencia al brindar 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 presentar en la revisión del sprint. En cambio, regresa al Product Backlog para su consideración futura.
Si la Definición de Finalizado 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 Finalizado adecuada para el producto.
Los desarrolladores deben cumplir con la definición de "terminado". Si hay varios equipos Scrum trabajando 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 trabajo de Scrum, tal como se describe en este documento, es inmutable. Si bien es posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum existe solo en su totalidad y funciona bien como un contenedor para otras técnicas, metodologías y prácticas.
Expresiones de gratitud
Gente
De las miles de personas que han contribuido a Scrum, debemos destacar a aquellas que fueron fundamentales en el comienzo: 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 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. Básicamente, 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 parte de 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 otro lugar. Para honrar a 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 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 que ha leído y acepta estar sujeto a los términos de la licencia Atribución Compartir Igual de Creative Commons.
