2. Modelo Core de Scrum

En este capítulo, hablaremos de las bases de Scrum, abriendo la caja para mostrar cada una de sus piezas fundamentales: el equipo, los artefactos, los eventos y la teoría que lo sostiene. Piensa en ello como los ingredientes básicos que necesitas para el desarrollo de productos exitosos. Puntos Clave de Este Capítulo: - Descubre quiénes componen el equipo en Scrum y cuál es su función. - Identifica los artefactos que actúan como herramientas de trazabilidad y planeación. - Reconoce los eventos que mantienen en marcha el proceso Scrum. - Comprende la teoría de Scrum que vincula todas las piezas juntas.

• 2.1 - El equipo Scrum
• 2.2 - Artefactos en Scrum
• 2.3 - Eventos en Scrum
• 2.4 - Teoría de Scrum

2.1 - El equipo Scrum

Un Equipo Scrum consiste en un Propietario del Producto (Product Owner), un Scrum Master y los Developers; y se trata de una unidad cohesionada de profesionales centrados en un objetivo a la vez: el Objetivo de Producto (Product Goal).

Los Equipos Scrum son auto-gestionados y multifuncionales. El modelo de Equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad.

Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades para poder obtener retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.

Tamaño del Equipo Scrum

El tamaño óptimo de un Equipo Scrum es 10 personas o menos, esto le permite ser lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para poder completar una cantidad significativa de trabajo.

Consideraciones:

• No se recomienda tener menos de 3 miembros en el Equipo pues se reduce la interacción y resulta en baja productividad.
• Los Equipos más pequeños pueden encontrar limitaciones en cuanto a las habilidades necesarias durante un Sprint, haciendo que el Incremento pudiese no ser significativo para el cliente.
• Tener más de 10 miembros en el equipo requiere demasiada coordinación.
• Los Equipos muy grandes generan demasiada complejidad y dificultades en la comunicación como para que un proceso empírico pueda ser de utilidad.
• Los roles de Product Owner y Scrum Master no se cuentan como Developers, a menos que también estén contribuyendo al desarrollo del trabajo durante el Sprint.

---

1. El Product Owner (Dueño de Producto)

• El Product Owner es el responsable de maximizar el valor entregado por los Developers
• Es el representante de todos los interesados (stakeholders) en los resultados del producto
• Actúa como interlocutor único ante el equipo Scrum, con autoridad para tomar decisiones.
• Es el encargado de garantizar los resultados del producto.
• El Product Owner (P.O) es una única persona, no un comité.
• Es considerado como “La voz del cliente”
• Es la única persona responsable de gestionar el Product Backlog.

La gestión del Product Backlog incluye:

• Expresar claramente los elementos del Product Backlog.
• Ordenar los elementos en el Product Backlog para alcanzar los objetivos y las misiones de la mejor manera posible.
• Garantizar que el Product Backlog sea visible, transparente y clara para todos y que muestre, lo que el equipo trabajará a continuación.
• Asegurar que los Developers entienden los elementos del Product Backlog a nivel necesario.
• El Product Owner es una única persona, no un comité. El Product Owner podría representar los deseos de un comité en el Product Backlog, pero aquellos que quieran cambiar la prioridad de un elemento del Product Backlog deben hacerlo a través del Product Owner.

Para que el Product Owner pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones. Las decisiones del Product Owner se reflejan en el contenido y en la priorización del Product Backlog.

Responsabilidades del Product Owner

• Participar en las reuniones de planificación y revisión de las iteraciones (sprints).
• Entender las necesidades de las partes interesadas para posteriormente levantar los requerimientos que harán parte del Product Backlog.
• Mantener comunicación frecuente con el cliente (ya que es el único punto de contacto entre el cliente y el Equipo Scrum).
• Gestionar los riesgos globales del proyecto.
• Presentar informes del proyecto al cliente u otras partes interesadas.
• Aprobar cambios en el proyecto.
• Asegurar que se administran correctamente los recursos financieros del proyecto al inicio y durante su ejecución.
• Participar en las reuniones de apertura y cierre del proyecto.

Normalmente el rol del Product Owner se asocia con un Gerente de Proyecto, dadas sus responsabilidades de gestión, sin embargo, estos roles NO son iguales. Es más preciso asociarlo al rol que representa “La voz del cliente”.

---

2. Desarrolladores (Developers)

Los Developers son los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” (Done) que potencialmente se pueda poner en producción al final de cada Sprint. Solo los Developers participan en la creación del Incremento.

Responsabilidades de los Developers

• Crear un plan para el Sprint: el Sprint Backlog
• Asegurar la calidad con el cumplimiento de la Definición de Terminado (Definition of Done)
• Adaptar su plan de trabajo diario para alcanzar el Objetivo del Sprint (Sprint Goal)
• Responsabilizarse del trabajo.

Nota: Se llaman “Desarrolladores”, porque desarrollan el producto (no necesariamente software)

La organización es la encargada de estructurar y empoderar a los Developers para que estos organicen y gestionen su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad del Equipo Scrum en conjunto.

Los Developers tienen las siguientes características:

• Son autogestionados. Nadie (ni siquiera el Scrum Master) les da órdenes o imposiciones sobre cómo convertir elementos del Product Backlog en Incrementos de funcionalidad potencialmente desplegables.
• Nadie fuera del Scrum Master y el Product Owner puede pedir a los Developers que trabajen en un conjunto diferente de requisitos que previamente hayan sido planeados y acordados.
• Los Developers son multifuncionales, con todas las habilidades necesarias para crear un Incremento de producto.
• Scrum no reconoce títulos para los miembros de un Equipo Scrum, independientemente del trabajo que realice cada persona, quienes ejecuten el trabajo necesario para construir el producto se conocen como Developers.
• No existen sub-equipos en el Equipo Scrum, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas, aseguramiento de calidad, arquitectura, operaciones, o análisis de negocio.
• Los Developers pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad del producto recae sobre los Developers como un todo.

---

3. El Scrum Master (Maestro Scrum)

El Scrum Master es un facilitador, responsable de promover y apoyar Scrum como se define en la Guía de Scrum. Su principal responsabilidad entonces es garantizar que todos conocen y aplican correctamente la teoría y práctica de Scrum.

• El Scrum Master es un líder que sirve al Equipo Scrum y en general a toda la organización.
• El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no.

El Scrum Master al servicio del Equipo y los Desarrolladores (Developers)

El Scrum Master sirve a los desarrolladores de varias formas, incluyendo:

• Guiar a los Desarrolladores para que aprendan a ser autogestionados y multifuncionales.
• Ayudar a los Desarrolladores a centrarse en crear productos de alto valor además de cumplir con la Definición de Terminado.
• Eliminar impedimentos para el progreso de los Desarrolladores.
• Facilitar los eventos de Scrum según se requiera o necesite, para que sean productivos, respetando el tiempo designado para cada uno (time-box).
• Guiar a los Desarrolladores en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.

El Scrum Master al servicio del Product Owner

El Scrum Master sirve al Product Owner de varias formas, incluyendo:

• Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el Equipo de la mejor manera posible.
• Ayudar a encontrar técnicas para gestionar el Product Backlog, definir el Objetivo de Producto (Product Goal) y gestionar los atrasos en el producto.
• Ayudar al Equipo Scrum a entender la necesidad de contar con elementos del Product Backlog claros y concisos.
• Entender la planificación del producto en un entorno empírico y complejo.
• Ayudar a entender y practicar la agilidad.
• Facilitar la colaboración de las partes interesadas y/o cliente según sea necesario.

El Scrum Master al servicio de la Organización

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

• Liderar y guiar a la organización en la adopción de Scrum.
• Planificar y asesorar en la adopción de Scrum en la organización.
• Ayudar a los empleados e interesados a entender y poner en práctica un enfoque empírico en el desarrollo del trabajo.
• Motivar cambios que incrementen la productividad en la organización.
• Junto con otros Scrum Masters, incrementar la efectividad de la adopción de Scrum en la organización.
• Eliminar las barreras de comunicación entre los Equipos Scrum y las diferentes partes interesadas.

Scrum NO considera el rol tradicional de “Gerente del Proyecto”. Entonces, ¿a dónde van estos empleados? Lo más frecuente y natural es que los Gerentes de Proyecto hagan una transición hacia Product Owners e incluso a Scrum Masters. Sin embargo, muchos buenos Scrum Masters provienen de los desarrolladores y QA; por lo tanto el Scrum Master no es ni remotamente parecido al del Gerente de Proyecto, y por esto es importante que el candidato a Scrum Master adquiera capacitación en Scrum.

El Scrum Master debe aceptar que el equipo es dueño de la agenda de trabajo, así que no más actualizar los viejos Diagramas de Gantt. Debe alentar al equipo para que mantenga actualizadas sus estimaciones diarias. El Scrum Master asegura que se siga el proceso de Scrum, que todos entienden Scrum y cómo funciona.

El Scrum Master debe quitar impedimentos, o asistir en quitar impedimentos, lo más rápido posible.

Se asegura que el equipo se mantiene en rumbo, recordándole al equipo el objetivo del Sprint en cada reunión.

Organiza los Scrums diarios (Reunión diaria), y se asegura que se realice en el mismo lugar a la misma hora.

Traducido de Coping with change on Scrum projects, por Jack Milunksy.

---

Comunicación en el equipo

2.2 - Artefactos en Scrum

Los artefactos de Scrum representan el trabajo o el valor en diversas formas, los cuales son útiles para proporcionar transparencia y oportunidades para la 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, necesaria para asegurar que todos tengan el mismo entendimiento sobre el Producto.

Cada artefacto está vinculado con un compromiso para garantizar que se cuenta con información suficiente sobre el producto, esto mejora la transparencia y el enfoque con el que se puede medir el progreso:

• Para el Product Backlog el compromiso es el Objetivo de Producto (Product Goal).
• Para el Sprint Backlog el compromiso es el Objetivo del Sprint (Sprint Goal).
• Para el Incremento el compromiso es la Definición de Terminado (Definition of Done - DoD).

Antes de abordar los artefactos, ¿qué es un Producto?

Un producto es un vehículo para aportar valor y se refiere a cualquier resultado entregable y potencialmente utilizable que se desarrolla durante un determinado tiempo. Tiene un límite claro, partes interesadas conocidas, usuarios o clientes bien definidos. Un "producto" puede ser un bien tangible o intangible, como un software, una aplicación, un documento, un servicio, un producto físico o cualquier otro artefacto que proporcione valor a los clientes o usuarios finales.

---

1. El Product Backlog

El Product Backlog es una lista ordenada de todos los elementos que podrían ser necesarios para el producto y es la única fuente de requisitos para cualquier cambio a realizarse en el producto, y también es la única fuente de trabajo para el Equipo Scrum.

El Product Owner es el responsable del Product Backlog, incluyendo su contenido, disponibilidad y ordenación.

Un Product Backlog siempre esta en constante actualización. El desarrollo inicial de los elementos del Product Backlog solo refleja los requisitos conocidos y mejor entendidos al principio.

El Product Backlog evoluciona a medida que el producto y el entorno en el que se usará también lo hacen. El Product Backlog es dinámico; cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Mientras el producto exista, su Product Backlog también existe.

El Product Backlog enumera todas las características, funcionalidades, requisitos, mejoras, correcciones y cambios a realizarse sobre el producto para entregas futuras. Los elementos del Product Backlog tienen como mínimo los siguientes atributos:

• La descripción (en función del valor para el negocio)
• El orden (prioridad)
• La estimación
• Los criterios de aceptación

A medida que un producto es utilizado y se incrementa su valor y el mercado proporciona retroalimentación, el Product Backlog se convierte en una lista más larga y exhaustiva. Los elementos estan en constante actualización así que el Product Backlog es un artefacto vivo. Los cambios en los requisitos de negocio, las condiciones del mercado o la tecnología podrían causar cambios en el Product Backlog.

¡Nota Importante! Para evitar proyectos que nunca terminan, es importante considerar el alcance del producto a la hora de crear y actualizar el Product Backlog.

El compromiso del Product Backlog es el Product Goal

Product Goal (Objetivo del Producto)

• Es el estado futuro del producto que el equipo toma como referencia para planificar su trabajo.
• El Product Goal podría incluir también las restricciones a las cuales se enfrenta el desarrollo del producto (tiempo, costo, alcance, calidad) con el fin de asegurar que se cumple con las necesidades del cliente.
• El Product Goal es el objetivo a largo plazo para el Equipo Scrum. Deben cumplir (o abandonar) un objetivo antes de asumir el siguiente.
• El Product Goal se encuentra en el Product Backlog.

---

2. El Sprint Backlog

El Sprint Backlog es un conjunto de los elementos del Product Backlog que han sido seleccionados para desarrollarse durante un Sprint, el cual constituye un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint.

El Sprint Backlog es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”.

Cuando se requiere nuevo trabajo, el Equipo de Desarrollo lo adiciona al Sprint Backlog. A medida que el trabajo se ejecuta o se completa se va actualizando la estimación de trabajo restante. Cuando algún elemento del plan se considera innecesario, es eliminado. Solo el Equipo de Desarrollo puede cambiar su Sprint Backlog durante un Sprint. El Sprint Backlog es una imagen visible en tiempo real del trabajo que el Equipo de Desarrollo planea llevar a cabo durante el Sprint y pertenece únicamente al Equipo de Desarrollo.

• El Sprint Backlog hace visible todo el trabajo que el Equipo de Desarrollo debe completar para alcanzar el Objetivo del Sprint.
• Para asegurar el mejoramiento continuo, en el Sprint Backlog se incluye por lo menos una actividad que permita la mejora de procesos (normalmente identificadas en la Retrospectiva inmediatamente anterior).
• El Sprint Backlog es un plan con un nivel de detalle suficiente como para que los cambios en el progreso se puedan entender en el Scrum Diario.

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 de trabajo para entregar el Incremento (cómo).

El compromiso del Sprint Backlog es el Sprint Goal

Sprint Goal (Objetivo del Sprint)

Es el Objetivo único para el Sprint, el cual se verá reflejado al entregar el incremento de producto generado al final de un Sprint.

El objetivo de Sprint se define durante la Planificación de Sprint y, a continuación, se agrega al Backlog de Sprint (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 Objetivo del Sprint.

---

3. Incremento de Producto

Un Incremento es el resultado que entregan los Desarrolladores al final de cada Sprint, el cual se suma al valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint el nuevo Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser utilizado y que cumple con la Definición de “Terminado” del Equipo Scrum.

• El incremento es un paso hacia la visión del producto (Product Goal).
• El incremento debe estar en condiciones de utilizarse sin importar si el Product Owner decide liberarlo o no.

El compromiso del Incremento es la Definición de Terminado (DoD)

Definición de Terminado (DoD - Definition Of Done)

Es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto.

• La Definición de terminado (Criterios de terminado) es definida en conjunto por el Equipo Scrum.
• La DoD puede ser definida para cada incremento o para el producto en general.
• Si un incremento no cumple con la Definición de Terminado, no puede ser aprobado.

Un ejemplo genérico de criterios de terminado puede ser:

• Los elementos fueron revisados por otros miembros del equipo (se realizaron las pruebas de colegas).
• No existen defectos o los defectos están arreglados.
• Se completaron las pruebas unitarias.
• Se finalizó toda la documentación técnica y de usuario final.
• Todos los archivos y documentos del proyecto están en el repositorio de la organización.

2.3 - Eventos en Scrum

Los eventos en Scrum, también conocidos como sesiones de trabajo, son momentos estructurados que facilitan la colaboración, la transparencia y la inspección regular, promoviendo una ejecución ágil de los proyectos. Aquí está una descripción concisa de cada uno y su propósito:

• Sprint: Es el corazón de Scrum, un periodo de tiempo determinado (usualmente de dos a cuatro semanas) donde se realiza un incremento de producto "potencialmente entregable". Sirve para mantener al equipo enfocado en un conjunto de objetivos específicos.

• Planificación del Sprint (Sprint Planning): Al inicio de cada sprint, el equipo se reúne para planificar y acordar los elementos del backlog del producto que serán abordados durante ese sprint. Facilita la colaboración y la alineación de expectativas entre los miembros del equipo.

• Daily Scrum (Scrum Diario): Es una reunión corta (15 minutos) que tiene lugar cada día durante el sprint. Permite a los desarrolladores compartir actualizaciones sobre su progreso y planificar el trabajo del día, ayudando a identificar obstáculos tempranamente.

• Revisión del Sprint (Sprint Review): Al final del sprint, el equipo se reúne para evaluar y demostrar el trabajo realizado. Facilita la inspección del incremento de producto y ajustes basados en el feedback de los stakeholders.

• Retrospectiva del Sprint (Sprint Retrospective): Es una reunión que ocurre después de la revisión del sprint y antes de la próxima planificación del sprint. Sirve para que el equipo reflexione sobre su forma de trabajar y acuerde maneras de mejorar para el próximo sprint.

En Scrum existen diferentes eventos predefinidos con el fin de crear regularidad, minimizar la necesidad de reuniones innecesarias y permitir la transparencia.

Todos los eventos tienen un periodo de tiempo limitado (time-box), de tal modo que todos tienen una duración máxima, y se llevan a cabo al mismo tiempo y en el mismo lugar para reducir la complejidad.

1. El Sprint

¿De qué se trata un Sprint?

Los Sprints son el latido del corazón de Scrum, donde todas las ideas se convierten en valor. El Sprint es un evento con un tiempo asignado (time-box) de 1 a 4 semanas durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.

Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior. Los Sprints contienen y consisten en la Planificación del Sprint, los Scrum Diarios, el desarrollo del trabajo, la Revisión del Sprint, y la Retrospectiva del Sprint.

Cada Sprint puede considerarse como un “mini-proyecto” con un horizonte no mayor de un mes. Al igual que los proyectos, los Sprints se usan para alcanzar una meta. Cada Sprint tiene un objetivo de lo que se construirá, es decir, el Objetivo del Sprint (Sprint Goal), un diseño y un plan flexible que guiará su construcción, el trabajo del equipo y el incremento de producto resultante.

Los Sprints habilitan la predictibilidad al asegurar la inspección y adaptación del progreso al menos en cada mes calendario.

¿Cuál es la duración de un Sprint?

Típicamente, el Sprint dura entre 1 y 4 semanas (un mes calendario), siendo 2 semanas el duración más común.

Cuando el horizonte de un Sprint es mayor a un mes, la complejidad podría incrementarse y el riesgo podría aumentar.

¿Quiénes participan durante el desarrollo del Sprint y cómo se involucran?

• Scrum Master: Ayuda al equipo a mantenerse enfocado en la meta del Sprint, facilita la resolución de impedimentos y garantiza que se sigan las prácticas Scrum.
• Product Owner: Asegura que el equipo tenga una visión clara del valor que deben entregar, prioriza las tareas y proporciona claridad sobre las historias de usuario o requerimientos.
• Developers: Implementan las funcionalidades, mantienen una comunicación constante sobre el progreso y colaboran para cumplir con la meta del Sprint.

¿Qué se necesita para poder llevar a cabo un Sprint?

• Un Product Backlog priorizado.
• Un Sprint Goal o meta definido en la Planificación del Sprint.
• Un Sprint Backlog con los elementos seleccionados y su plan de trabajo.

¿Qué sucede durante el Sprint?

No hay una "agenda" para el Sprint como tal, pero el flujo general es:

1. Comenzar a trabajar en los elementos del Sprint Backlog.
2. Realizar reuniones diarias de sincronización (Daily Scrum).
3. Trabajar colaborativamente para resolver impedimentos.
4. Asegurarse de que se cumplan las definiciones de terminado ("Definition of Done") para los ítems completados.

¿Qué resulta del Sprint?

• Un incremento potencialmente entregable del producto.
• Actualizaciones al Product Backlog basadas en el aprendizaje y el trabajo durante el Sprint.

Consideraciones sobre la duración del Sprint

• Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse.
• Durante el Sprint no se realizan cambios que puedan afectar al objetivo del Sprint.
• La calidad del producto no debe disminuir.
• El alcance puede clarificarse y renegociarse con el Product Owner a medida que se va aprendiendo más.
• Todos los eventos relacionados con el Sprint deben ejecutarse dentro del tiempo del Sprint (Planificación, Scrum Diario, Revisión y Retrospectiva), la falta de alguno de estos eventos da como resultado una reducción de la transparencia y constituye una oportunidad perdida de inspección y adaptación.
• La duración de los Sprint dependerá de los siguientes factores:
  • Fechas de entrega acordadas con el cliente
  • Experiencia del equipo (a menor experiencia con Scrum, los Sprints deberían ser más cortos)
  • Restricciones propias para la construcción del producto
• La duración del Sprint es definida por todo el Equipo Scrum con las recomendaciones del Scrum Master, quienes a su vez deberán llegar a un consenso con el Product Owner.

¿Se puede cancelar un Sprint? Un Sprint puede cancelarse antes que el periodo de tiempo llegue a su fin. Algunas de las razones por las que se podría cancelar un Sprint son:

• La organización cambia el Objetivo del Producto (Product Goal) y eso afecta el entregable del Sprint que se está ejecutando.
• Las condiciones del mercado o de la tecnología cambian.
• El objetivo del Sprint quedó obsoleto.
• Surge un error sobre un producto que está en ambiente de producción y los Developers deben resolverlo cuanto antes.
• Surge un cambio urgente que debe introducirse de inmediato al incremento de producto.

Consideraciones sobre la cancelación del Sprint

• Solo el Product Owner tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, de los Developers o del Scrum Master.
• Debido a la corta duración de los Sprints, su cancelación rara vez tiene sentido.
• Cuando se cancela un Sprint se revisan los elementos que se hayan completado y “Terminado”. Si una parte del trabajo es potencialmente entregable, el Product Owner normalmente la acepta.
• Si el Sprint ha sido cancelado, todos los elementos del Sprint Backlog que no hayan sido completados se vuelven a estimar para el siguiente Sprint o se vuelven a introducir en el Product Backlog para desarrollarse en futuros Sprints.
• Aunque se cancele un Sprint de igual manera consume recursos ya que el equipo debe reagruparse de nuevo para otra Planificación de Sprint para empezar otro Sprint.
• Las cancelaciones del Sprint son a menudo traumáticas para el Equipo Scrum y son muy poco comunes.

---

2. Planificación del Sprint (Sprint Planning)

¿De qué se trata la Planificación del Sprint?

La Planificación del Sprint es una sesión de trabajo en la que el equipo Scrum determina qué elementos del Product Backlog se trabajarán durante el próximo Sprint y cómo se abordarán, es decir un plan de trabajo, y este plan se crea mediante el trabajo colaborativo de todo el equipo Scrum.

En esta sesión se establece el alcance y el objetivo para las próximas semanas (Sprint Goal).

• El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito.
• El Scrum Master enseña al Equipo Scrum a mantenerse dentro del tiempo máximo del evento.
• El Product Owner es el encargado de dirigir la sesión de planificación, ya que él tiene la información que se usará como insumo para seleccionar el trabajo.

¿Cuál es la duración de la Planificación del Sprint?

Máximo 8 horas para un Sprint de un mes. Para Sprints más cortos, la duración se reduce proporcionalmente (por ejemplo, 4 horas para un Sprint de dos semanas).

¿Quiénes participan de la Planificación del Sprint y cómo se involucran?

• Scrum Master: Facilita la sesión y asegura que todos entiendan el propósito y la agenda de la sesión. Resuelve impedimentos que puedan surgir durante la planificación.
• Product Owner: Explica claramente los ítems del Product Backlog y ayuda al equipo a priorizar el trabajo basándose en el valor y las necesidades del negocio. Propone el objetivo del Sprint.
• Developers: Determinan el trabajo que pueden realizar durante el Sprint y descomponen los ítems en tareas con sus respectivas estimaciones.

¿Qué se necesita para la Planificación del Sprint?

• El Product Backlog actualizado.
• El último incremento del producto.
• Rendimiento pasado del equipo (por ejemplo, velocidad).
• "Borrador" de los elementos opcionados para trabajar en este Sprint (identificados previamente por el Product Owner).

Agenda de la Planificación del Sprint

1. ¿Por qué este Sprint es valioso?

• El Product Owner propone cómo el producto podría aumentar su valor y utilidad en el Sprint.
• Todo el equipo de Scrum colabora para definir el Objetivo de Sprint (Sprint Goal) durante la Planificación.

2. ¿Qué puede hacerse en este Sprint?

• Se identifican los cambios y/o riesgos que puedan afectar este Sprint.
• En equipo se seleccionan los elementos del Product Backlog que harán parte de este Sprint, es decir, definen el Sprint Backlog.
• Se identifican las dependencias que puedan existir.
• Los elementos seleccionados se descomponen en tareas detalladas y se realiza su estimación.
• Los Developers (y algunos casos también el Scrum Master si ejecuta trabajo del Sprint) se autoasignan los elementos del Sprint Backlog.

3. ¿Cómo se conseguirá completar el trabajo seleccionado?

• Se explica el detalle de las tareas y esfuerzos necesarios que deben ejecutarse para "terminar" los elementos del Sprint Backlog.
• Se asegura que todo el Equipo entiende cómo crear un incremento cumpliendo con la Definición de Terminado (Definition Of Done).

¿Qué resulta de la Planificación del Sprint?

• El objetivo del Sprint (Sprint Goal) definido.
• Lista de ítems del Product Backlog seleccionados para el Sprint (Sprint Backlog).
• El plan sobre cómo el equipo abordará las tareas (como parte del Sprint Backlog).

Consideraciones adicionales sobre la Planificación del Sprint

• La reunión debe ser colaborativa; todas las decisiones se toman en conjunto.
• Es vital no sobrecargar al equipo durante el Sprint. Es preferible subestimar que sobreestimar.
• La claridad en el objetivo del Sprint ayuda a mantener al equipo alineado y enfocado.
• El equipo debe estar preparado para adaptarse a los cambios, manteniendo la visión y el objetivo del Sprint.

---

3. Daily Scrum (Scrum Diario)

¿De qué se tratan los daily?

El Scrum Diario es una corta sesión diaria (15 minutos) que tiene como objetivo inspeccionar el progreso de los Developers hacia el Objetivo del Sprint (Sprint Goal) e identificando posibles impedimentos para la ejecución.

El Scrum Diario se realiza para cada día del sprint.

Nota: Si el Product Owner o el Scrum Master están desarrollando elementos del Sprint Backlog, entonces pueden participar como Developers.

¿Cuál es la duración de los daily?

Máximo 15 minutos.

¿Quiénes participan de los daily y cómo se involucran?

• Scrum Master: Asegura que la reunión ocurra diariamente, facilita la solución de impedimentos externos y mantiene la estructura y duración de la reunión.
• Product Owner: Puede asistir para escuchar, pero no interfiere en la dinámica de la reunión. Si tiene comentarios o inquietudes, los discute fuera del Daily Scrum.
• Developers: Activamente participan compartiendo su progreso, plan para el día y señalando impedimentos.

Nota: El Scrum Master y Product Owner pueden asistir, pero la reunión es principalmente para los Developers.

¿Qué se necesita para los daily?

• Sprint Backlog.
• Progreso del día anterior (tareas completadas, en progreso, en pruebas, pendientes).
• Posibles impedimentos identificados.

Posible agenda de los daily

Nota: El Scrum Master y los Developers tienen la libertad de seleccionar la estructura y técnicas que deseen para la ejecución de esta reunión; sin embargo, el Scrum Master tiene la opción de hacer las siguientes preguntas a los Developers:

• ¿Qué hice hoy?
• ¿Qué haré mañana?
• ¿Existe algún impedimento que esté afectando o nos pueda afectar?

¿Qué resulta de los daily?

• Entendimiento compartido del progreso hacia el Objetivo del Sprint.
• Identificación y registro de impedimentos.
• Ajustes en el plan diario de trabajo, si es necesario.

Consideraciones adicionales sobre los daily

• El Scrum diario se realiza a la misma hora y lugar todos los días para reducir la complejidad. Por lo general se realiza antes de finalizar la jornada de trabajo del Equipo.
• Durante el Scrum Diario el Equipo coordina y planea el trabajo para las siguientes 24 horas.
• Si surgen temas que requieran discusiones más amplias, se deben tratar fuera del Scrum diario para no desviar el propósito principal.
• El Scrum Master se asegura de que la reunión se ejecute diariamente, pero son los Developers los responsables de dirigir el Scrum Diario, es decir que, no es obligatoria la presencia del Scrum Master para que se lleve a cabo el Scrum Diario.
• El Scrum Master enseña al Equipo a mantener el Scrum Diario dentro de un bloque de tiempo de máximo 15 minutos.
• El Scrum Diario es una reunión interna del Equipo. Si otras personas están presentes, el Scrum Master se asegura de que no interrumpan la reunión ni alteren la planificación del trabajo.
• Los Scrum Diarios mejoran la comunicación, identifican los impedimentos relacionados con desarrollo del trabajo, resaltan y promueven la toma rápida de decisiones y mejoran el nivel de conocimiento del Equipo.
• Durante los Scrum Diarios se actualizan el Burndown chart y el Scrum Board.
• Esta reunión por lo general se realiza de pie con el fin de garantizar el cumplimiento del tiempo asignado, por lo que también se le puede conocer como el Scrum Diario de Pie (Daily Standup Meeting).

---

4. Revisión del Sprint (Sprint Review)

¿De qué se trata la Revisión del Sprint?

Al final del Sprint se lleva a cabo la Revisión de Sprint en la que se inspecciona el Incremento que se produjo durante el Sprint y adaptar el Product Backlog si fuese necesario.

El Equipo Scrum realiza una demostración del incremento y se revisa el progreso con respecto al Objetivo de Producto; basándose en esto y en cualquier cambio que deba considerarse, los asistentes colaboran para determinar los elementos que podrían desarrollarse en el siguiente Sprint para optimizar el valor.

Se trata de una sesión de trabajo, no de una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación para el equipo Scrum y fomentar la colaboración.

El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo fijado.

¿Cuál es la duración de la Revisión del Sprint?

Normalmente, dura máximo 4 horas para un Sprint de 4 semanas (la duración suele ser proporcional al largo del Sprint, por lo que para Sprints de 2 semanas, suele ser de 2 horas).

¿Quiénes participan de la Revisión del Sprint?

• Scrum Master: Facilita la sesión y garantiza que se siga la agenda.
• Product Owner: Presenta los ítems del Product Backlog completados, resalta el valor del trabajo realizado y lidera la discusión sobre las prioridades.
• Developers: Demuestran el trabajo realizado y responden preguntas técnicas.
• Stakeholders: Brindan retroalimentación y aclaran dudas o expectativas.

¿Qué se necesita para la Revisión del Sprint?

• Incremento de producto terminado del Sprint.
• Product Backlog.
• Estimaciones del trabajo (en el Sprint Backlog).

Agenda de la Revisión del Sprint

• El Equipo habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas.
• El Equipo hace una demostración del trabajo que ha "Terminado" y responde preguntas acerca del Incremento y su funcionalidad.
• El Product Owner habla acerca del Product Backlog en su estado actual. Proyecta objetivos probables y posibles fechas de entrega basándose en el progreso obtenido hasta la fecha (si fuera necesario).
• El Product Owner realiza la aprobación de los elementos del Sprint Backlog que se han "Terminado" y rechaza los que no se han "Terminado" y con esto determinar la Deuda Técnica.
• Seguimiento y control del presupuesto, capacidades potenciales y mercado para la próxima entrega prevista del producto.
• Revisión del estado de los cambios que fueron planificados para este Sprint y revisión del estado de los riesgos que afectaron este Sprint.
• Refinamiento (grooming) del Product Backlog, en el que todo el Equipo colabora acerca de qué hacer a continuación, de modo que esta reunión proporcione información de entrada valiosa para Reuniones de Planificación de Sprints subsiguientes.

¿Qué resulta de la Revisión del Sprint?

• El resultado de la Revisión de Sprint es un Sprint Backlog revisado, además de una identificación de alto nivel de los posibles elementos del Product Backlog que se pueden desarrollar para el siguiente Sprint.
• Retroalimentación sobre el Incremento de producto.
• Actualización del Product Backlog con posibles nuevos ítems o cambios.
• Claridad sobre la dirección y prioridades del producto.

Consideraciones adicionales la Revisión del Sprint

• Aunque se busca retroalimentación, la Revisión del Sprint no es únicamente una sesión de aprobación; se verifica que el trabajo esté "terminado" según la Definición de Terminado (DoD).
• Es esencial tener un ambiente abierto donde las partes interesadas sientan la libertad de dar retroalimentación honesta y constructiva sobre el producto.

---

5. Retrospectiva del Sprint (Sprint Retrospective)

¿De qué se trata una retrospectiva?

La Retrospectiva del Sprint es una sesión donde el equipo Scrum reflexiona sobre el Sprint que acaba de terminar para identificar oportunidades de mejora y planificar acciones concretas para próximos Sprints.

¿Cuál es la duración de una retrospectiva?

Suele durar alrededor de 3 horas para un Sprint de 4 semanas (puede ser proporcionalmente menos para Sprints más cortos, por ejemplo, alrededor de 45 minutos a 1.5 horas para Sprints de 2 semanas).

¿Quiénes participan y cómo se involucran?

• Scrum Master: Facilita la discusión, asegura un ambiente seguro para que todos expresen sus opiniones y ayuda al equipo a identificar áreas de mejora.
• Product Owner: Aporta desde su perspectiva sobre el desarrollo del producto, prioridades y feedback del cliente.
• Developers: Comparten feedback, discuten desafíos y proponen soluciones.

¿Qué se necesita para el evento?

• Feedback y observaciones del equipo sobre el Sprint que terminó.
• Datos y métricas relevantes del Sprint (como el Burndown Chart).
• Acciones de mejora de Retrospectivas anteriores.

Agenda de una retrospectiva

• Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas.
• Reflexionar sobre lo que salió bien y lo que no durante el Sprint.
• Discutir las causas de los desafíos y problemas.
• Identificar oportunidades de mejora y priorizarlas.
• Crear un plan o establecer acciones concretas para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.

¿Qué resulta de una retrospectiva?

• Acciones concretas para implementar mejoras en el próximo Sprint.
• Comprensión compartida de cómo mejorar el proceso de trabajo.

Consideraciones adicionales de una retrospectiva

• La Retrospectiva es un espacio seguro donde todos los miembros del equipo deben sentirse cómodos compartiendo su feedback sin temor a represalias.
• Las acciones de mejora deben ser específicas, medibles y asignadas para garantizar su implementación.
• Es esencial revisar las acciones de mejora de retrospectivas anteriores para evaluar su impacto y asegurar la mejora continua.

2.4 - Teoría de Scrum

• Scrum se basa en el empirismo (experiencia) y el pensamiento lean (reducir desperdicios).
• Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo.
• Scrum combina cuatro eventos formales para inspección y adaptación dentro de un contenedor: el Sprint.
• Los eventos funcionan porque se basan en los pilares empíricos de Scrum de transparencia, inspección y adaptación.

Transparencia

El proceso y el trabajo deben ser visibles para aquellos que realizan el trabajo (equipo Scrum), así como para los que reciben el trabajo (cliente y partes interesadas). Con Scrum, las decisiones importantes se basan en el estado percibido de los artefactos. Los artefactos que tienen poca transparencia pueden conducir a decisiones que disminuyen el valor y aumentan el riesgo. La transparencia permite la inspección.

Inspección

Los artefactos de Scrum y el progreso hacia los objetivos deben ser inspeccionados con frecuencia y diligentemente para detectar varianzas o problemas potencialmente indeseables. Para ayudar con la inspección, Scrum proporciona cadencia en forma de sus cinco eventos.

En los proyectos Scrum se deben inspeccionar frecuentemente los artefactos y el progreso hacia un objetivo, para detectar variaciones.

La inspección no debe ser tan frecuente como para que interfiera en el trabajo, las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos en el mismo lugar de trabajo (normalmente el Scrum Master).

Adaptación

Si algún aspecto de un proceso se desvía fuera de los límites aceptables o si el producto resultante es inaceptable, el proceso que se está aplicando o los resultados que se producen deben ajustarse. El ajuste debe realizarse lo antes posible para minimizar la desviación adicional.

Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.

Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la inspección y adaptación, tal y como se describen en la sección Eventos de Scrum de esta guía:

• Reunión de Planificación del Sprint.
• Scrum Diario.
• Revisión del Sprint.
• Retrospectiva del Sprint.

La teoría de Scrum ha sido tomada de: https://scrumguides.org/