La guía de Scrum ™

Propósito de la guía de Scrum

Scrum es un marco para desarrollar, entregar y mantener productos complejos. Esta guía contiene la definición
de Scrum. Esta definición consiste en los roles, eventos, artefactos y las reglas de Scrum que los unen. Ken
Schwaber y Jeff Sutherland desarrollaron Scrum; la Guía de Scrum está escrita y provista por ellos. Juntos,
respaldan la Guía de Scrum.

Definición de Scrum
Scrum (n): un marco dentro del cual las personas pueden abordar complejos problemas de adaptación,
mientras que ofrecen productiva y creativamente productos del más alto valor posible.
Scrum es:

 Ligero
 Simple de entender
 Difícil de dominar

Scrum es un marco de procesos que se ha utilizado para gestionar el trabajo en productos complejos desde
principios de los años noventa. Scrum no es un proceso, técnica o método definitivo. Más bien, es un marco
dentro del cual puede emplear varios procesos y técnicas. Scrum deja en claro la eficacia relativa de su gestión
de productos y técnicas de trabajo para que pueda mejorar continuamente el producto, el equipo y el entorno de
trabajo.
El marco de Scrum consiste en Scrum Teams y sus roles, eventos, artefactos y reglas asociados. Cada
componente dentro del marco sirve para un propósito específico y es esencial para el éxito y uso de Scrum.
Las reglas de Scrum unen los roles, eventos y artefactos, que rigen las relaciones y la interacción entre
ellos. Las reglas de Scrum se describen en todo el cuerpo de este documento.
Las tácticas específicas para usar el marco de Scrum varían y se describen en otra parte.

Usos de Scrum
Scrum fue desarrollado inicialmente para administrar y desarrollar productos. A partir de la década de 1990,
Scrum se ha utilizado ampliamente en todo el mundo para:

1. Investigar e identificar mercados viables, tecnologías y capacidades de productos;

2. Desarrollar productos y mejoras;
3. Libera productos y mejoras, tantas veces como sea posible por día;
4. Desarrollar y mantener la nube (en línea, segura, bajo demanda) y otros entornos operativos para el uso
del producto; y,
5. Sostener y renovar productos.

Scrum se ha utilizado para desarrollar software, hardware, software integrado, redes de funciones interactivas,
vehículos autónomos, escuelas, gobierno, marketing, administración de operaciones de organizaciones y casi
todo lo que utilizamos en nuestra vida cotidiana, como individuos y sociedades.
A medida que la complejidad de la tecnología, el mercado y el entorno y sus interacciones han aumentado
rápidamente, la utilidad de Scrum al tratar con la complejidad se demuestra a diario.
Scrum demostró ser especialmente efectivo en la transferencia iterativa e incremental de conocimientos. Scrum
ahora se usa ampliamente para productos, servicios y la administración de la organización principal.
La esencia de Scrum es un pequeño equipo de personas. El equipo individual es altamente flexible y
adaptativo. Estas fortalezas continúan operando en redes de equipos individuales, varios, muchos y que
desarrollan, liberan, operan y mantienen el trabajo y productos de trabajo de miles de personas. Colaboran e
interoperan a través de sofisticadas arquitecturas de desarrollo y entornos de lanzamiento de destino.
Cuando las palabras "desarrollar" y "desarrollo" se utilizan en la Guía de Scrum, se refieren a trabajos
complejos, como los tipos identificados anteriormente.

La teoría de Scrum
Scrum se basa en la teoría de control de procesos empíricos o empirismo. El empirismo afirma que el
conocimiento proviene de la experiencia y toma decisiones basadas en lo que se conoce. Scrum emplea un
enfoque iterativo e incremental para optimizar la predictibilidad y controlar el riesgo. Tres pilares sostienen cada
implementación del control del proceso empírico: transparencia, inspección y adaptación.

Transparencia
Los aspectos importantes del proceso deben ser visibles para los responsables del resultado. La transparencia
requiere que esos aspectos sean definidos por un estándar común para que los observadores compartan un
entendimiento común de lo que se está viendo.
Por ejemplo:

 Todos los participantes deben compartir un lenguaje común que se refiera al proceso; y,
 Aquellos que realizan el trabajo y aquellos que inspeccionan el incremento resultante deben compartir
una definición común de "Hecho".

Inspección
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y avanzar hacia un objetivo
de Sprint para detectar variaciones indeseables. Su inspección no debería ser tan frecuente como para que la
inspección obstaculice el trabajo. Las inspecciones son más beneficiosas cuando son realizadas diligentemente
por inspectores expertos en el lugar de trabajo.

Adaptación
Si un inspector determina que uno o más aspectos de un proceso se desvían fuera de los límites aceptables, y
que el producto resultante será inaceptable, se debe ajustar el proceso o el material que se está
procesando. Se debe hacer un ajuste tan pronto como sea posible para minimizar la desviación adicional.
Scrum prescribe cuatro eventos formales para inspección y adaptación, como se describe en la sección de
Eventos de Scrum de este documento:

 Sprint Planning
 Daily Scrum
 Revisión de Sprint
 Sprint Retrospective

Scrum Values
Cuando los valores de compromiso, coraje, enfoque, apertura y respeto son encarnados y vividos por el equipo
de Scrum, los pilares de transparencia, inspección y adaptación de Scrum cobran vida y generan confianza
para todos. Los miembros del equipo de Scrum aprenden y exploran esos valores mientras trabajan con los
eventos, roles y artefactos de Scrum.
El uso exitoso de Scrum depende de que las personas se vuelvan más competentes en la vivencia de estos
cinco valores. Las personas se comprometen personalmente a alcanzar los objetivos del equipo de Scrum. Los
miembros del equipo de Scrum tienen coraje para hacer lo correcto y trabajar en problemas difíciles. Todos se
enfocan en el trabajo del Sprint y los objetivos del Scrum Team. El equipo de Scrum y sus partes interesadas
acuerdan ser abiertos sobre todo el trabajo y los desafíos al realizar el trabajo. Los miembros del equipo de
Scrum se respetan mutuamente para ser personas capaces e independientes.

El equipo de Scrum
El Scrum Team consta de un Product Owner, el Development Team y un Scrum Master. Los Scrum Teams se
auto organizan y tienen funciones cruzadas. Los equipos autoorganizados eligen la mejor manera de llevar a
cabo su trabajo, en lugar de ser dirigidos por otros fuera del equipo. Los equipos multifuncionales tienen todas
las competencias necesarias para realizar el trabajo sin depender de otros que no formen parte del equipo. El
modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad. El
equipo de Scrum ha demostrado ser cada vez más eficaz para todos los usos anteriores y cualquier trabajo
complejo.
Los equipos de Scrum entregan productos de forma iterativa e incremental, lo que maximiza las oportunidades
de comentarios. Las entregas incrementales del producto "Hecho" aseguran que siempre esté disponible una
versión potencialmente útil del producto en funcionamiento.

El dueño del producto

El propietario del producto es responsable de maximizar el valor del producto resultante del trabajo del equipo
de desarrollo. Cómo se hace esto puede variar ampliamente entre las organizaciones, los equipos de Scrum y
las personas.
El propietario del producto es la única persona responsable de administrar la acumulación de productos. La
gestión de la acumulación de productos incluye:

 Expresar claramente los ítems del Backlog del Producto;

 Ordenar los artículos en la cartera de pedidos del producto para lograr los mejores objetivos y misiones;
 Optimizar el valor del trabajo que realiza el Equipo de Desarrollo;
 Asegurar que la Lista de pedidos del producto sea visible, transparente y clara para todos, y muestra en
qué trabajará el equipo de Scrum a continuación; y,
 Asegurar que el equipo de desarrollo comprenda los elementos en la cartera de pedidos del producto al
nivel necesario.

El propietario del producto puede hacer el trabajo anterior o hacer que lo haga el equipo de desarrollo. Sin
embargo, el propietario del producto sigue siendo responsable.
El propietario del producto es una persona, no un comité. El propietario del producto puede representar los
deseos de un comité en la lista de pedidos del producto, pero aquellos que deseen cambiar la prioridad de un
elemento de la cartera de productos deben dirigirse al propietario del producto.
Para que el propietario del producto tenga éxito, toda la organización debe respetar sus decisiones. Las
decisiones del propietario del producto son visibles en el contenido y el pedido de la cartera de pedidos del
producto. Nadie puede forzar al Equipo de Desarrollo a trabajar a partir de un conjunto diferente de requisitos.

El equipo de desarrollo
El Equipo de desarrollo está formado por profesionales que realizan el trabajo de entregar un Incremento
potencialmente liberable del producto "Hecho" al final de cada Sprint. Se requiere un incremento "Hecho" en la
Revisión de Sprint. Solo los miembros del Equipo de Desarrollo crean el Incremento.
Los equipos de desarrollo están estructurados y facultados por la organización para organizar y gestionar su
propio trabajo. La sinergia resultante optimiza la eficiencia y eficacia general del equipo de desarrollo.
Los Equipos de Desarrollo tienen las siguientes características:

 Ellos son autoorganizados. Nadie (ni siquiera el Scrum Master) le dice al Equipo de Desarrollo cómo
convertir el Atrasamiento del Producto en Incrementos de funcionalidad potencialmente liberable;
 Los Equipos de desarrollo son multifuncionales, con todas las habilidades necesarias como equipo para
crear un Incremento de producto;
 Scrum no reconoce títulos para los miembros del Equipo de desarrollo, independientemente del trabajo
que realice la persona;
 Scrum no reconoce sub-equipos en el equipo de desarrollo, independientemente de los dominios que
deben abordarse como pruebas, arquitectura, operaciones o análisis de negocios; y,
 Los miembros del Equipo de Desarrollo Individual pueden tener habilidades especializadas y áreas de
enfoque, pero la responsabilidad pertenece al Equipo de Desarrollo como un todo.

Tamaño del equipo de desarrollo

El tamaño del equipo de desarrollo óptimo es lo suficientemente pequeño como para seguir siendo ágil y lo
suficientemente grande como para completar un trabajo significativo dentro de un Sprint. Menos de tres
miembros del Equipo de Desarrollo disminuyen la interacción y los resultados en ganancias de productividad
más pequeñas. Los Equipos de Desarrollo más pequeños pueden encontrar limitaciones de habilidades durante
el Sprint, lo que hace que el Equipo de Desarrollo no pueda entregar un Incremento potencialmente
liberable. Tener más de nueve miembros requiere demasiada coordinación. Los grandes equipos de desarrollo
generan demasiada complejidad para que un proceso empírico sea útil. Los roles Dueño de producto y Maestro
de Scrum no están incluidos en este conteo a menos que también estén ejecutando el trabajo de Sprint
Backlog.

El Scrum Master
El Scrum Master es responsable de promover y apoyar Scrum como se define en la Guía de Scrum. Scrum
Masters hace esto al ayudar a todos a entender la teoría, las prácticas, las reglas y los valores de Scrum.
El Scrum Master es un sirviente líder del Scrum Team. El Scrum Master ayuda a aquellos ajenos al Scrum
Team a comprender cuáles de sus interacciones con el Scrum Team son útiles y cuáles no. El Scrum Master
ayuda a todos a cambiar estas interacciones para maximizar el valor creado por el equipo de Scrum.

Scrum Master Service para el propietario del producto

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

 Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo
de Scrum de la mejor manera posible;
 Encontrar técnicas para una gestión eficaz de la acumulación de productos;
 Ayudar al equipo de Scrum a comprender la necesidad de elementos claros y concisos de productos
atrasados;
 Comprender la planificación de productos en un entorno empírico;
 Asegurar que el Propietario del Producto sepa cómo organizar el Retraso del Producto para maximizar
el valor;
 Comprender y practicar la agilidad; y,
 Facilitar los eventos de Scrum según lo solicitado o necesario.

Scrum Master Service para el equipo de desarrollo

El Scrum Master sirve al Equipo de Desarrollo de varias maneras, que incluyen:

 Coaching del equipo de desarrollo en autoorganización y funcionalidad cruzada;

 Ayudando al equipo de desarrollo a crear productos de alto valor;
 Eliminar impedimentos para el progreso del Equipo de Desarrollo;
 Facilitar eventos Scrum según se solicite o necesite; y,
 Coaching del equipo de desarrollo en entornos organizacionales en los que Scrum todavía no se ha
adoptado ni entendido completamente.

Scrum Master Service para la organización

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

 Liderando y entrenando a la organización en su adopción de Scrum;

 Planear implementaciones de Scrum dentro de la organización;
 Ayudar a los empleados y partes interesadas a comprender y promulgar Scrum y el desarrollo de
productos empíricos;
 Causando cambios que aumentan la productividad del Equipo de Scrum; y,
 Trabajar con otros Scrum Masters para aumentar la efectividad de la aplicación de Scrum en la
organización.

Eventos de Scrum
Los eventos prescritos se usan en Scrum para crear regularidad y minimizar la necesidad de reuniones no
definidas en Scrum. Todos los eventos son eventos encerrados en el tiempo, de modo que cada evento tiene
una duración máxima. Una vez que comienza un Sprint, su duración es fija y no se puede acortar o alargar. Los
eventos restantes pueden finalizar siempre que se logre el objetivo del evento, asegurando que se dedique una
cantidad apropiada de tiempo sin permitir el desperdicio en el proceso.
Además del Sprint mismo, que es un contenedor para todos los demás eventos, cada evento en Scrum es una
oportunidad formal para inspeccionar y adaptar algo. Estos eventos están específicamente diseñados para
permitir una transparencia e inspección críticas. Si no se incluye alguno de estos eventos, se reduce la
transparencia y se pierde la oportunidad de inspeccionar y adaptar.

El Sprint
El corazón de Scrum es un Sprint, un cuadro de tiempo de un mes o menos durante el cual se crea un
Incremento de producto "Hecho", utilizable y potencialmente liberable. Los sprints tienen duraciones
consistentes a lo largo de un esfuerzo de desarrollo. Un nuevo Sprint comienza inmediatamente después de la
conclusión del Sprint anterior.
Los sprints contienen y consisten en Sprint Planning, Daily Scrums, el trabajo de desarrollo, Sprint Review y
Sprint Retrospective.
Durante el Sprint:

 No se realizan cambios que pondrían en peligro la Meta de Sprint;

 Los objetivos de calidad no disminuyen; y,
 El alcance se puede aclarar y renegociar entre el propietario del producto y el equipo de desarrollo a
medida que se aprende más.

Cada Sprint puede considerarse un proyecto con un horizonte no mayor a un mes. Al igual que los proyectos,
Sprints se utilizan para lograr algo. Cada Sprint tiene una meta de lo que se construirá, un diseño y un plan
flexible que guiará su construcción, el trabajo y el incremento resultante del producto.
Los Sprints están limitados a un mes calendario. Cuando el horizonte de un Sprint es demasiado largo, la
definición de lo que se está construyendo puede cambiar, la complejidad puede aumentar y el riesgo puede
aumentar. Los Sprints permiten la previsibilidad al garantizar la inspección y la adaptación del progreso hacia un
objetivo de Sprint al menos cada mes calendario. Los Sprints también limitan el riesgo a un mes calendario de
costo.

Cancelando un Sprint
Se puede cancelar un Sprint antes de que termine Sprint time-box. Solo el Propietario del Producto tiene la
autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de las partes interesadas, el Equipo
de Desarrollo o el Scrum Master.
Un Sprint se cancelará si el objetivo de Sprint se vuelve obsoleto. Esto podría ocurrir si la empresa cambia de
dirección o si cambian las condiciones del mercado o la tecnología. En general, un Sprint debería ser cancelado
si ya no tiene sentido dadas las circunstancias. Pero, debido a la corta duración de Sprints, la cancelación
raramente tiene sentido.
Cuando se cancela un Sprint, se revisan todos los ítems pendientes de completar del Producto "Hecho". Si
parte del trabajo es potencialmente liberable, el propietario del producto generalmente lo acepta. Todos los
elementos incompletos del Backlog del producto se vuelven a estimar y se vuelven a colocar en el Backlog del
Producto. El trabajo realizado en ellos se deprecia rápidamente y debe volver a estimarse con frecuencia.
Las cancelaciones de Sprint consumen recursos, ya que todos se reagrupan en otro Sprint Planning para
comenzar otro Sprint. Las cancelaciones de Sprint suelen ser traumáticas para el equipo de Scrum, y son muy
poco frecuentes.

Sprint Planning
El trabajo que se realizará en el Sprint está planificado en Sprint Planning. Este plan es creado por el trabajo
colaborativo de todo el equipo de Scrum.
La planificación de Sprint está sincronizada en el tiempo hasta un máximo de ocho horas para un Sprint de un
mes. Para Sprints más cortos, el evento suele ser más corto. El Scrum Master asegura que el evento tenga
lugar y que los asistentes entiendan su propósito. El Scrum Master le enseña al Scrum Team a mantenerlo
dentro del time-box.
Sprint Planning responde lo siguiente:
  ¿Qué se puede entregar en el Incremento resultante del próximo Sprint?
 ¿Cómo se logrará el trabajo necesario para lograr el Incremento?

Tema uno: ¿Qué se puede hacer este Sprint?

El equipo de desarrollo trabaja para pronosticar la funcionalidad que se desarrollará durante el Sprint. El
Propietario del producto analiza el objetivo que debería alcanzar Sprint y los elementos del Registro de pedidos
del producto que, de completarse en el Sprint, alcanzarían la Meta de Sprint. Todo el equipo de Scrum colabora
en la comprensión del trabajo de Sprint.
El aporte a esta reunión es el Atrio del producto, el último Incremento del producto, la capacidad proyectada del
Equipo de desarrollo durante el Sprint y el desempeño anterior del Equipo de desarrollo. La cantidad de
elementos seleccionados del Backlog del Producto para Sprint depende exclusivamente del Equipo de
Desarrollo. Solo el Equipo de Desarrollo puede evaluar lo que puede lograr con el próximo Sprint.
Durante la planificación de Sprint, el equipo de Scrum también crea un objetivo de Sprint. La meta de Sprint es
un objetivo que se cumplirá dentro del Sprint a través de la implementación de la cartera de pedidos del
producto, y proporciona orientación al equipo de desarrollo sobre por qué está creando el incremento.

Tema dos: ¿cómo se hará el trabajo elegido?

Después de establecer la Meta de Sprint y seleccionar los ítems de la Lista de Apertura de Producto para
Sprint, el Equipo de Desarrollo decide cómo se convertirá esta funcionalidad en un Incremento de producto
"Hecho" durante la Sprint. Los elementos del Registro de productos pendientes seleccionados para este Sprint
más el plan para entregarlos se denominan pedidos pendientes de Sprint.
El equipo de desarrollo generalmente comienza diseñando el sistema y el trabajo necesario para convertir la
cartera de pedidos del producto en un incremento de producto en funcionamiento. El trabajo puede ser de
diferente tamaño o esfuerzo estimado. Sin embargo, se planea trabajar lo suficiente durante la planificación de
Sprint para que el equipo de desarrollo pronostique lo que cree que puede hacer en el próximo Sprint. El trabajo
planificado para los primeros días del Sprint por parte del Equipo de Desarrollo se descompone al final de esta
reunión, a menudo en unidades de un día o menos. El equipo de desarrollo se autoorganiza para llevar a cabo
el trabajo en la acumulación de Sprint, tanto durante la planificación Sprint como según sea necesario durante
todo el Sprint.
El propietario del producto puede ayudarlo a aclarar los elementos seleccionados de la cartera de productos
pendientes y a realizar intercambios. Si el Equipo de desarrollo determina que tiene demasiado o muy poco
trabajo, puede renegociar los elementos del Registro de productos seleccionados con el Propietario del
producto. El Equipo de Desarrollo también puede invitar a otras personas a asistir para proporcionar
asesoramiento técnico o de dominio.
Al final de la planificación de Sprint, el equipo de desarrollo debe poder explicarle al propietario del producto y al
Scrum Master cómo se propone trabajar como un equipo autoorganizado para lograr la meta de Sprint y crear el
incremento previsto.

Sprint Goal
Sprint Goal es un conjunto de objetivos para Sprint que se puede cumplir a través de la implementación de
Product Backlog. Brinda orientación al Equipo de Desarrollo sobre por qué está construyendo el Incremento. Se
crea durante la reunión de planificación de Sprint. El objetivo de Sprint le da al equipo de desarrollo cierta
flexibilidad con respecto a la funcionalidad implementada dentro del Sprint. Los ítems del Registro de Producto
seleccionado entregan una función coherente, que puede ser el Objetivo de Sprint. El objetivo de Sprint puede
ser cualquier otra coherencia que haga que el equipo de desarrollo trabaje conjuntamente en lugar de iniciativas
separadas.
A medida que el Equipo de Desarrollo trabaja, mantiene el Objetivo de Sprint en mente. Para satisfacer el
objetivo de Sprint, implementa funcionalidad y tecnología. Si el trabajo resulta ser diferente de lo esperado por
el equipo de desarrollo, colaboran con el propietario del producto para negociar el alcance de Sprint Backlog
dentro del Sprint.

Daily Scrum
The Daily Scrum es un evento de 15 minutos para el Equipo de Desarrollo. El Daily Scrum se lleva a cabo todos
los días del Sprint. En él, el Equipo de Desarrollo planea trabajar durante las próximas 24 horas. Esto optimiza
la colaboración y el rendimiento del equipo inspeccionando el trabajo desde el último Daily Scrum y
pronosticando el próximo trabajo de Sprint. El Daily Scrum se lleva a cabo al mismo tiempo y lugar cada día
para reducir la complejidad.
El equipo de desarrollo utiliza el Daily Scrum para inspeccionar el progreso hacia la meta de Sprint e
inspeccionar cómo avanza el progreso hacia completar el trabajo en la acumulación de Sprint. Daily Scrum
optimiza la probabilidad de que el equipo de desarrollo cumpla con la meta de Sprint. Todos los días, el Equipo
de Desarrollo debe entender cómo se propone trabajar juntos como un equipo autoorganizado para lograr la
Meta de Sprint y crear el Incremento previsto para el final del Sprint.
La estructura de la reunión es establecida por el Equipo de Desarrollo y se puede realizar de diferentes
maneras si se enfoca en el progreso hacia la Meta de Sprint. Algunos Equipos de Desarrollo usarán preguntas,
algunas serán más basadas en discusiones. Aquí hay un ejemplo de lo que podría usarse:

 ¿Qué hice ayer que ayudó al Equipo de Desarrollo a cumplir con el objetivo de Sprint?
 ¿Qué voy a hacer hoy para ayudar al Equipo de Desarrollo a cumplir con la Meta de Sprint?
 ¿Veo algún impedimento que impida que yo o el Equipo de Desarrollo cumpla con la Meta de Sprint?

El Equipo de Desarrollo o los miembros del equipo a menudo se reúnen inmediatamente después del Daily
Scrum para discusiones detalladas, o para adaptar, o replanificar, el resto del trabajo de Sprint.
Scrum Master se asegura de que el equipo de desarrollo tenga la reunión, pero el equipo de desarrollo es
responsable de realizar el Daily Scrum. El Scrum Master le enseña al Equipo de Desarrollo a mantener el Daily
Scrum dentro de la caja de tiempo de 15 minutos.
The Daily Scrum es una reunión interna para el Equipo de Desarrollo. Si hay otros presentes, Scrum Master se
asegura de que no interrumpan la reunión.
Los Scrums diarios mejoran las comunicaciones, eliminan otras reuniones, identifican los impedimentos al
desarrollo para su eliminación, destacan y promueven la toma de decisiones rápida, y mejoran el nivel de
conocimiento del Equipo de Desarrollo. Esta es una reunión clave para inspeccionar y adaptar.

Revisión de Sprint
Una Revisión de Sprint se lleva a cabo al final del Sprint para inspeccionar el Incremento y adaptar el Retraso
del Producto si es necesario. Durante la Revisión de Sprint, el Equipo de Scrum y las partes interesadas
colaboran sobre lo que se hizo en el Sprint. En función de eso y de cualquier cambio en la acumulación de
productos durante el Sprint, los asistentes colaboran en las siguientes cosas que podrían hacerse para
optimizar el valor. Esta es una reunión informal, no una reunión de estado, y la presentación del Incremento
tiene la intención de obtener retroalimentación y fomentar la colaboración.
Esta es como máximo una reunión de cuatro horas para Sprints de un mes. Para Sprints más cortos, el evento
suele ser más corto. El Scrum Master garantiza que el evento tenga lugar y que los asistentes entiendan su
propósito. El Scrum Master enseña a todos los involucrados a mantenerlo dentro de la caja de tiempo.
La Revisión de Sprint incluye los siguientes elementos:

 Los asistentes incluyen el equipo de Scrum y las partes interesadas clave invitadas por el propietario del
producto;
 El Propietario del Producto explica qué elementos del Atrio del Producto se han "Hecho" y qué no se
han "Hecho";
 El Equipo de Desarrollo discute qué fue bien durante el Sprint, qué problemas encontró y cómo se
resolvieron esos problemas;
 El Equipo de Desarrollo demuestra el trabajo que ha "Hecho" y responde preguntas sobre el
Incremento;
 El Propietario del Producto analiza la Cartera de Producto tal como está. Él o ella proyecta fechas
probables de destino y entrega basadas en el progreso hasta la fecha (si es necesario);
 Todo el grupo colabora sobre qué hacer a continuación, de modo que Sprint Review proporciona
información valiosa para la siguiente planificación de Sprint;
 Revisión de cómo el mercado o el posible uso del producto podría haber cambiado, qué es lo más
valioso que puede hacer a continuación; y,
 Revisión de la línea de tiempo, el presupuesto, las capacidades potenciales y el mercado para las
próximas versiones anticipadas de funcionalidad o capacidad del producto.
El resultado de Sprint Review es un Backlog del producto revisado que define los elementos probables del
Backlog del producto para el próximo Sprint. La acumulación de productos también se puede ajustar en general
para encontrar nuevas oportunidades.

Sprint Retrospective
La Retrospectiva de Sprint es una oportunidad para que Scrum Team se inspeccione a sí mismo y cree un plan
para que se implementen mejoras durante el próximo Sprint.
La Retrospectiva Sprint ocurre después de la Revisión Sprint y antes de la próxima Planificación Sprint. Esta es
como máximo una reunión de tres horas para Sprints de un mes. Para Sprints más cortos, el evento suele ser
más corto. El Scrum Master asegura que el evento tenga lugar y que los asistentes entiendan su propósito.
Scrum Master garantiza que la reunión sea positiva y productiva. El Scrum Master enseña todo para mantenerlo
dentro del time-box. El Scrum Master participa como miembro del equipo de pares en la reunión desde la
responsabilidad del proceso de Scrum.
El propósito de la Retrospectiva de Sprint es:

 Inspeccionar cómo fue el último Sprint con respecto a personas, relaciones, procesos y herramientas;
 Identifique y ordene los elementos principales que funcionaron bien y las posibles mejoras; y,
 Cree un plan para implementar mejoras en la forma en que el equipo de Scrum hace su trabajo.

El Scrum Master alienta al Scrum Team a mejorar, dentro del marco del proceso de Scrum, su proceso de
desarrollo y prácticas para hacerlo más efectivo y agradable para el próximo Sprint. Durante cada retrospectiva
de Sprint, el equipo de Scrum planifica formas de aumentar la calidad del producto mejorando los procesos de
trabajo o adaptando la definición de "Hecho", si corresponde y no en conflicto con los estándares del producto o
de la organización.
Al final de la Retrospectiva de Sprint, el equipo de Scrum debería haber identificado las mejoras que
implementará en el próximo Sprint. Implementar estas mejoras en el próximo Sprint es la adaptación a la
inspección del propio Scrum Team. Si bien las mejoras pueden implementarse en cualquier momento, la
Retrospectiva de Sprint brinda una oportunidad formal para enfocarse en la inspección y la adaptación.

Scrum Artifacts
Los artefactos de Scrum representan trabajo o valor para proporcionar transparencia y oportunidades para
inspección y adaptación. Los artefactos definidos por Scrum están diseñados específicamente para maximizar
la transparencia de la información clave para que todos tengan la misma comprensión del artefacto.

Pila de Producto
La cartera de pedidos del producto es una lista ordenada de todo lo que se sabe que es necesario en el
producto. Es la única fuente de requisitos para cualquier cambio que se realice en el producto. El propietario del
producto es responsable de la acumulación de productos, incluidos su contenido, disponibilidad y pedidos.
Un Backlog de Producto nunca está completo. El desarrollo más temprano de él expone los requisitos
inicialmente conocidos y mejor entendidos. El Backlog del producto evoluciona a medida que el producto y el
entorno en el que se utilizará evolucionan. La cartera de pedidos del producto es dinámica; cambia
constantemente para identificar lo que el producto necesita para ser apropiado, competitivo y útil. Si existe un
producto, también existe su Product Backlog.
La Lista de Atrasos del Producto enumera todas las características, funciones, requisitos, mejoras y soluciones
que constituyen los cambios que se realizarán en futuras versiones. Los elementos del Atrio del producto tienen
los atributos de una descripción, orden, estimación y valor. Los artículos del Backlog del producto a menudo
incluyen descripciones de prueba que probarán su integridad cuando estén "Listo".
A medida que un producto se utiliza y gana valor, y el mercado proporciona comentarios, la cartera de pedidos
del producto se convierte en una lista más amplia y exhaustiva. Los requisitos nunca dejan de cambiar, por lo
que una Cartera de Producto es un artefacto viviente. Los cambios en los requisitos del negocio, las
condiciones del mercado o la tecnología pueden causar cambios en la acumulación de productos.
Múltiples equipos de Scrum a menudo trabajan juntos en el mismo producto. One Product Backlog se usa para
describir el próximo trabajo sobre el producto. A continuación, se puede emplear un atributo de Product Backlog
que agrupa elementos.
El refinamiento de la acumulación de productos es el acto de agregar detalles, estimaciones y pedidos a los
artículos en la cartera de pedidos del producto. Este es un proceso continuo en el que el Propietario del
producto y el Equipo de desarrollo colaboran en los detalles de los elementos de los Atrasos del
producto. Durante el refinamiento de la acumulación de productos, los artículos se revisan y revisan. El equipo
de Scrum decide cómo y cuándo se realiza el refinamiento. El refinamiento usualmente no consume más del
10% de la capacidad del Equipo de Desarrollo. Sin embargo, el Propietario del producto puede actualizar los
elementos de los Aberturas del Producto o a discreción del Propietario del Producto.
Las partidas de pedidos acumulados de productos más altos suelen ser más claras y detalladas que las menos
solicitadas. Se hacen estimaciones más precisas basadas en la mayor claridad y mayor detalle; cuanto menor
es el orden, menos detalles. Los ítems del Registro atrasado de productos que ocuparán el Equipo de
desarrollo para el próximo Sprint se refinarán para que cualquier ítem pueda ser "Listo" dentro del casillero de
Sprint. Los elementos del Registro de Producto que el Equipo de Desarrollo puede "Hacer" dentro de un Sprint
se consideran "Listo" para su selección en un Plan de Sprint. Los artículos del Registro de Producto
generalmente adquieren este grado de transparencia a través de las actividades de refinación descritas
anteriormente.
El equipo de desarrollo es responsable de todas las estimaciones. El propietario del producto puede influir en el
equipo de desarrollo ayudándolo a comprender y seleccionar concesiones, pero las personas que realizarán el
trabajo harán la estimación final.

Monitoreo del progreso hacia los objetivos

En cualquier momento, se puede resumir el trabajo total restante para alcanzar un objetivo. El Product Owner
hace un seguimiento de este trabajo total restante al menos en cada Sprint Review. El Propietario del Producto
compara esta cantidad con el trabajo restante en las Revisiones de Sprint anteriores para evaluar el progreso
hacia la finalización del trabajo proyectado en el tiempo deseado para la meta. Esta información se hace
transparente para todos los interesados.
Se han utilizado diversas prácticas proyectivas sobre la tendencia para pronosticar el progreso, como quemas,
quemas o flujos acumulativos. Estos han demostrado ser útiles. Sin embargo, estos no reemplazan la
importancia del empirismo. En entornos complejos, lo que sucederá es desconocido. Solo lo que ya sucedió
puede usarse para la toma de decisiones prospectiva.

Sprint Backlog
Sprint Backlog es el conjunto de ítems del Backlog del Producto seleccionado para Sprint, más un plan para
entregar el Incremento del producto y realizar el Sprint Goal. Sprint Backlog es un pronóstico del Equipo de
Desarrollo sobre qué funcionalidad será en el próximo Incremento y el trabajo necesario para entregar esa
funcionalidad en un Incremento "Hecho".
Sprint Backlog hace visible todo el trabajo que el equipo de desarrollo identifica como necesario para cumplir
con la meta de Sprint. Para garantizar la mejora continua, incluye al menos una mejora de proceso de alta
prioridad identificada en la reunión retrospectiva previa.
Sprint Backlog es un plan con suficiente detalle para que los cambios en el progreso se puedan entender en
Daily Scrum. El Equipo de desarrollo modifica la acumulación de Sprint durante todo el Sprint, y la acumulación
de Sprint emerge durante el Sprint. Este surgimiento ocurre cuando el Equipo de Desarrollo trabaja a través del
plan y aprende más sobre el trabajo necesario para lograr la Meta de Sprint.
A medida que se requiere un nuevo trabajo, el Equipo de Desarrollo lo agrega a la Lista de espera de Sprint. A
medida que se realiza o completa el trabajo, se actualiza el trabajo restante estimado. Cuando los elementos
del plan se consideran innecesarios, se eliminan. Solo el equipo de desarrollo puede cambiar su acumulación
de Sprint durante un Sprint. Sprint Backlog es una imagen muy visible y en tiempo real del trabajo que el equipo
de desarrollo planea realizar durante el Sprint, y pertenece únicamente al equipo de desarrollo.

Monitoreo del progreso de Sprint

En cualquier momento en un Sprint, se puede sumar el trabajo total que queda en Sprint Backlog. El Equipo de
Desarrollo sigue este trabajo total restante al menos para cada Daily Scrum para proyectar la probabilidad de
alcanzar el Objetivo Sprint. Al rastrear el trabajo restante a lo largo del Sprint, el Equipo de Desarrollo puede
gestionar su progreso.
Incremento
El Incremento es la suma de todos los ítems del Backlog del Producto completados durante un Sprint y el valor
de los incrementos de todos los Sprints previos. Al final de un Sprint, el nuevo Incremento debe ser "Hecho", lo
que significa que debe estar en condiciones utilizables y cumplir con la definición del Equipo Scrum de
"Hecho". Un incremento es un cuerpo de trabajo inspeccionable y realizado que respalda el empirismo al final
del Sprint. El incremento es un paso hacia una visión o meta. El incremento debe estar en condiciones
utilizables independientemente de si el Propietario del Producto decide liberarlo.

Transparencia de artefactos
Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se basan en el
estado percibido de los artefactos. En la medida en que se complete la transparencia, estas decisiones tienen
una base sólida. En la medida en que los artefactos son incompletamente transparentes, estas decisiones
pueden ser defectuosas, el valor puede disminuir y el riesgo puede aumentar.
El Scrum Master debe trabajar con el propietario del producto, el equipo de desarrollo y otras partes
involucradas para comprender si los artefactos son completamente transparentes. Hay prácticas para hacer
frente a la transparencia incompleta; el Scrum Master debe ayudar a todos a aplicar las prácticas más
adecuadas en ausencia de una transparencia completa. Un Scrum Master puede detectar una transparencia
incompleta inspeccionando los artefactos, detectando patrones, escuchando atentamente lo que se dice y
detectando diferencias entre los resultados esperados y los reales.
El trabajo del Scrum Master es trabajar con el equipo de Scrum y la organización para aumentar la
transparencia de los artefactos. Este trabajo generalmente implica aprender, convencer y cambiar. La
transparencia no ocurre de la noche a la mañana, sino que es una ruta.

Definición de "Hecho"
Cuando un ítem de Atasco del Producto o un Incremento se describe como "Hecho", todos deben entender qué
significa "Hecho". Aunque esto puede variar significativamente según el Equipo de Scrum, los miembros deben
tener una comprensión compartida de lo que significa que el trabajo se complete, para garantizar la
transparencia. Esta es la definición de "Hecho" para el Equipo de Scrum y se usa para evaluar cuándo se
completa el trabajo en el Incremento del producto.
La misma definición guía al equipo de desarrollo a saber cuántos ítems del inventario de productos puede
seleccionar durante una planificación de Sprint. El propósito de cada Sprint es entregar incrementos de
funcionalidades potencialmente liberables que se adhieran a la definición actual de "Hecho" del Equipo Scrum.
Los equipos de desarrollo ofrecen un aumento de la funcionalidad del producto cada Sprint. Este Incremento es
utilizable, por lo que un Propietario del Producto puede elegir lanzarlo inmediatamente. Si la definición de
"Hecho" para un incremento es parte de las convenciones, normas o directrices de la organización de
desarrollo, todos los equipos Scrum deben seguirla como mínimo.
Si "Hecho" para un incremento no es una convención de la organización de desarrollo, el Equipo de Desarrollo
del Equipo de Scrum debe definir una definición de "Hecho" apropiado para el producto. Si hay varios equipos
de Scrum trabajando en el lanzamiento del sistema o producto, los Equipos de desarrollo en todos los equipos
de Scrum deben definir mutuamente la definición de "Hecho".
Cada Incremento es aditivo a todos los Incrementos anteriores y probado minuciosamente, asegurando que
todos los Incrementos trabajen juntos.
A medida que los equipos Scrum maduren, se espera que sus definiciones de "Hecho" se amplíen para incluir
criterios más estrictos para una mayor calidad. Las nuevas definiciones, tal como se utilizan, pueden descubrir
el trabajo que se debe realizar en incrementos previamente "Hecho". Cualquier producto o sistema debe tener
una definición de "Hecho" que es un estándar para cualquier trabajo realizado en él.

Nota final
Scrum es gratis y se ofrece en esta guía. Los roles, eventos, artefactos y reglas de Scrum son inmutables y
aunque implementar solo partes de Scrum es posible, el resultado no es Scrum. Scrum existe solo en su
totalidad y funciona bien como contenedor de otras técnicas, metodologías y prácticas.