Qué es SCRUM

Definición
Scrum es un método para trabajar en equipo a partir de iteraciones o Sprints. Así, por lo
tanto, su objetivo será controlar y planificar proyectos con un gran volumen de cambios de
última hora, en donde la incertidumbre sea elevada.

Se suele planificar por semanas. Al final de cada Sprint o iteración, se va revisando el trabajo
validado de la anterior semana. En función de esto, se priorizan y planifican las actividades
en las que invertiremos nuestros recursos en el siguiente Sprint.

Entre las principales características de la metodología Scrum , desataca que es un desarrollo

incremental en lugar de la clásica planificación del desarrollo completo de un producto o
servicio. Sus equipos de trabajo se caracterizan por ser auto-organizados. Y se centra en el
producto final, en la calidad del mismo.

Además, en la metodología Scrum se solapan diferentes fases de desarrollo, en lugar de

llevar a cabo una planificación secuencial o de cascada

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas

prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen
en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado
para proyectos en entornos complejos, donde se necesita obtener resultados pronto,
donde los requisitos son cambiantes o poco definidos, donde la innovación,
la competitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente
lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la
calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia,
cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y
solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.

El proceso
En Scrum un proyecto se ejecuta en ciclos temporales cortos y de duración
fija (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de 3
y hasta 4 semanas, límite máximo de feedback de producto real y reflexión). Cada iteración
 tiene que proporcionar un resultado completo, un incremento de producto final que sea
susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa

como plan del proyecto. En esta lista el cliente (Product Owner) prioriza los objetivos
balanceando el valor que le aportan respecto a su coste (que el equipo estima
considerando la Definición de Hecho) y quedan repartidos en iteraciones y entregas.
Las actividades que se llevan a cabo en Scrum son las siguientes (los tiempos indicados son
para iteraciones de 2 semanas):

Planificación de la iteración
El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos
partes:

1. Selección de requisitos (2 horas). El cliente presenta al equipo la lista de requisitos

priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y
selecciona los requisitos más prioritarios que prevé que podrá completar en la iteración, de
manera que puedan ser entregados si el cliente lo solicita.
2. Planificación de la iteración (2 horas). El equipo elabora la lista de tareas de la
iteración necesarias para desarrollar los requisitos seleccionados. La estimación de esfuerzo
se hace de manera conjunta y los miembros del equipo se autoasignan las tareas,
se autoorganizan para trabajar incluso en parejas (o grupos mayores) con el fin de
compartir conocimiento (creando un equipo más resiliente) o para resolver juntos objetivos
especialmente complejos.
 Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos), normalmente
delante de un tablero físico o pizarra (Scrum Taskboard). El equipo inspecciona el trabajo
que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la
iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones
necesarias que permitan cumplir con la previsión de objetivos a mostrar al final de la
iteración. En la reunión cada miembro del equipo responde a tres preguntas:

 ¿Qué he hecho desde la última reunión de sincronización para ayudar al equipo a cumplir
su objetivo?
 ¿Qué voy a hacer a partir de este momento para ayudar al equipo a cumplir su objetivo?
 ¿Qué impedimentos tengo o voy a tener que nos impidan conseguir nuestro objetivo?

Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda

mantener el foco para cumplir con sus objetivos.

 Elimina los obstáculos que el equipo no puede resolver por sí mismo.

 Protege al equipo de interrupciones externas que puedan afectar el objetivo de la iteración
o su productividad.

Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para
prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican los
objetivos del proyecto (10%-15% del tiempo de la iteración) con el objetivo de maximizar la
utilidad de lo que se desarrolla y el retorno de inversión.

Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:

1. Revisión (demostración) (1,5 horas). El equipo presenta al cliente los requisitos

completados en la iteración, en forma de incremento de producto preparado para ser
entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios
que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias
de manera objetiva, ya desde la primera iteración, replanificando el proyecto.
2. Retrospectiva (1,5 horas). El equipo analiza cómo ha sido su manera de trabajar y cuáles
son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera
continua su productividad. El Facilitador se encargará de eliminar o escalar los obstáculos
identificados que estén más allá del ámbito de acción del equipo.

Roles de Scrum
La metodología Scrum tiene unos roles y responsabilidades principales, asignados a sus
procesos de desarrollo. Estos son:
  Project Owner. Se asegura de que el proyecto se esté desarrollando acorde con la
estrategia del negocio. Escribe historias de usuario, las prioriza, y las coloca en el
Product Backlog.
 Master Scrum o Facilitador. Elimina los obstáculos que impiden que el equipo cumpla
con su objetivo.
 Development team Member. Los encargados de crear el producto para que pueda
estar listo con los requerimientos necesarios. Se recomienda que sea un equipo
multidisciplinar, de no más de 10 personas.
Detallando los roles antes mencionados encontramos lo siguiente

El Product Owner
Cuando se trata de maximizar el valor del producto y el trabajo del Equipo de Desarrollo, es
el Product Owner el responsable de ello. Esto varía según los Equipos Scrum y las personas
del equipo. El Product Owner tiene la responsabilidad de gestionar el Backlog del Producto.
Esta gestión incluye:
 Expresar claramente los elementos del backlog de Producto

 Ordenar los elementos del Backlog de Producto para alcanzar las misiones y los
objetivos

 Optimizar el valor del trabajo que realiza el Equipo de Desarrollo

 Asegurar que el Backlog de Producto es visible, transparente y claro.

Esto revela en qué debería trabajar el Equipo Scrum y asegura que el Equipo de Desarrollo
comprende perfectamente los elementos del Backlog de Producto al nivel requerido.
Aunque el Product Owner podría delegar este trabajo en el Equipo de Desarrollo, son
responsables del resultado.
El Product Owner es una persona y no un comité. Si existe un comité en funcionamiento,
pueden presentar sus deseos en el backlog de Producto. Aquellos que quieran hacer
cualquier ajuste, necesitan consultar al Product Owner.
Para garantizar que el Product Owner tiene éxito, todas las personas de la organización
deben respetar sus decisiones, que son visibles en el contenido y orden del Backlog de
Producto. No hay nadie capaz de ordenar al Equipo de Desarrollo trabajar con requisitos
distintos, y el Equipo de Desarrollo también tiene sus acciones limitadas bajo las
instrucciones de otra persona.

El Scrum Master
El Scrum Master tiene la responsabilidad de asegurar que se ha entendido y aprobado el
método Scrum. Trabajan con el Equipo Scrum, por lo que pueden adherirse a la teoría,
prácticas y reglas de Scrum. El Scrum Master es esencialmente el líder-ayudante del Equipo
Scrum. Si te encuentras en la situación de que eres el Scrum Master de dos equipos, echa
un vistazo a: “Las Dos Preguntas más Importantes sobre Liderar 2 Equipos como Scrum
Master”.
El Scrum Master ayuda a las personas que no están en el Equipo Scrum a entender cuáles
de sus interacciones con el Equipo Scrum son útiles y cuáles no.
Entendiendo el Servicio del Scrum Master
Hay tres grupos de Servicio del Scrum Master, y estos incluyen:
El Servicio del Scrum Master para el Product Owner
Esto se hace de numerosas maneras, incluyendo:
Encontrar técnicas para gestionar de manera efectiva el Backlog de Producto
Ayudar al Equipo Scrum a entender la necesidad de tener elementos claros y concisos en el
backlog de Producto
Comprensión del planteamiento de producto en un ambiente empírico
Asegurar que el Product Owner conoce la mejor manera de organizar el backlog de Producto
para maximizar el valor
Comprensión y práctica de la agilidad.
Facilitar eventos de Scrum según se requiera
El Servicio del Scrum Master para el Equipo de Desarrollo
Aquí, el Scrum Master ayudará al Equipo de Desarrollo de las siguientes maneras:
Actuar de coach en temas de auto-organización y multifuncionalidad
Ayudar al Equipo de Desarrollo a crear productos de alto valor
Eliminar los Impedimentos del progreso del Equipo de Desarrollo
Facilitar eventos de Scrum según se requiera
Actuar como coach en ambientes de organización donde el método Scrum no ha sido
totalmente adoptado o entendido
Servicio del Scrum Master para la Organización
Los Scrum Masters pueden ayudar a la organización de varias maneras, como:
Liderar al equipo y actuar de coach en la adopción del método Scrum
Planear la implementación de Scrum en la organización
Ayudar a empleados y partes interesadas a entender el desarrollo de Scrum y el desarrollo
empírico de productos
Causar cambios que lleven al incremento de la productividad del Equipo Scrum
Trabajar con otros Scrum Masters para aumentar la efectividad de la implantación de Scrum
en la organización

El Equipo de Desarrollo
Es un equipo formado por profesionales que trabajan para entregar un Incremento de
producto “Finalizado” que se pueda lanzar al final de cada Sprint. Solo los miembros de este
equipo pueden crear el Incremento.

La organización asegura que el Equipo de Desarrollo está empoderado para organizar y

gestionar su trabajo. La sinergia que ocurre, como resultado, optimizará la eficiencia y
efectividad del Equipo de Desarrollo.
Estos equipos tienen las siguientes características:

 Se auto-organizan. No reciben instrucciones ni consejo de nadie sobre cómo convertir

el Backlog de Producto en Incrementos de funcionalidades potencialmente liberables.

 Son multifuncionales y tienen todas las habilidades necesarias para crear un

Incremento de producto.

 Scrum no otorga ningún título al Equipo de Desarrollo. Todo el mundo es

desarrollador, sin importar el trabajo que desempeñen. Esto se aplica sin excepciones.

 Dentro del Equipo de Desarrollo, el Scrum reconoce que no hay sub-equipos. Esto
ocurre incluso cuando hay muchos dominios que tienen que ser tratados, como el
análisis de negocios o el testeo. Esto se aplica sin excepciones.

 Cada miembro del Equipo de Desarrollo podría tener una habilidad o zona de confort
especial, pero si hablamos de responsabilidades, se considera al equipo como un
todo.

El Equipo de Desarrollo se compone de muchas personas, siendo tres el número óptimo.

Esto asegura que se mantienen ágiles y son un lo suficientemente grandes para finalizar
todo el trabajo que se debe hacer en un Sprint.

Si el equipo tiene menos de tres miembros, la interacción puede verse reducida, lo que
significa que se tendrá menor productividad. Además, los Equipos de Desarrollo pequeños
pueden ver restringidas sus capacidades durante el Sprint, significando que podrían no ser
capaces de entregar un Incremento potencialmente liberable.

Los equipos grandes, como aquellos con más de nueve miembros, necesitan mucha más
coordinación. Acaban generando demasiada complejidad como para gestionar un proceso
empírico. Al contar al Equipo de Desarrollo, no se cuenta al Product Owner ni al Scrum
Master a no ser que también estén realizando el trabajo del Backlog del Sprint.

Valores de Scrum
Hay muchos valores que el Equipo Scrum debe encarnar. Estos son el coraje, el compromiso,
la sinceridad, el respeto Estos valores son básicos para erigir los pilares del método Scrum
y conseguir confianza con todas las personas envueltas en él.
Los miembros del Equipo Scrum aprenden y exploran estos valores al trabajar en eventos y
roles de Scrum. Para que el método Scrum tenga éxito, es necesario que los miembros del
equipo sean competentes en estas cinco características.
Así lo hacen:
  Tienen el coraje para hacer lo que es correcto y abordar los problemas graves
 Se comprometen a alcanzar los objetivos del equipo
 Los inversores y el equipo acuerdan hablar abiertamente sobre el trabajo y las
dificultades que tiene el mismo
 Se respetan los unos a los otros y confían en que son independientes y capaces
 Se centran en el trabajo del Sprint y los objetivos del equipo

Entendiendo el Sprint
El corazón del método Scrum es el Sprint. Se puede definir como un periodo de tiempo de
un mes o menos en el que se crea un producto liberable, utilizable y “Finalizado”.
Normalmente tienen una duración consistente durante un periodo de desarrollo. Los
sprints deberían tener duraciones constantes durante todo el desarrollo. Un nuevo Sprint
comienza solo cuando el anterior ha finalizado.
Los Sprints contienen y consisten de la Planificación del Sprint, los Scrums Diarios, la
Revisión del Sprint, la Retrospectiva del Sprint y el Trabajo de Desarrollo.
Cuando el Sprint está en curso, no debería haber ninguna alteración que pudiera afectar al
objetivo del mismo, los objetivos cualitativos no descienden, y el enfoque podría ser
aclarado y renegociado entre el Product Owner y el Equipo de Desarrollo.
Es seguro considerar cada Sprint como un proyecto de un mes en el que se ha de conseguir
algo. Por esta razón, en el Sprint se define claramente qué se va a construir, diseñar, un plan
para la producción, el trabajo y el producto final. Si el Sprint durara más de un mes, la
definición de lo que se va a crear cambiaría, y el riesgo podría subir junto a la complejidad
general. Los Sprints son importantes ya que aseguran que el trabajo es predecible y puede
ser inspeccionado y adaptado mientras se trabaja por el objetivo del Sprint. Limitan el
riesgo, particularmente si nos fijamos en el coste.
Es posible cancelar un Sprint antes de que finalice. Sin embargo, la única persona que puede
hacer esto es el Product Owner. La decisión puede estar influenciada por otros, incluyendo
las partes interesadas, el Equipo de Desarrollo o el Scrum Master. Una cancelación puede
hacerse efectiva cuando el Objetivo del Sprint se vuelve obsoleto.
La obsolescencia puede estar causada por el azar en la dirección, las condiciones del
mercado o las condiciones de la tecnología. Si el Sprint deja de tener sentido, debería ser
cancelado. Sin embargo, verás que raramente se cancela un Sprint, ya que tienen una
duración bastante corta.
Hay una serie de pasos que hay que cumplir al cancelar un Sprint. Se revisan primero los
elementos completados y “Finalizados” del Backlog de Producto. Si algo del trabajo del
Sprint puede liberarse, será aceptado por el Product Owner. Esos elementos que son
incompetentes en el backlog de Producto se reestiman y devuelven al Backlog de Producto.
Ya que este tipo de trabajo se puede depreciar rápidamente, se debe revalorar
frecuentemente.
Las cancelaciones desaniman, ya que consumen recursos. Esto se debe a que todas las
personas envueltas en el Sprint tienen que reagruparse y realizar otro proceso de
planificación del Sprint, para comenzar uno nuevo. Causan malestar en el equipo y se trata
de evitarlas.
Planificación del Sprint
Cualquier trabajo que va a hacerse en el Sprint se planea en la Planificación del Sprint. La
planificación une al Equipo Scrum y se crea mediante un trabajo colaborativo. La
planificación del Sprint tiene una duración concreta de ocho horas como máximo para un
Sprint de un mes; aquí puedes encontrar sugerencias sobre cómo llevar a cabo una efectiva
planificación del sprint.
Cuando el Sprint dura menos, también el evento tiene a ser más corto. Depende del Scrum
Master asegurar que el evento tiene lugar y que los asistentes entienden la razón del
mismo. El Scrum Master enseñará al equipo a mantenerse en la duración establecida.
En la Planificación se responden las preguntas sobre qué se puede liberar en el Incremento
del siguiente Sprint, y cómo se conseguirá realizar el trabajo que se va a liberar.
¿Qué se puede liberar en el siguiente Sprint?
Durante el periodo de Planificación del Sprint, el Equipo de Desarrollo trabajará en
pronosticar la funcionalidad que será desarrollada durante el Sprint. El Product Owner
analizará el objetivo que se busca en el Sprint. Más allá, los elementos del Backlog de
Producto que ayudarán a conseguir dicho objetivo. El Equipo Scrum al completo trabajará
conjuntamente para comprender el trabajo del Sprint.
Esta reunión tiene unos aportes principales, que son el Backlog de Producto, el último
Incremento de producto, la capacidad esperada del Equipo de Desarrollo durante el Sprint
y el rendimiento previo del mismo. El Equipo de Desarrollo seleccionará cuántos elementos
del Sprint provendrán del backlog de Producto. Es el Equipo de Desarrollo quien
proporcionará información sobre qué pueden conseguir, basándose en las expectativas del
Sprint.
Después del pronóstico de los elementos del Backlog de Producto, el Equipo de Desarrollo
llevará a cabo el Sprint, mientras que el Equipo Scrum podría establecer el Objetivo del
Sprint. El Objetivo del Sprint es el propósito que se alcanzará en el Sprint cuando el Backlog
de Producto haya sido implementado. Sirve como guía para el Equipo de Desarrollo sobre
por qué se crea el Incremento.
Si te interesa este tema, hace un tiempo Chris escribió un artículo en el blog: “Cuatro
Razones Por las Que no se Llevan a Cabo las Historias de Usuario Ágiles”, échale un vistazo.
¿Cómo se logrará el trabajo?
Una vez que se ha establecido el Objetivo del Sprint y que los elementos de Backlog de
Producto se han seleccionado, entonces el Equipo de Desarrollo decidido cómo se
construirá la funcionalidad para conseguir un Incremento del producto “Finalizado” durante
el Srpint. Los elementos del Backlog de Producto elegidos para este Sprint, junto al plan
para liberarlos, se conoce como Backlog del Sprint.
El Equipo de Desarrollo diseñará un sistema para convertir el Backlog de Producto en un
Incremento de producto funcional. La carga de trabajo puede variar según el esfuerzo
necesario y el tamaño del trabajo. Durante la Planificación del Sprint, el Equipo de
Desarrollo pronosticará qué piensan que se puede conseguir en el siguiente Sprint.
Al final de la reunión, el trabajo planeado para los primeros días del Sprint, que debe realizar
el Equipo de Desarrollo, se descompone en unidades diarias (o menos). La auto-
organización tiene lugar a la hora de realizar el trabajo del Backlog del Sprint, tanto durante
la Planificación del Sprint como cuando sea requerido en el Sprint.
El Product Owner tiene la tarea de ayudar a aclarar los elementos del Backlog de Producto
elegidos e intercambiarlos cuando sea necesario. Si el Equipo de Desarrollo decidiera que
es mucho o poco trabajo, entonces debería ser renegociado basándose en los elementos
del Backlog de Producto.
Esto se hace junto al Product Owner. El Equipo de Desarrollo tiene también la libertad de
invitar a otros a asistir en beneficio del dominio o para dar consejos técnicos. Al final de la
Planificación del Sprint, el Equipo de Desarrollo debería tener la capacidad de explicar al
Product Owner y al Scrum Master cómo se realizará el trabajo trabajando como un equipo
auto-organizado para alcanzar el Objetivo del Sprint.

Objetivo del Sprint

Es un objetivo que se pone en el Sprint, que se consigue con facilidad una vez que se ha
implementado el Backlog de Producto. Actúa, de alguna manera, como una guía al Equipo
de Desarrollo sobre la razón por la que se crea el Incremento. El Objetivo del Sprint se
establece en la reunión de Planificación del Sprint.

Se asegura que el Equipo de Desarrollo tiene un nivel de flexibilidad, en relación a la

funcionalidad implementada en el Sprint. El Objetivo del Sprint se entrega a través de los
Elementos del Backlog del Producto y asegura que el Equipo de Desarrollo puede trabajar
conjuntamente, en lugar de dividirse en diferentes iniciativas.

El Equipo de Desarrollo trabaja con el Objetivo del Sprint siempre en la mente, y esto afecta
su funcionalidad y uso de la tecnología. Cuando haya un cambio en las expectativas, el
Equipo de Desarrollo y el Product Owner facilitarán la colaboración para negociar el
enfoque que se da al Backlog de Producto en el Sprint.

Revisión del Sprint

La Revisión del Sprint se lleva a cabo una vez que el Sprint ha finalizado. En ella, se
inspecciona el Incremento y se adapta el Backlog de Producto si fuera necesario. Cuando la
Revisión del Sprint tiene lugar, el Equipo Scrum y las partes interesadas evalúan qué se ha
hecho durante el Sprint.

El resultado de la discusión podría llevar a adoptar cambios en el backlog de Producto, así

como a la revisión de lo que podría ser optimizado con el objetivo de añadir valor. La
revisión sirve para compartir información y no es una reunión sobre el estado del proyecto.
Solo se mantiene para conseguir algo de feedback y para asegurar que existe colaboración.
Duraría unas cuatro horas si el Sprint fuera de un mes. Si el Sprint fuera más corto, también
lo sería la reunión.

Incluye los siguientes elementos:

Asistencia del Equipo Scrum y de las partes interesadas, invitados por el Product Owner

El Product Owner explica qué elementos del Backlog de Producto están “Finalizados” y
cuáles no.

El Equipo de Desarrollo explica qué funcionó durante el Sprint y qué no funcionó, y cómo
se solventaron los problemas

El Equipo de Desarrollo revela qué se ha “Finalizado” y propone preguntas sobre el

Incremento

El Product Owner habla sobre el estado del Backlog de Producto y posibles fechas de
finalización de los proyectos

El grupo al completo colabora en los siguientes pasos, de manera que la Revisión del Sprint
proporciona información valiosa para la Planificación de próximos Sprints

Revisar el mercado o el posible uso del producto, cualquier cambio, y lo mejor para hacer a
continuación

Revisar el cronograma, el presupuesto, las capacidades y el mercado para el lanzamiento

del producto

Después de la Revisión del Sprint, el Backlog de Producto se suele revisar, y se definen los
elementos del Backlog de Producto que se utilizarán probablemente en el siguiente Sprint.
Puede que se hagan ajustes generales para encontrar nuevas oportunidades.

Retrospectiva del Sprint

Es una oportunidad para el Equipo Scrum de realizar una inspección sobre lo que se ha
realizado y desarrollar un plan para conseguir mejoras en el siguiente Sprint. Ocurre una
vez que la Revisión del Sprint se ha finalizado, antes de que la Planificación del Sprint vuelva
a comenzar.

Es una reunión con una duración concreta de unas tres horas para Sprints de un mes. Sprints
más cortos darán lugar a reuniones más cortas. El Scrum Master se asegurará de que la
reunión tiene lugar y los asistentes entienden claramente su propósito.

El Scrum Master participará como un miembro del equipo para proporcionar información
sobre las responsabilidades en el proceso Scrum. El objetivo de esta reunión es:

 Inspeccionar el último Sprint

 Identificar y ordenar lo que funcionó y lo que necesita ser mejorado

  Desarrollar un plan para implementar mejoras al Equipo Scrum y la manera en que
trabajan

El Scrum Master usará esta reunión para animar al Equipo Scrum a mejorar en las prácticas
y procesos del desarrollo. Esto asegurará que el siguiente Sprint sea más efectivo y
disfrutable. Se implementan los planes para elevar la calidad del producto, estableciendo
una definición apropiada de producto “Finalizado”.

Una vez que se ha completado la Retrospectiva del Sprint, el Equipo Scrum habrá
identificado qué se puede mejorar en el siguiente Sprint. Se adoptarán estas mejoras y
serán inspeccionadas por el propio Equipo Scrum. La Retrospectiva del Sprint es una
oportunidad formal de centrarse en la inspección y la adaptación.

Si te interesa este tema, puedes echar un vistazo a mi otro artículo: “La Guía Sobre Las
Retrospectivas Ágiles Que Te Convertirá En Un Magnífico Facilitador”. Mi amigo Marc
Loeffler escribió este artículo: “Las cinco preguntas más comunes sobre las Retrospectivas
Ágiles”. Y, por supuesto, si buscas nuevas ideas para tu Retrospectiva del Sprint, echa un
vistazo a: “Ideas sobre las Retrospectivas Ágiles”.

Monitorizar el Progreso del Sprint

Durante el Sprint, se puede resumir el Backlog del Sprint en cualquier comento. Depende
del Equipo de Desarrollo el monitorizar en cada Scrum Diario el trabajo restante para
alcanzar el Objetivo del Sprint. Monitorizarlo le permite al Equipo de Desarrollo gestionar
el progreso del proyecto.

Incremento
Se puede resumir todo el trabajo que resta del Backlog del Sprint en cualquier momento. El
Incremento es la suma de esto y del valor de cualquier otro Incremento de Sprints previos.
El incremento final al terminar el Sprint debería estar “Finalizando”, que significa que está
en una condición utilizable y cumple con la definición establecida por el Equipo Scrum. La
condición utilizable es indispensable, sea cual sea la decisión del Product Owner de lanzarlo
o no.