Finalidad de la Guía Scrum

Nosotros desarrollamos Scrum a principio de los años 1990. Escribimos la primera versión de la Guía Scrum en 2010 para ayudar a la gente de todo el mundo a entender Scrum. Hemos evolucionado la Guía desde entonces en actualizaciones pequeñas y funcionales. Juntos le damos apoyo.

La Guía Scrum contiene la definición de Scrum. Cada elemento sirve a un propósito específico que es esencial para el valor y resultados generales que se obtienen con Scrum. Cambiar el diseño central o las ideas de Scrum, omitiendo elementos, o no siguiendo sus las reglas, ocultan los problemas y limitan los beneficios de Scrum, potencialmente convirtiéndolo en inútil.

Seguimos el uso creciente de Scrum en un mundo donde la complejidad crece de manera continua. Nos honra ver Scrum aplicado a tantos dominios asociados fundamentalmente a trabajo complejo, más allá del desarrollo de productos de software donde Scrum tiene sus raíces. Tal como el uso de Scrum se expande, desarrolladores, investigadores, analistas, científicos y otros especialistas realizan el trabajo. Usamos la palabra “desarrollador” en Scrum para simplificar, no para excluir. Si tú obtienes valor de Scrum, puedes considerarte incluido en este término.

Mediante el uso de Scrum, se pueden encontrar, aplicar y diseñar patrones, procesos y conocimientos que encajan en este marco de trabajo, tal como se describe en este documento. Su descripción queda fuera del objetivo de la Guía Scrum porque éstos son contextuales y varían de manera amplia entre los diferentes usos de Scrum. Dichas tácticas para usar dentro del marco de trabajo Scrum están descritas en otros lugares.

Ken Schwaber y Jeff Sutherland, Julio de 2020

© 2020 Ken Schwaber y Jeff Sutherland

Esta publicación se ofrece bajo la licencia Creative Commons Atribución/Reconocimiento 4.0 Licencia Pública Internacional — CC BY 4.

This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accesible en: https://creativecommons.org/licenses/by/4.0/legalcode.es y descrito de manera resumida en https://creativecommons.org/licenses/by/4.0/deed.es. Mediante la utilización de esta Guía Scrum, reconoces haber leido y estar de acuerdo con los términos de esta Atribución.

Definición de Scrum

Scrum es un marco de trabajo ligero que ayuda a las personas, equipos y organizaciones a generar valor mediante soluciones adaptativas a problemas complejos.

En resumen, Scrum requiere un Scrum Master que fomente un entorno donde:

1. Un Propietario del Producto ordena el trabajo de un problema complejo en una Lista del Producto.
2. El Equipo Scrum convierte una selección del trabajo en un incremento de valor durante un Sprint.
3. El Equipo Scrum y los actores interesados inspeccionan los resultados y los adaptan para el siguiente Sprint.
4. Repetir.

Scrum es simple. Intenta usarlo tal como es y determina si su filosofía, teoría y estructura te ayudan a conseguir los objetivos y a crear valor. El marco de trabajo Scrum es incompleto a propósito, solo contiene las partes necesarias para implementar la teoría de Scrum. Scrum se ha construido a partir de la inteligencia colectiva de las personas que lo usan. En lugar de proporcionar sus instrucciones detalladas a la gente, las reglas de Scrum guían sus relaciones e interacciones.

Se pueden utilizar varios procesos, técnicas y métodos dentro del marco de trabajo. Scrum se adapta a las prácticas existentes o las revela innecesarias. Scrum hace visible la eficacia relativa de la gestión actual, del entorno y de las técnicas de trabajo, y gracias a esto pueden mejorarse.

Teoría de Scrum

Scrum está basado en el empirismo y en el pensamiento lean. El empirismo afirma que el conocimiento viene de la experiencia y de tomar decisiones según lo observado. El pensamiento lean reduce el desperdicio y se centra en lo esencial.

Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y controlar el riesgo. Scrum fomenta el compromiso de grupos de personas que colectivamente tienen todas las capacidades y experiencia para hacer el trabajo, y compartir o adquirir dichas capacidades según se necesite.

Scrum combina cuatro eventos formales para inspeccionar y adaptar, dentro de un evento contenedor, el Sprint. Estos eventos funcionan porque implementan los pilares del empirismo de Scrum: la transparencia, la inspección y la adaptación.

Transparencia

El proceso emergente y el trabajo deben ser visibles para aquellos que realizan el trabajo y también para aquellos que lo reciben. En Scrum, las decisiones importantes se basan en el estado percibido de sus tres artefactos formales. Los artefactos que tengan una baja transparencia pueden conducir a decisiones que disminuyan el valor e incrementen el riesgo.

La transparencia habilita la inspección. La inspección sin transparencia es engañosa y un desperdicio.

Inspección

Los artefactos de Scrum y el avance hacia las metas acordadas deben ser inspeccionados con frecuencia y esmero para detectar eventuales desviaciones o problemas. Para facilitar la inspección, Scrum proporciona una cadencia en forma de sus cinco eventos.

La inspección habilita la adaptación. La inspección sin adaptación se considera inútil. Los eventos de Scrum se han diseñado para provocar cambios.

Adaptación

Si cualquier aspecto del proceso se desvía fuera de límites aceptables, o si el producto resultado es inaceptable, el proceso aplicado o los materiales producidos deben ser adaptados. La adaptación debe hacerse tan pronto como sea posible para minimizar una mayor desviación.

La adaptación resulta más difícil cuando las personas involucradas no están empoderadas o no se autogestionan. Un Equipo Scrum debe adaptarse en el momento que aprende cualquier cosa nueva mediante la inspección.

Los valores de Scrum

El uso exitoso de Scrum depende de que las personas sean expertos en actuar según cinco valores:

Compromiso, foco, apertura, respeto y coraje

El Equipo Scrum se compromete a alcanzar sus metas y a darse soporte mutuamente. Su foco principal está en el trabajo del Sprint para avanzar lo máximo posible hacia dichas metas. El Equipo Scrum y sus actores interesados se muestran abiertos sobre el trabajo y sus retos. Los miembros del Equipo Scrum respetan la capacidad e independencia de los demás, así como reciben este respecto de las personas para las que trabajan. Los miembros del Equipo Scrum tienen el coraje de hacer lo correcto y de trabajar en problemas difíciles.

Estos valores orientan al Equipo Scrum respecto a su trabajo, acciones y conducta. Las decisiones tomadas, los pasos dados y la manera en que se usa Scrum deberían reforzar estos valores, no reducirlos ni debilitarlos. Los miembros del Equipo Scrum aprenden y exploran los valores mediante el uso de los eventos de Scrum y de los artefactos. Cuando esos valores se encarnan por el Equipo Scrum y por las personas con las que trabajan, los pilares del empirismo como la transparencia, inspección y adaptación cobran vida, generando confianza.

El Equipo Scrum

La unidad fundamental de Scrum es un equipo pequeño de personas, el Equipo Scrum. El Equipo Scrum consiste en un Scrum Master, un Propietario del Producto y Desarrolladores. Dentro de un Equipo Scrum no hay subequipos ni jerarquías. Es una unidad cohesiva de profesionales enfocados en un objetivo en cada momento, la Meta del Producto (Product Goal).

Los equipos Scrum son multifuncionales, significando que sus miembros tienen las capacidades necesarias para crear valor cada Sprint. También son autogestionados, significando que sus miembros deciden internamente quién hace qué, cuándo y cómo.

El Equipo Scrum es suficientemente pequeño para permanecer ágil y suficientemente grande para completar un trabajo significativo durante cada Sprint, típicamente está compuesto de 10 personas o menos. En general, hemos contrastado que los equipos pequeños se comunican mejor y son más productivos. Si el Equipo Scrum llega a ser demasiado grande, debería considerar reorganizarse en múltiples Equipos Scrum cohesivos, todos ellos enfocados en el mismo producto. Así pues, todos comparten la misma Meta del Producto, Lista del Producto y Propietario del Producto.

El Equipo Scrum es responsable de todas las actividades relacionadas con el producto, incluyendo la colaboración con los actores relacionados, la verificación, el mantenimiento, la operación, la experimentación, la investigación, el desarrollo y todo aquello que se necesite hacer. El Equipo Scrum está estructurado y empoderado por la organización para gestionar su propio trabajo. Trabajar en Sprints a un ritmo sostenible mejora el foco del Equipo Scrum y la consistencia. El Equipo Scrum completo es responsable de crear un incremento valioso y útil cada Sprint. Scrum define tres responsabilidades dentro del Equipo Scrum: los Desarrolladores, el Propietario del Producto y el Scrum Master.

Desarrolladores (Developers)

Los Desarrolladores son las personas del Equipo Scrum que están comprometidos en crear cualquier aspecto del Incremento usable cada Sprint.

Las capacidades específicas necesarias de los Desarrolladores son frecuentemente amplias y varían con el dominio del trabajo. En cualquier caso, los Desarrolladores son siempre responsables de:

• Crear un plan para el Sprint, la Lista del Sprint;
• Inculcar la calidad adhiriéndose a la Definición de Hecho;
• Adaptar su plan cada día hacía la Meta del Sprint; y,
• Mantenerse mutuamente responsables como profesionales.

Propietario del Producto (Product Owner)

El Propietario del Producto es responsable de maximizar el valor del producto resultante a partir del trabajo del Equipo Scrum. La manera de hacerlo varía ampliamente en las diferentes organizaciones, Equipos Scrum y personas.

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

• Desarrollar y comunicar explícitamente la Meta del Producto;
• Crear y comunicar claramente los ítems de la Lista del Producto;
• Ordenar los ítems de la Lista del Producto; y,
• Asegurar que la Lista del Producto es transparente, visible y entendida.

El Propietario del Producto puede hacer todo este trabajo o puede delegarlo a otros. En cualquier caso, el Propietario del Producto sigue siendo responsable.

El Propietario del Producto necesita que la organización entera respete sus decisiones para poder tener éxito. Estas decisiones son visibles a través del contenido y la ordenación de la Lista del Producto, así como mediante la inspección del Incremento en el Sprint Review.

El Propietario del Producto es una persona, no un comité. El Propietario del Producto puede representar las necesidades de muchas partes interesadas en la Lista del Producto. Aquellos que quieran cambiar la Lista del Producto pueden intentar convencer al Propietario del Producto.

Scrum Master

El Scrum Master es responsable de establecer Scrum tal como se define en esta Guía Scrum. Lo hace ayudando a todos a entender la teoría y la práctica de Scrum, tanto al equipo Scrum como a la organización.

El Scrum Master es responsable de la efectividad del Equipo Scrum. Lo hace habilitando al Equipo Scrum para mejorar sus prácticas, dentro del marco de trabajo Scrum. Los Scrum Masters son auténticos líderes que sirven al Equipo Scrum y al resto de la organización.

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

• Acompañando a los miembros del equipo en la autogestión y la multifuncionalidad;
• Ayudando al Equipo Scrum a enfocarse en crear incrementos de alto valor que cumplan la Definición de Hecho.
• Ayudando a eliminar impedimentos al avance del Equipo Scrum; y,
• Asegurando que todos los eventos de Scrum se realizan y son positivos, productivos, y se ajustan a su duración máxima.

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

• Ayudando a encontrar técnicas efectivas para la definición de la Meta del Producto y la gestión de la Lista del Producto;
• Ayudando al Equipo Scrum a entender la necesidad de tener ítems de la Lista del Producto claros y concisos;
• Ayudando a establecer una planificación de producto empírica para un entorno complejo; y,
• Facilitando la colaboración con las partes interesadas según sea solicitada o necesaria.

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

• Liderando, formando y acompañando a la organización en su adopción de Scrum;
• Planificando y asesorando sobre las implementaciones de Scrum en la organización;
• Ayudando a los empleados y las partes interesadas a entender y establecer una aproximación empírica para el trabajo complejo; y,
• Eliminar las barreras entre las partes interesadas y los Equipo Scrums.

Los Eventos de Scrum

El Sprint es un contenedor para todos los demás eventos. Cada evento en Scrum es una oportunidad formal de inspeccionar y adaptar los artefactos de Scrum. Estos eventos están diseñados específicamente para habilitar la transparencia requerida.

El no realizar cualquier evento tal como se prescribe resulta en oportunidades perdidas para inspeccionar y adaptar. Los eventos se usan en Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum.

De manera óptima, todos los eventos se realizan en el mismo sitio y hora para reducir la complejidad.

El Sprint

Los Sprints son los latidos de corazón de Scrum, en los cuales las ideas se transforman en valor.

Son eventos con duración fija de un mes o menos para crear consistencia. Un nuevo Sprint comienza inmediatamente tras la conclusión del Sprint anterior.

Todo el trabajo necesario para alcanzar la Meta del Producto, incluyendo el Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective forman parte del Sprint.

Durante el Sprint:

• No se permiten cambios que pongan en peligro la Meta del Sprint;
• La calidad no disminuye;
• El Lista del Producto se refina tal como sea necesario; y,
• El alcance puede ser clarificado y renegociado con el Propietario del Producto tal y como se va aprendiendo más.

Los Sprints permiten la predictibilidad asegurando que se da la inspección y la adaptación hacia la Meta del Producto al menos cada mes de calendario. Cuando el horizonte de un Sprint es demasiado largo la Meta del Sprint puede llegar a ser inválida, la complejidad puede aumentar y el riesgo incrementarse. Los sprints más cortos permiten generar más ciclos de aprendizaje y limitar el riesgo en coste y esfuerzo a un periodo temporal menor. Cada Sprint puede ser considerado como un proyecto corto.

Existen diferentes prácticas para predecir el avance, como los burn-downs, burn-ups o diagrama de flujo acumulado. A pesar de que se han demostrado útiles, éstas no reemplazan la importancia del empirismo. En un entorno complejo, se desconoce lo que sucederá. Sólo aquello que ya ha ocurrido puede utilizarse en la toma de decisiones hacia el futuro.

Un Sprint puede cancelarse si la Meta del Sprint llega a ser obsoleta. Únicamente el Propietario del Producto tiene la autoridad de cancelar un Sprint.

Planificación del Sprint (Sprint Planning)

El Sprint Planning inicia el Sprint estableciendo el trabajo a realizar durante el Sprint. El plan resultante es creado por el trabajo colaborativo del Equipo Scrum entero.

El Propietario del Producto asegura que los asistentes están preparados para discutir los ítems más importantes de la Lista del Producto y como se alinean con la Meta del Producto. El Equipo Scrum podría también invitar a otra gente a asistir a la Planificación del Sprint para dar su opinión.

La Planificación del Sprint aborda los siguientes temas:

Tema uno: ¿Por qué este Sprint crea valor?

El Propietario del Producto propone como el producto podría aumentar su valor y utilidad en el Sprint actual. El Equipo Scrum completo colabora entonces para definir una Meta del Sprint que comunique por qué el Sprint crea valor a las partes interesadas. La Meta del Sprint debe completarse antes del final de la Planificación del Sprint.

Tema dos: ¿Qué puede hacerse en este Sprint?

Los Desarrolladores seleccionan los ítems de la Lista del Producto que se incluirán en el Sprint actual de manera consensuada con el Propietario del Producto. El Equipo Scrum puede refinar estos ítems durante este proceso para aumentar su comprensión y confianza.

Seleccionar cuánto puede completarse durante el Sprint puede ser un reto. Sin embargo, cuando más saben los Desarrolladores sobre su rendimiento pasado, su disponibilidad próxima y su Definición de Hecho, más confiados pueden estar en las previsiones de los Sprints.

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

Para cada ítem seleccionado de la Lista del Producto, los Desarrolladores planifican el trabajo necesario para crear un Incremento que cumpla la Definición de Hecho. Esto se hace habitualmente descomponiendo los ítems de la Lista del Producto en ítems más pequeños de un día o menos. Esto se realiza únicamente según el criterio de los Desarrolladores. Nadie más les dice cómo convertir los ítems de la Lista del Producto en Incrementos de valor.

La Meta del Sprint, los ítems de la Lista del Producto seleccionados para el Sprint, junto con el plan para entregar éstos es lo que se llama Lista del Sprint.

La Planificación del Sprint está limitada a 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 (Daily Scrum)

La finalidad del Scrum Diario es inspeccionar el avance hacia la Meta del Sprint y adaptar la Lista del Sprint según sea necesario, ajustando el trabajo próximo planificado.

El Scrum Diario es un evento de 15 minutos para los Desarrolladores del Equipo Scrum. Para reducir la complejidad, se realiza a la misma hora y lugar de los días de trabajo del Sprint. Si el Propietario del Producto o el Scrum Master están trabajando en ítems de la Lista del Sprint, entonces participan como Desarrolladores.

Los Desarrolladores pueden usar las estructuras o técnicas que quieran, mientras su Scrum Diario se concentre en el avance hacia la Meta del Sprint y produzca un plan accionable para el siguiente día de trabajo. Esto crea foco y mejora la autogestión.

Los Scrum Diarios mejoran las comunicaciones, identifican impedimentos, promueven la toma rápida de decisiones, y así 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 durante el día para discusiones más detalladas sobre la adaptación o planificación del resto del trabajo del Sprint.

Revisión del Sprint (Sprint Review)

El objetivo de la Revisión del Sprint es inspeccionar el resultado del Sprint y determinar las adaptaciones futuras. El Equipo Scrum presenta el resultado de su trabajo a los actores interesados clave y se discute el avance hacia la Meta del Producto.

Durante el evento, el Equipo Scrum y los actores interesados revisan que se logró durante el Sprint y que ha cambiado en su entorno. Basándose en esta información, los participantes colaboran en qué hacer a continuación. La Lista del Producto puede ajustarse para cubrir nuevas oportunidades. La Revisión del Sprint es una sesión de trabajo y el Equipo Scrum debería evitar que se limite a una presentación.

La Revisión del Sprint es el penúltimo evento del Sprint y está limitado a 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 del Sprint (Sprint Retrospective)

El objetivo de la Retrospectiva del Sprint es planificar maneras de mejorar la calidad y la efectividad.

El Equipo Scrum inspecciona como fue el último Sprint respecto a las personas, las interacciones, los procesos y herramientas, así como su Definición de Hecho. Los elementos inspeccionados suelen variar con el dominio del trabajo. Las suposiciones que les hicieron equivocarse se identifican y se exploran sus orígenes. El Equipo Scrum discute que fue bien durante el Sprint, qué problemas encontraron y cómo éstos fueron, o no, solucionados.

El Equipo Scrum identifica los cambios más útiles que pueden mejorar su efectividad. Las mejoras con un impacto mayor se identifican tan pronto como sea posible, pudiendo incluso ser añadidas a la Lista del siguiente Sprint.

La Retrospectiva concluye el Sprint. Se limita a un máximo de tres horas para un Sprint de un mes. Para Sprints más cortos, el evento suele ser más corto.

Los Artefactos de Scrum

Los artefactos de Scrum representan el trabajo o el valor. Están diseñados para maximizar la transparencia de la información clave. Así, todos aquellos que los inspeccionen tendrán la misma base para la adaptación.

Cada artefacto contiene un compromiso para asegurar que éste proporciona la información que aumenta la transparencia y el foco necesarios para medir el avance:

• Para la Lista del Producto es la Meta del Producto.
• Para la Lista del Sprint es la Meta del Sprint.
• Para el Incremento es la Definición de Hecho.

Estos compromisos existen para reforzar el empirismo y los valores de Scrum en el Equipo Scrum y los actores interesados.

Lista del Producto

El Lista del Producto es una lista emergente y ordenada de aquello necesario para mejorar el producto. Es la única fuente del trabajo realizado por el Equipo Scrum.

Los ítems de la Lista del Producto que pueden entregarse “Hechos” por el Equipo Scrum durante un Sprint se consideran preparados (ready) para escogerse en un evento de Planificación del Sprint, y suelen adquirir este nivel de transparencia mediante las actividades de refinamiento. El refinamiento de la Lista del Producto es el acto de descomponer y definir con más detalle sus ítems en otros más pequeños y precisos. Esta actividad es continua en la que añaden detalles, como la descripción, el orden y el tamaño. Los atributos de los ítems suelen variar según el dominio del trabajo.

Los Desarrolladores que harán el trabajo son responsables de hacer las estimaciones. El Propietario del Producto puede influir en los Desarrolladores ayudándoles a entender y escoger entre las alternativas.

Compromiso: La Meta del Producto

La Meta del Producto describe un estado futuro del producto que puede servir al Equipo Scrum para planificar cómo llegar a este objetivo. La Meta del Producto está en la Lista del Producto. El resto de la Lista del Producto emerge para definir “qué” realizará la Meta del Producto.

Un producto es un vehículo para entregar valor. Tiene un límite claro, actores interesados conocidos, y usuarios o clientes bien definidos. Un producto puede 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. Éstos deben alcanzar (o abandonar) un objetivo antes de asumir el siguiente.

 Lista del Sprint

El Lista del Sprint se compone de la Meta del Sprint (el porqué), el conjunto de ítems de la Lista del Producto seleccionados para el Sprint (el qué), así como de un plan accionable para entregar el Incremento (el cómo).

El Lista del Sprint es un plan de y para los Desarrolladores. Es una foto muy visible y en tiempo real del trabajo que los Desarrolladores planean conseguir durante el Sprint para conseguir la Meta del Sprint.

Así pues, la Lista del Producto se actualiza durante el Sprint cuando se aprende más. Debería tener suficiente detalle para que los Desarrolladores puedan inspeccionar su avance durante el Scrum Diario.

Compromiso: La Meta del Sprint

La Meta del Sprint es el único objetivo para el Sprint. Aunque la Meta del Sprint es un compromiso de los Desarrolladores, permite flexibilidad respecto al trabajo exacto necesario para alcanzarla. La Meta del Sprint también crea coherencia y foco, motivando al Equipo Scrum para que trabajen juntos en vez de en iniciativas separadas.

La Meta del Sprint se crea durante la Planificación del Sprint y se añade a la Lista del Sprint. Los Desarrolladores tienen presente esta Meta durante su trabajo en el Sprint. Si el trabajo resulta diferente del esperado durante el Sprint, éstos colaboran con el Propietario del Producto para renegociar el alcance de la Lista del Sprint sin afectar a la Meta del Sprint.

Incremento

Un incremento es un paso intermedio hacia la Meta del Producto. Cada Incremento se agrega a los anteriores incrementos y es verificado a fondo, asegurando que todos los Incrementos funcionan juntos. Para poder ofrecer valor, el Incremento debe ser usable.

Se pueden crear múltiples incrementos durante un Sprint. La suma de los Incrementos se presenta en la Sprint Review para dar soporte al empirismo. Sin embargo, un Incremento puede entregarse a los actores interesados antes del final del Sprint. La Revisión del Sprint nunca debería considerarse una aprobación necesaria para entregar valor.

El trabajo no puede considerarse parte de un Incremento hasta que se cumple la Definición de Hecho.

Compromiso: La Definición de Hecho

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

El momento en que un ítem de la Lista del Producto cumple la Definición de Hecho, ha nacido un incremento.

La Definición de Hecho crea transparencia al proporcionar a todos un entendimiento compartido de qué trabajo se completó como parte del Incremento. Si el ítem de la Lista del Producto no cumple no cumple la Definición de Hecho, no puede ser entregado ni siquiera presentado en una Revisión de Sprint. Por contra, se devuelve al Lista del Producto para considerarlo en un futuro.

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 ésta no es un standard organizativo, el Equipo Scrum debe crear la Definición de Hecho adecuada para el producto.

Los Desarrolladores deben ajustarse a la Definición de Hecho. Si existen múltiples Equipos Scrum trabajando en un producto, deben definir mútuamente y cumplir la misma Definición de Hecho.

Nota final

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

Reconocimientos

De las miles de personas que han contribuido a Scrum, debemos destacar aquellas que fueron determinantes al principio: Jeff Sutherland trabajó con Jeff McKenna y John Scrumniotales, y Ken Schwaber trabajó con Mike Smith y Chris Martin, y todos ellos trabajaron juntos. Muchos otros han contribuido en los años posteriores, y sin su ayuda Scrum no sería tan refinado como lo es hoy.

La historia de la Guía Scrum

Ken Schwaber y Jeff Sutherland presentaron Scrum por primera vez en la conferencia OOPSLA en 1995. Básicamente documentaba el aprendizaje que Ken y Jeff habían obtenido durante los años anteriores e hizo pública la primera definición de Scrum.

La Guía Scrum documenta Scrum como fue desarrollado, evolucionado y sostenido durante más de 30 años por Jeff Sutherland y Ken Schwaber. Existen otras fuentes que proporcionan patrones, procesos y conocimientos que complementan al marco de trabajo Scrum. Estos pueden aumentar la productividad, valor, creatividad y satisfacción con los resultados.

La historia completa de Scrum se describe en otros lugares. Para honrar a los primeros sitios donde se intentó y demostró útil, reconocemos a Individual Inc., Newspage, Fidelity Investments, and IDX (ahora GE Medical).

Traducción

Esta guía ha sido traducida de la original en inglés por los siguientes

Professional Scrum Trainers de Scrum.org:

• Alex Ballarin | linkedin.com/in/alexballarin | twitter.com/AlexBallarin76
• Guillem Hernández | linkedin.com/in/guillemhs | twitter.com/guillemhs
• Joel Francia | linkedin.com/in/joelfrancia | twitter.com/joelfrah

Hemos decidido traducir todos los términos, y dejar una referencia en la cabecera de las secciones que definen los términos más importantes, como ayuda, dado que la mayoría de la literatura sobre Scrum está en inglés.