Traducido del inglés al español - www.onlinedoctranslator.

com

Ken Schwaber y Jeff Sutherland

La guía Scrum
La guía definitiva de Scrum: Las reglas del juego

noviembre 2020
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 desarrollado 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 tiene un propósito específico
que es esencial para el valor general y los resultados obtenidos con Scrum. Cambiar el diseño central o las
ideas de Scrum, omitir elementos o no seguir las reglas de Scrum, encubre los problemas y limita los
beneficios de Scrum, e incluso puede volverlo 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 realizan 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. Usamos la palabra "desarrolladores" en Scrum no

para excluir, sino para simplificar. Si obtiene valor de Scrum, considérese incluido.

A medida que se utiliza Scrum, se pueden encontrar, aplicar 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 va 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. Tales tácticas para usar dentro
del marco Scrum varían ampliamente y se describen en otra parte.

Ken Schwaber y Jeff Sutherland Noviembre de 2020

© 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 resumen
formatohttps://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 Atribución.
Licencia Share-Alike de Creative Commons.

1
Propósito de la Guía Scrum ............................................... .................................................... ..........................1

Definición de scrum .................................................. .................................................... ..........................................3

Teoría Scrum ................................................. .................................................... ...............................................3

Transparencia .................................................. .................................................... ..........................................3

Inspección .................................................. .................................................... ..........................................................4

Adaptación .................................................. .................................................... .............................................4

Valores Scrum ................................................. .................................................... ..........................................................4

Equipo Scrum .................................................. .................................................... ..................................................5

Desarrolladores .................................................. .................................................... .............................................5

Dueño del producto................................................ .................................................... .............................................5

Maestro Scrum................................................... .................................................... ..........................................6

Eventos Scrum ................................................. .................................................... ...............................................7

El Sprint.................................................. .................................................... ..................................................7

Planificación de Sprint ................................................. .................................................... .......................................8

Scrum diario .................................................. .................................................... .............................................9

Revisión de Sprint ................................................ .................................................... ..........................................9

Retrospectiva de Sprint .............................................. .................................................... .............................10

Artefactos de Scrum ................................................. .................................................... ..........................................10

Pila de Producto ................................................ .................................................... .....................................10

Compromiso: Objetivo del producto ........................................... .................................................... ..........11

Cartera de Sprint .................................................. .................................................... ..........................................11

Compromiso: Sprint Goal ............................................... .................................................... ....................11

Incremento................................................. .................................................... .............................................11

Compromiso: Definición de Hecho ............................................... .................................................... ........12

Nota final .................................................. .................................................... .................................................... ..13

Agradecimientos ................................................. .................................................... ..............................13

Gente ................................................. .................................................... ...............................................13

Historial de la guía Scrum ............................................... .................................................... ..........................13

2
Definición de melé
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 Scrum Master para fomentar un entorno en el que:

1. Un Product Owner ordena el trabajo de un problema complejo en un Product Backlog.

2. El Equipo Scrum convierte una selección del trabajo en un Incremento de valor durante un Sprint.
3. El Equipo Scrum y sus partes interesadas inspeccionan los resultados y los ajustan para el próximo 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 Scrum está intencionalmente incompleto, solo define las partes necesarias para implementar la
teoría 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.

Se pueden emplear varios 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 las
técnicas actuales de gestión, ambiente y trabajo, para que se puedan realizar mejoras.

Teoría de Scrum
Scrum se basa en el empirismo y el pensamiento lean. El empirismo afirma que el conocimiento proviene de la
experiencia y de la toma de decisiones en base a lo observado. El pensamiento Lean reduce el desperdicio y se enfoca en
lo esencial.

Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo. Scrum involucra a grupos

de personas que colectivamente tienen todas las habilidades y la experiencia para hacer el trabajo y compartir o adquirir tales

habilidades según sea necesario.

Scrum combina cuatro eventos formales para inspección y adaptación dentro de un evento contenedor, el Sprint.
Estos eventos funcionan porque implementan los pilares empíricos de Scrum de transparencia, inspección y
adaptación.

Transparencia
El proceso emergente y el trabajo deben ser visibles tanto para quienes realizan el trabajo como para quienes lo reciben.

Con Scrum, las decisiones importantes se basan en el estado percibido de sus tres artefactos formales. Los artefactos que

tienen poca transparencia pueden conducir a decisiones que disminuyen el valor y aumentan el riesgo.

3
La transparencia permite la inspección. La inspección sin transparencia es engañosa y derrochadora.

Inspección
Los artefactos de Scrum y el progreso hacia los objetivos acordados deben inspeccionarse con frecuencia y diligencia para
detectar variaciones o problemas potencialmente indeseables. Para ayudar con la inspección, Scrum proporciona cadencia
en forma de cinco eventos.

La inspección permite la adaptación. La inspección sin adaptación se considera inútil. Los eventos Scrum están diseñados
para provocar cambios.

Adaptación
Si algún aspecto de un proceso se desvía fuera de los límites aceptables o si el producto resultante es
inaceptable, se debe ajustar el proceso que se aplica o los materiales que se producen. El ajuste debe
hacerse lo antes posible para minimizar más desviaciones.

La adaptación se vuelve más difícil cuando las personas involucradas no están empoderadas o son autogestionarias. Se espera

que un Equipo Scrum se adapte en el momento en que aprende algo nuevo a través de la inspección.

Valores Scrum
El uso exitoso de Scrum depende de que las personas se vuelvan más competentes en vivir cinco valores:

Compromiso, Enfoque, Apertura, Respeto y Coraje

El Equipo Scrum se compromete a lograr sus objetivos y a apoyarse mutuamente. Su enfoque principal está en el
trabajo del Sprint para lograr el mejor progreso posible hacia estos objetivos. El Equipo Scrum y sus partes
interesadas están abiertos sobre el trabajo y los desafíos. Los miembros del Equipo Scrum se respetan entre sí
como 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 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 usa Scrum deben reforzar estos valores, no disminuirlos o 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 son 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 generando confianza.

4
Equipo Scrum
La unidad fundamental de Scrum es un pequeño equipo de personas, un Scrum Team. El Equipo Scrum consta de un
Scrum Master, un Product Owner y Desarrolladores. Dentro de un Equipo Scrum, no hay sub-equipos o jerarquías. Es
una unidad cohesiva de profesionales enfocados en un objetivo a la vez, la Meta del Producto.

Los Equipos Scrum son multifuncionales, lo que significa que los miembros tienen todas las habilidades necesarias para crear

valor en cada Sprint. También 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 seguir siendo ágil y lo suficientemente grande como para completar un trabajo

significativo dentro de un Sprint, normalmente 10 o menos personas. En general, hemos descubierto que los equipos más pequeños se

comunican mejor y son más productivos. Si los Equipos Scrum se vuelven demasiado grandes, deberían considerar reorganizarse en múltiples

Equipos Scrum cohesivos, cada uno enfocado en el mismo producto. Por lo tanto, deben compartir el mismo objetivo del producto, cartera de

productos y propietario del producto.

El Equipo Scrum es responsable de todas las actividades relacionadas con el producto, desde la colaboración de las partes

interesadas, la verificación, el mantenimiento, la operación, la experimentación, la investigación y el desarrollo, y cualquier otra

cosa que pueda ser necesaria. Están estructurados y facultados por la organización para gestionar su propio trabajo. Trabajar en

Sprints a un ritmo sostenible mejora el enfoque y la consistencia del 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 se comprometen a crear cualquier aspecto de un Incremento

utilizable en cada Sprint.

Las habilidades específicas que necesitan los desarrolladores suelen ser amplias y variarán según el 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 Listo;
● Adaptando su plan cada día hacia el Sprint Goal; y,
● Responsabilizarse unos a otros como profesionales.

Dueño del producto

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

5
El propietario del producto también es responsable de la gestión eficaz de la cartera de productos, que incluye:

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

● Crear y comunicar claramente los elementos de la Lista de Producto;
● Ordenar elementos de la Lista de Producto; y,
● Garantizar que la cartera de productos sea transparente, visible y comprensible.

El propietario del producto puede realizar el trabajo anterior o puede delegar la responsabilidad a otros. Independientemente, el

Product Owner 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 de
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 deseen cambiar el Product Backlog pueden hacerlo
tratando de convencer al Product Owner.

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

El Scrum Master es responsable de la efectividad del Scrum Team. Lo hacen al permitir que el
Equipo Scrum mejore sus prácticas, dentro del marco Scrum.

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, que incluyen:

● Entrenando a los miembros del equipo en autogestión y funcionalidad cruzada;

● Ayudar al Equipo Scrum a enfocarse en crear Incrementos de alto valor que cumplan con la Definición de Listo;

● Provocar la eliminación de impedimentos para el 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 marco de

tiempo.

Scrum Master sirve al propietario del producto de varias maneras, que incluyen:

6
 ● Ayudar a encontrar técnicas para la definición efectiva de la meta del producto y la gestión de la cartera de productos;

● Ayudar al Equipo Scrum a comprender la necesidad de elementos claros y concisos de la Lista de Producto;
● ayudar a establecer la 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, que incluyen:

● Liderar, capacitar y asesorar a la organización en su adopción de Scrum;

● Planificar y asesorar implementaciones de Scrum dentro de la organización;
● Ayudar a los empleados y partes interesadas a comprender y promulgar un enfoque empírico para el trabajo
complejo; y,
● Eliminación de 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. La falta de operación de

cualquier evento según lo prescrito da como resultado la pérdida de oportunidades para inspeccionar y adaptar. Los eventos se utilizan en

Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Óptimamente, todos los eventos se llevan a cabo

al mismo tiempo y lugar para reducir la complejidad.

el sprint
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 del Sprint anterior.

Todo el trabajo necesario para lograr el objetivo del producto, incluida la planificación de Sprint, Scrums diarios, revisión de

Sprint y retrospectiva de Sprint, se realiza dentro de Sprints.

Durante el Sprint:

● No se realizan cambios que puedan poner en peligro el Sprint Goal;

● La calidad no disminuye;
● El Product Backlog se refina según sea necesario; y,
● El alcance puede aclararse y renegociarse con el propietario del producto a medida que se aprende más.

Los sprints permiten la previsibilidad al garantizar la inspección y la adaptación del progreso hacia un objetivo del producto al

menos cada mes calendario. Cuando el horizonte de un Sprint es demasiado largo, el Sprint Goal puede volverse inválido, la

complejidad puede aumentar y el riesgo puede aumentar. Se pueden emplear Sprints más cortos para generar más aprendizaje

7
ciclos 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 burn-downs, burn-ups o flujos acumulativos. Si bien han
demostrado ser útiles, estos no reemplazan la importancia del empirismo. En entornos complejos, se desconoce qué
sucederá. Solo lo que ya sucedió puede usarse para la toma de decisiones con miras al futuro.

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

Planificación de Sprint

Sprint Planning inicia el Sprint al diseñar el trabajo que se realizará para el Sprint. Este plan resultante
es creado por 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 de la cartera de

productos y cómo se relacionan con el objetivo del producto. El Equipo Scrum también puede invitar a otras personas a asistir a Sprint

Planning para brindar asesoramiento.

Sprint Planning aborda los siguientes temas:

Tema uno: ¿Por qué es valioso este Sprint?

El Product Owner propone cómo el producto podría incrementar su valor y utilidad en el Sprint actual. Luego, todo
el Equipo Scrum colabora para definir un Sprint Goal que comunica por qué el Sprint es valioso para las partes
interesadas. El objetivo del Sprint debe finalizarse antes de que finalice la planificación del Sprint.

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

A través de la discusión con el Propietario del Producto, los Desarrolladores seleccionan elementos del 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 dentro de un Sprint puede ser un desafío. Sin embargo, cuanto más sepan
los desarrolladores sobre su rendimiento anterior, su próxima capacidad y su definición de hecho, más confianza
tendrán en sus pronósticos de Sprint.

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

Para cada elemento del Product Backlog seleccionado, los Desarrolladores planifican el trabajo necesario para crear un Incremento que

cumpla con la Definición de Terminado. A menudo, esto se hace descomponiendo los elementos de la cartera de productos en elementos de

trabajo más pequeños de un día o menos. Cómo se hace esto queda a la entera discreción de los Desarrolladores. Nadie más les dice cómo

convertir los elementos del Product Backlog en Incrementos de valor.

8
El objetivo del Sprint, los elementos del Product Backlog seleccionados para el Sprint, más el plan para entregarlos,
se denominan juntos Sprint Backlog.

La planificación de Sprint tiene un límite de tiempo de un máximo de ocho horas para un Sprint de un mes. Para Sprints más cortos, el

evento suele ser más corto.

Scrum diario
El propósito del Daily Scrum es inspeccionar el progreso hacia el Sprint Goal 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
realiza a la misma hora y en el mismo lugar todos los días hábiles del Sprint. Si el Product Owner o Scrum Master están
trabajando activamente en los 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 Sprint Goal y produzca un plan de acción para el próximo día de trabajo.
Esto crea enfoque y mejora la autogestión.

Daily Scrums mejora las comunicaciones, identifica impedimentos, promueve la toma de decisiones rápidas y, en
consecuencia, elimina la necesidad de otras reuniones.

Daily Scrum 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 replanificación del resto del trabajo del Sprint.

Revisión de Sprint

El propósito de la Revisión del Sprint es inspeccionar el resultado del Sprint y determinar futuras
adaptaciones. 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 ha cambiado
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 un límite de tiempo de un máximo de cuatro horas para un
Sprint de un mes. Para Sprints más cortos, el evento suele ser más corto.

9
Retrospectiva de Sprint
El propósito de la Retrospectiva de Sprint es planificar formas de aumentar la calidad y la eficacia.

El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las
herramientas y su Definición de Terminado. Los elementos inspeccionados a menudo varían con el dominio del trabajo.
Se identifican las suposiciones que los llevaron por mal camino y se exploran sus orígenes. El Equipo Scrum analiza qué
salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.

El Equipo Scrum identifica los cambios más útiles para mejorar su efectividad. Las mejoras más
impactantes se abordan lo antes posible. Incluso pueden agregarse al Sprint Backlog para el próximo
Sprint.

La Retrospectiva del Sprint concluye el Sprint. Tiene un límite de tiempo de un máximo de tres horas para un Sprint de un
mes. Para Sprints más cortos, el evento suele ser más corto.

Artefactos 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 proporcione información que mejore la transparencia y el
enfoque contra el cual se puede medir el progreso:

● Para el Product Backlog es el Product Goal.

● Para el Sprint Backlog es el Sprint Goal.
● Para el Incremento es la Definición de Terminado.

Estos compromisos existen para reforzar el empirismo y los valores de Scrum para el Equipo Scrum y sus partes
interesadas.

Pila de Producto
El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la
única fuente de trabajo realizada por el Scrum Team.

Los elementos de la Lista de Producto que puede realizar el Equipo Scrum dentro de un Sprint se consideran listos para la

selección en un evento de Planificación de Sprint. Suelen adquirir este grado de transparencia después de las actividades de

refinación. El refinamiento de la cartera de productos es el acto de desglosar y definir aún más los elementos de la cartera de

productos en elementos más pequeños y precisos. Esta es una actividad continua para agregar detalles, como una descripción,

orden y tamaño. Los atributos a menudo varían con el dominio del trabajo.

10
Los Desarrolladores que estarán haciendo el trabajo son responsables del dimensionamiento. El propietario del producto puede

influir en los desarrolladores ayudándolos a comprender y seleccionar compensaciones.

Compromiso: Producto Meta

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 la cartera de productos. El resto del Product Backlog emerge para
definir "qué" cumplirá con el Product Goal.

Un producto es un vehículo para entregar valor. Tiene un límite claro, partes interesadas conocidas, usuarios o
clientes bien definidos. Un producto puede ser un servicio, un producto físico o algo más abstracto.

El Product Goal es el objetivo a largo plazo para el Scrum Team. Deben cumplir (o abandonar) un objetivo
antes de asumir el siguiente.

Pila de Sprint
El Sprint Backlog se compone del Sprint Goal (por qué), el conjunto de elementos del Product Backlog seleccionados para
el Sprint (qué), así como un plan procesable para entregar el Incremento (cómo).

El Sprint Backlog es un plan por y para los Desarrolladores. Es una imagen muy visible y en tiempo real del trabajo
que los desarrolladores planean realizar durante el Sprint para lograr el objetivo del Sprint. En consecuencia, el
Sprint Backlog se actualiza a lo largo del Sprint a medida que se aprende más. Debe tener suficientes detalles para
que puedan inspeccionar su progreso en el Daily Scrum.

Compromiso: Sprint Goal

El Sprint Goal es el único objetivo del Sprint. Aunque el Sprint Goal es un compromiso de los
desarrolladores, brinda flexibilidad en términos del trabajo exacto necesario para lograrlo. El Sprint Goal
también crea coherencia y enfoque, alentando al Equipo Scrum a trabajar en conjunto en lugar de en
iniciativas separadas.

El Sprint Goal se crea durante el evento Sprint Planning y luego se agrega al Sprint Backlog. 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 Product Owner para negociar el alcance del Sprint Backlog
dentro del Sprint sin afectar el Sprint Goal.

Incremento
Un Incremento es un peldaño concreto hacia el Objetivo del Producto. Cada Incremento se suma a todos los Incrementos

anteriores y se verifica exhaustivamente, lo que garantiza que todos los Incrementos funcionen juntos. Para proporcionar valor,

el Incremento debe ser utilizable.

11
Se pueden crear múltiples incrementos dentro de un Sprint. La suma de los Incrementos se presenta en el Sprint
Review apoyando así el empirismo. Sin embargo, se puede entregar un Incremento a las partes interesadas antes
del final del Sprint. La 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 Listo, nace un Incremento.

La Definición de Terminado crea transparencia al proporcionar a todos una comprensión compartida de qué trabajo
se completó como parte del Incremento. Si un elemento de la Lista de Producto no cumple con la Definición de
Terminado, no se puede publicar ni presentar en la Revisión del Sprint. En su lugar, vuelve a Product Backlog para
futuras consideraciones.

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

Los Desarrolladores están obligados a cumplir con la Definición de Listo. Si hay varios Equipos Scrum
trabajando juntos en un producto, deben definir y cumplir mutuamente con la misma Definición de Listo.

12
Nota final
Scrum es gratuito y se ofrece en esta Guía. El marco Scrum, 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.

Agradecimientos

Gente
De las miles de personas que han contribuido a Scrum, debemos destacar aquellas 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, Scrum no sería refinado como lo es hoy.

Historial de la guía Scrum

Ken Schwaber y Jeff Sutherland presentaron conjuntamente Scrum por primera vez en la Conferencia OOPSLA en 1995.
Esencialmente, documentó el aprendizaje que Ken y Jeff obtuvieron durante los años anteriores e hizo pública la
primera definición formal de Scrum.

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

La historia completa de Scrum se describe en otra parte. Para honrar los primeros lugares donde 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 Attribution Share-Alike de Creative Commons, accesible enhttps://
creativecommons.org/licenses/by-sa/4.0/legalcode y también se describe en forma resumida enhttps://
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 Reconocimiento Compartir-Igual de Creative Commons.

13