Esta versión HTML de la Guía Scrum es un port directo de la versión de noviembre de 2020 disponible como PDF aquí.

Propósito de la Guía Scrum

Desarrollamos Scrum a principios de la década de 1990. Escribimos la primera versión de la Guía Scrum en 2010 para ayudar a las personas de todo el mundo a comprender Scrum. Hemos evolucionado la Guía desde entonces a través de pequeñas actualizaciones funcionales.Juntos, lo respaldamos.

La Guía de Scrum contiene la definición de Scrum. Cada elemento del marco sirve a un propósito específico que es esencial para el valor global y los resultados obtenidos con Scrum. Cambiar el diseño o las ideas principales de Scrum, omitir elementos o no seguir las reglas de Scrum,encubre problemas y limita los beneficios de Scrum, lo que potencialmente lo hace inútil.

Seguimos el uso creciente de Scrum dentro de un mundo complejo en constante crecimiento.Nos sentimos honrados de ver que Scrum se adopta en muchos dominios que tienen un trabajo esencialmente complejo, más allá del desarrollo de productos de software, Dondeescrum tiene sus raíces. A medida que el uso de Scrum se extiende, 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 obtienes valor de Scrum, considérate incluido.

A medida que se utiliza Scrum, se pueden encontrar, aplicar y modificar patrones, procesos y conocimientos que se ajusten al marco de trabajo de Scrum descrito en este documento. Su descripción va más allá del propósito de la Guía de Scrum, ya que son sensibles al contexto y difieren ampliamente entre los usos de Scrum.Tales tácticas para usar dentro del marco de Scrum varían ampliamente y se describen en otros lugares.

Definición de Scrum

Scrum es un marco ligero que ayuda a las personas, los equipos y las organizaciones a generar valor a través de soluciones adaptativas para problemas complejos.

En pocas palabras, Scrum requiere un Maestro de Scrum para fomentar un entorno donde:

1. Un Propietario de producto ordena el trabajo para un problema complejo en un registro de producto.

2. El equipo Scrum convierte una selección del trabajo en un Incremento de valor durante un Sprint.

3. El equipo de Scrum y sus partes interesadas inspeccionan los resultados y se ajustan para el siguiente Sprint.

4. 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 está incompleto a propósito, solo definiendo las partes requeridas 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 diversos procesos, técnicas y métodos. Scrum envuelve las prácticas existentes o las hace innecesarias. Scrum hace visible la eficacia relativa de las técnicas actuales de gestión, entorno y trabajo, de modo que se puedan realizar mejoras.

Teoría de Scrum

Scrum se basa en el empirismo y el pensamiento magro. El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones basadas en lo observado. El pensamiento esbelto reduce el desperdicio y se centra en lo esencial.

Scrum emplea un enfoque iterativo e incremental para optimizar la prevención 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 de mantenimiento, el Sprint. Estos eventos funcionan porque implementan los pilares empíricos de transparencia, inspección y adaptación.

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 actos formales. Los artefactos que tienen poca transparencia pueden llevar a decisiones que disminuyen el valor y aumentan el riesgo.

La transparencia permite la inspección. La inspección sin transparencia es un derroche y un derroche.

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 la forma de sus 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, el proceso que se está aplicando o los materiales que se están produciendo deben ajustarse. El ajuste debe hacerse lo antes posible para minimizar la desviación adicional.

La adaptación se hace más difícil cuando las personas involucradas no son empoderadas o autogestionadas. Se espera que un equipo de Scrum adapte el momento para aprender cualquier cosa nueva a través de la inspección.

Valores de Scrum

El uso exitoso de Scrum depende de que las personas sean más competentes en la vida de cinco valores:

Compromiso, Enfoque, Apertura, Respeto y Coraje

El equipo de Scrum se compromete a lograr sus objetivos y apoyarse mutuamente. Su enfoque principal es el trabajo del Sprint para hacer el mejor progreso posible hacia estos objetivos. El equipo de Scrum y sus partes interesadas están abiertos sobre el trabajo y los desafíos. Los miembros del equipo Scrum se respetan entre sí para 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 dan dirección al equipo de Scrum con respecto a su trabajo,acciones y comportamiento. Las decisiones que se toman, los pasos que se toman y la forma en que se utiliza Scrum deben reforzar estos valores, no disminuirlos o disminuirlos. Los miembros del equipo de Scrum aprenden y exploran los valores al trabajar con los eventos y artefactos de Scrum. Cuando el equipo de Scrum y las personas con las que trabajan incorporan estos valores, los pilares fundamentales empíricos de transparencia, inspección y adaptación llegan a lifebuilding trust.

Scrum Team

La unidad fundamental de Scrum es un pequeño equipo de personas, un Equipo Scrum.El equipo de Scrum consta de un Maestro de Scrum, un Propietario de producto y desarrolladores. Dentro de un equipo Scrum, no hay sub-equipos o hierarchies.It es una unidad cohesiva de profesionales centrada en un objetivo a la vez, el Objetivo del Producto.

Los equipos Scrum son multifuncionales, lo que significa que los miembros tienen todas las habilidades necesarias para crear valor en cada Sprint. También 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 para completar un trabajo significativo dentro de un Sprint, generalmente 10 o menos people.In general, hemos descubierto que los equipos más pequeños se comunican mejor y son más productivos. Si los equipos de Scrum se vuelven demasiado grandes, deben considerar organizarlos en múltiples equipos de Scrum cohesivos, cada uno enfocado en el mismo producto. Por lo tanto,deben compartir el mismo Objetivo de Producto, la Acumulación de Productos y el Propietario del Producto.

El equipo de 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, y cualquier otra cosa que pueda ser necesaria. Están estructurados y empoderados por la organización para gestionar su propio trabajo. Trabajar en Sprints a un ritmo sostenible mejora el enfoque y la consistencia del equipo de Scrum.

Todo el equipo de Scrum es responsable de crear un incremento valioso y útil en cada Sprint. Scrum define tres cuentas específicas dentro del equipo Scrum: los Desarrolladores, el Propietario del Producto y el ScrumMaster.

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 a menudo son amplias y voluntariosas con el dominio del 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 de Sprint; y,

• Responsabilizándose mutuamente como profesionales.

Propietario del Producto

El Propietario del Producto es responsable de maximizar el valor del producto resultante del trabajo del equipo de Scrum. La forma en que se hace esto puede variar ampliamente entre organizaciones, equipos de Scrum e individuos.

El Propietario del Producto también es responsable de la gestión efectiva del Backlog del Producto, que incluye:

• Desarrollar y comunicar explícitamente el Objetivo del Producto;

• Crear y comunicar claramente los elementos del Backlog del Producto;

• Realizar pedidos de productos atrasados; y,

• Garantizar que el Producto atrasado sea transparente, visible y entendido.

El Propietario del Producto puede hacer el trabajo anterior o delegar la responsabilidad a otros. En cualquier caso, el Propietario del producto sigue siendo responsable.

Para que los Propietarios de productos tengan éxito, toda la organización debe respetar sus decisiones. Estas decisiones son visibles en el contenido y el orden de la cartera de Productos, y a través del incremento inspeccionable en la Revisión de impresiones.

El Propietario del producto es una persona, no un comité. El Propietario del Producto puede representar las necesidades de muchas partes interesadas en el Backlog de Productos. Aquellos que quieran cambiar el Backlog de productos pueden hacerlo tratando de convencer al Propietario del producto.

Scrum Master

El Scrum Master es responsable de establecer Scrum como se define en la Guía de Scrum. Lo hacen ayudando a todos a comprender la teoría y la práctica del Scrum, tanto dentro del equipo de Scrum como de la organización.

El Maestro de Scrum es responsable de la eficacia del Equipo de Scrum. Lo hacen permitiendo al equipo de Scrum mejorar sus prácticas, dentro del marco de Scrum.

Los Maestros de Scrum son verdaderos líderes que sirven al equipo de Scrum y a la organización más grande.

El Maestro de Scrum sirve al Equipo de Scrum de varias maneras, incluyendo:

• Entrenar a los miembros del equipo en la autogestión y la funcionalidad cruzada;

• Ayudar al Equipo de Scrum a centrarse en crear Incrementos de alto valor que cumplan con la Definición de Hecho;

• Asegurarse de que todos los eventos de Scrum tengan lugar y sean positivos, productivos y se mantengan dentro de la caja de tiempo.

El Scrum Master sirve al Propietario del Producto de varias maneras, entre ellas:

• Ayudar a encontrar técnicas para la definición efectiva de Objetivos de Producto y la gestión del Backlog de productos;

• Ayudar al equipo de Scrum a comprender la necesidad de elementos de Backlog de productos claros y concisos;

  Facilitar la colaboración de las partes interesadas según se solicite o se necesite.

El Scrum Master sirve a la organización de varias maneras, incluyendo:

• 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 las partes interesadas a comprender y aplicar un enfoque empírico para el trabajo complejo; y,

• Eliminar las barreras entre las partes interesadas y los equipos de 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 artefactos de Scrum. Estos eventos están diseñados específicamente para permitir la transparencia requerida. El fracaso para operar cualquier evento según lo prescrito resulta en la pérdida de 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.

De manera óptima, todos los eventos se celebran al mismo tiempo y en el mismo lugar para reducir la complejidad.

Los Sprints

son el latido del corazón de Scrum, donde las ideas se convierten en valor.

Son eventos de duración fija de un mes o menos para crear consistencia.Un nuevo Sprint comienza inmediatamente después de la conclusión de la impresión anterior.

Todo el trabajo necesario para lograr el Objetivo del Producto, incluida la Planificación de Sprint, los Scrums Diarios, la Revisión de Sprint y la Retrospectiva de Sprint, se lleva a cabo dentro de los Sprints.

Durante el Sprint:

• No se realizan cambios que pongan en peligro el Objetivo del Sprint;

• La calidad no disminuye;

• El Backlog de productos se refina según sea necesario; y,

• El alcance se puede aclarar y renegociar con el Propietario del Producto a medida que se aprenda más.

Los sprints permiten la previsibilidad al garantizar la inspección y la adaptación del progreso hacia un Objetivo de producto al menos cada mes calendario. Cuando el horizonte de aSprint es demasiado largo, el objetivo de 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 varias prácticas para pronosticar el progreso, como quemados, quemados o flujos acumulativos. Aunque han demostrado ser útiles, no reemplazan la importancia del empirismo. En entornos complejos, lo que sucederá es desconocido. Sólo lo que ya ha ocurrido puede utilizarse para la toma de decisiones con visión de futuro.

Un Sprint podría cancelarse si el objetivo de Sprint se vuelve obsoleto. Solo el propietario del producto tiene la autoridad para cancelar el Sprint.

Planificación de Sprint

La planificación de Sprint inicia el Sprint al trazar el trabajo que debe realizarse para el Sprint. Este plan resultante es creado por el trabajo de colaboración de todo el equipo de Scrum.

El Propietario del producto se asegura de que los asistentes estén preparados para discutir los elementos más importantes del Backlog de productos y cómo se asignan al objetivo del producto. El equipo de Scrum también puede invitar a otras personas a asistir a SprintPlanning para brindar asesoramiento.

La planificación de Sprints 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 su utilidad en el Sprint actual. Todo el equipo de Scrum colabora para definir un Objetivo de Sprint que comunique por qué el Sprint es valioso para los interesados. El Objetivo de Sprint debe finalizarse antes de finalizar la Planificación de impresiones.

Tema Dos: ¿Qué se puede hacer en este Sprint?

A través de conversaciones con el Propietario del producto, los Desarrolladores seleccionan elementos del Backlog del Producto para incluirlos en el Sprint actual. El equipo de SCRUM puede refinar estos elementos durante este proceso, lo que aumenta la comprensión y la confianza.

Seleccionar cuánto se puede completar dentro de un Sprint puede ser un desafío.Sin embargo,cuanto más sepan los Desarrolladores sobre su rendimiento pasado, su capacidad futura y su Definición de Hecho, más confiados estarán en sus pronósticos de Sprint.

Tema tres: ¿Cómo se realizará el trabajo elegido?

Para cada elemento de Backlog de producto seleccionado, los Desarrolladores planifican el trabajo necesario para crear un Incremento que cumpla con la Definición de Hecho. Esto se hace a menudo descomponiendo los elementos atrasados de productos en elementos de trabajo más pequeños de un día o menos. Cómo se hace esto es a discreción de los Desarrolladores. Nadie más les dice cómo convertir los artículos atrasados de productos en Incrementos de valor.

El Objetivo de Sprint, los elementos del Backlog de productos seleccionados para el Sprint, además del plan para entregarlos, se conocen conjuntamente como el registro de Sprint.

La planificación de Sprints tiene una duración máxima de ocho horas para una impresión de un mes. Para Sprints más cortos, el evento suele ser más corto.

Scrum diario

El propósito del Scrum Diario es inspeccionar el progreso hacia el objetivo de Sprint y adaptar el Backlog de Sprint según sea necesario, ajustando el trabajo planificado.

El Scrum Diario es un evento de 15 minutos para los Desarrolladores del equipo de Scrum. Para reducir la complejidad, se lleva a cabo a la misma hora y lugar todos los días laborables del Sprint. Si el Propietario del Producto o el Maestro de Scrum están trabajando activamente en elementos del Backlog de Sprint, participan como desarrolladores.

Los Desarrolladores pueden seleccionar la estructura y las técnicas que deseen, siempre y cuando su Scrum Diario se centre en el progreso hacia el Objetivo de Sprint y produzca un plan procesable para el siguiente día de trabajo. Esto crea un enfoque y mejora la autogestión.

Los Scrums diarios mejoran las comunicaciones, identifican impedimentos, promueven la toma rápida de decisiones 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. A menudo se reúnen a lo largo del día para discusiones más detalladas sobre la adaptación o la re-planificación del resto del trabajo del Sprint.

Revisión de Sprint

El propósito de la Revisión de Sprint es inspeccionar el resultado de la Sprint y determinar adaptaciones futuras. El equipo de 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 de Scrum y las partes interesadas revisan lo que se completó en el Sprint y lo que ha cambiado en su entorno.En base a esta información, los asistentes colaboran sobre qué hacer a continuación. La acumulación de productos también puede ajustarse para aprovechar las nuevas oportunidades. La revisión de impresiones es una sesión de trabajo y el equipo de Scrum debe evitar limitarla a una presentación.

La Revisión de Sprint es el penúltimo evento del Sprint y se establece a un máximo de cuatro horas para un Sprint de un mes. Para los shorterSprints, 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 de Scrum inspecciona cómo fue el último Sprint con respecto a individuos, interacciones, procesos, herramientas y su Definición de Hecho. Los elementos inspeccionados a menudo varían según el ámbito de trabajo. Se identifican las conjeturas que los llevaron por mal camino y se exploran sus orígenes. El equipo de Escrum discute qué fue bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.

El equipo de Scrum identifica los cambios más útiles para mejorar su eficacia. Las mejoras más impactantes se abordan lo antes posible. Incluso se pueden agregar al Backlog de Sprint para nextSprint.

La Retrospectiva del Sprint concluye el Sprint. Está programado para un máximo de tres horas para un Sprint de un mes. Para carreras cortas, 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 la misma base para la adaptación.

Cada artefacto contiene un compromiso para garantizar que proporciona información que mejora la transparencia y el enfoque con el que se puede medir el progreso:

• Para el Backlog de productos, es el Objetivo del Producto.

• Para el Backlog de Sprint, es el Objetivo de 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 de Scrum y sus grupos de interés.

Backlog de productos

El Backlog de productos es una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la única fuente de trabajo realizada por el equipo de Escrum.

Los artículos pendientes de productos que puede hacer el equipo Scrum dentro de oneSprint se consideran listos para ser seleccionados en un evento de Planificación de Sprint. Normalmente adquieren este grado de transparencia tras las actividades de refinado.El refinamiento del Backlog de productos es el acto de desglosar y definir aún más los elementos del Backlog de productos en elementos más pequeños y precisos. Esta es una actividad continua para agregar detalles, como una descripción, un pedido y un tamaño. Los atributos a menudo varían con el dominio del trabajo.

Los Desarrolladores que harán el trabajo son los responsables del diseño. El Propietario del producto puede influir en los Desarrolladores ayudándoles 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 de Scrum planifique contra él. El Objetivo del Producto está en el Backlog de productos. El resto de la Cartera de Productos surge para definir » qué » cumplirá con 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.

El Objetivo del Producto es el objetivo a largo plazo para el equipo de Scrum. Deben cumplir (o abandonar) un objetivo antes de asumir el siguiente.

Backlog de Sprint

El Backlog de Sprint está compuesto por el Objetivo de Sprint (por qué), el conjunto de elementos de Backlog de productos seleccionados para el Sprint (qué), así como un plan procesable para entregar el Incremento (cómo).

El Backlog de Sprint es un plan de 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 de Sprint.En consecuencia, el Backlog de Sprint se actualiza a lo largo del Sprint y se aprende más. Debe tener suficiente detalle para que puedan inspeccionar su progreso en el Scrum diario.

Compromiso: Objetivo de Sprint

El Objetivo de Sprint es el único objetivo del Sprint. Aunque el objetivo de impresión es un compromiso de los Desarrolladores, proporciona flexibilidad en términos del trabajo exacto necesario para lograrlo. El objetivo de Sprint también crea coherencia y enfoque, animando al equipo de Scrum a trabajar juntos en lugar de en iniciativas separadas.

El Objetivo de Sprint se crea durante el evento de Planificación de Sprint y luego se agrega al Backlog de 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 que esperaban, colaboran con el Propietario del Producto para negociar el alcance del Backlog de Sprint dentro del Sprint sin afectar el Objetivo de Impresión.

Incremento

Un incremento es un escalón concreto hacia el Objetivo del Producto. Cada incremento se añade a todos los Incrementos anteriores y se verifica a fondo,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 aumentos 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 revisión de Sprint nunca debe considerarse un valor de eliminación de puerta.

El trabajo no puede considerarse parte de un incremento a menos que cumpla con la definición de Hecho.Compromiso

: Definición de Hecho

La Definición de Hecho es una descripción formal del estado del Aumento cuando cumple con las medidas de calidad requeridas para el producto.

En el momento en que un artículo de Backlog de producto cumple con la Definición de Hecho, nace un incremento.

La Definición de Hecho crea transparencia al proporcionar a todos una comprensión compartida de qué trabajo se completó como parte del incremento. Si un artículo de Backlog de Producto no cumple con la Definición de Hecho, no se puede publicar ni presentar en la Revisión de Sprint.En su lugar, vuelve al Backlog de productos para su consideración futura.

Si la Definición de Hecho por un incremento es parte de los estándares de la organización, todos los equipos de Scrum deben seguirla como mínimo. Si no es un estándar organizacional, el equipo de Scrum debe crear una Definición de Hecho apropiada para el producto.

Se requiere que los Desarrolladores se ajusten a la Definición de Hecho. Si hay varios equipos de Scrum trabajando juntos en un producto, deben definir y cumplir con la misma Definición de Hecho.

Nota Final

Scrum es gratuito y se ofrece en esta Guía. El marco Scrum, como se describe en el presente documento, es inmutable. Si bien es posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum solo existe en su totalidad y funciona como un contenedor para otras técnicas, metodologías y prácticas.

Agradecimientos

Personas

De los miles de personas que han contribuido a Scrum, deberíamos unir a los que fueron instrumentales al principio: Jeff Sutherland trabajó con Jeff McKenna y John Scumniotales, y Ken Schwaber trabajó con Mike Smith y Chris Martin, y todos ellos trabajaron juntos. Muchos otros contribuyeron en los años siguientes y sin su ayuda el Scrum no se refinaría como lo es hoy en día.

Historia de la Guía de Scrum

Ken Schwaber y Jeff Sutherland presentaron por primera vez Scrum en la Conferencia OOPSL en 1995. En esencia, documentó el aprendizaje que Ken y Jeff adquirieron en los años anteriores e hizo pública la primera definición formal de Scrum.

La Guía Scrum documenta Scrum como 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 Scrum.Esto puede aumentar la productividad, el valor, la creatividad y la satisfacción con los resultados.

El historial completo de Scrum se describe en otra parte. Para honrar los primeros lugares donde se probó y probó, 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 de atribución compartida de Creative Commons, accesible atttps: / / creativecommons.org/licenses/by-sa/4.0/legalcode y también se describe en forma resumida en atttps://creativecommons.org/licenses/by-sa/4.0/. Al utilizar esta guía de Scrum, usted reconoce y acepta que ha leído y acepta cumplir con los términos de la licencia de Atribución Compartida de CreativeCommons.