3.6 - Emisores de información útiles para el Scrum Master

El término "emisor de información" no hace parte de los conceptos core de Scrum. Sin embargo, en el contexto de la comunicación y la gestión ágil de producto, los emisores de información son herramientas diseñadas para mostrar el estado actual de los Sprints o del producto en su totalidad.

Estos instrumentos ofrecen una visualización clara y concisa de tareas, progresos y obstáculos, facilitando la transparencia y permitiendo un seguimiento y control efectivos. Sirven como medios esenciales para que todos los involucrados, desde el equipo Scrum hasta los stakeholders, tengan una comprensión clara del avance y estado del trabajo.

El Scrum Board

El Scrum Board o también conocido como tablero Scrum es una adaptación del tablero Kanban que nos permite dar seguimiento a cada Sprint Backlog dentro del equipo Scrum.

El Scrum Board es un emisor de información que le permite al Equipo garantizar la transparencia en los Sprints, mantiene la coordinación y permite realizar al Scrum Master sus labores de Inspección.

Comúnmente está compuesto por 4 columnas: Pendiente (to do), En Progreso (in progress), En Prueba (testing), Terminado (done).

Cada elemento por desarrollar debe ponerse en una tarjeta individual, y dado que el Scrum Board se actualiza constantemente, todas las tarjetas deberán pasar por las 4 columnas. (No se pueden hacer saltos de columnas).

Aclaraciones sobre el Scrum Board

• Cuando el tablero está físico en el lugar de trabajo del equipo, generalmente las tarjetas que se manejan son “sticky notes” de distintos colores.
• Cuando se van a desarrollar múltiples historias de usuario en un solo Sprint conviene dividir el tablero en filas, donde cada fila representa un componente o épica del producto.
• Al final de un Sprint se “borra” o reinicia el Scrum Board (para así poderlo usar para el próximo Sprint)
• Para considerar un elemento como “terminado” y moverlo a esta zona en el Scrum Board, se debe considerar la “Definición de terminado (DoD)”.
• Para facilitar la lectura del Scrum Board, a cada miembro del equipo puede asignársele un color de tarjetas (a manera de convenciones).
• Aunque por lo general el Scrum Board se actualiza durante la reunión diaria, cada Developer tiene autonomía para actualizar su conjunto de elementos asignados en el Sprint Backlog.

Burndown chart del Sprint

El “Burndown Chart” es un emisor de información que muestra la cantidad de trabajo pendiente en el Sprint actual en función del tiempo.

Es un emisor gráfico de 2 dimensiones:

• El eje vertical muestra el trabajo restante, que se determina con la sumatoria de puntos de historia a desarrollar en el Sprint
• El eje horizontal muestra el tiempo, es decir la duración del Sprint en días hábiles.

Al inicio del Sprint, la cantidad de trabajo restante es la más alta y, a medida que se avanza el Sprint, esta cantidad debería disminuir, "quemándose" (burn) el trabajo hasta llegar a cero al final del Sprint.

El Burndown Chart es una herramienta esencial para los equipos Scrum ya que les permite visualizar diariamente su progreso, identificar posibles problemas y ajustar su ritmo de trabajo si es necesario para cumplir con el Objetivo del Sprint (Sprint Goal).

Aclaraciones sobre el Burndown Chart

• Una posible variación de esta herramienta es el "Burnup chart" que muestra gráficamente la cantidad de trabajo completado a lo largo del tiempo, en lugar de lo que queda por hacer (a medida que avanza el tiempo, la línea del gráfico asciende, mostrando cuánto trabajo se ha "acumulado" o completado).
• Los Developers son los responsables de la actualización del Burndown Chart. El Scrum Master puede facilitar y asegurarse de que el Burndown Chart se mantenga actualizado, pero no es su responsabilidad directa hacerlo.
• Por lo general la actualización se realiza durante los Scrum Diarios.

Diagrama de flujo acumulado

El Diagrama de Flujo Acumulado (CFD - Cumulative Flow Diagram) es un emisor de información bastante útil para la elaboración de informes y el seguimiento de los resultados del proyecto; y se originó a partir de la metodología Kanban.

Este emisor de información muestra el progreso del producto respecto a los ítems del Product Backlog, y se construye un único diagrama de flujo acumulado por producto.

Este gráfico se compone de dos ejes; el eje vertical "Y" muestra la cantidad de ítems (como tareas, características, user Historias de Usuario). El eje horizontal "X" muestra el tiempo, usualmente días, semanas o meses.

Cada área coloreada en el gráfico representa un estado o categoría diferente del flujo de trabajo:

• La zona "gris" muestra el comportamiento del Product Backlog; y el aumento de esta zona significa la adición de nuevos requerimientos/tareas/historias de usuario. La disminución de esta zona significa que se retiran requerimientos/tareas/historias de usuario que ya no generan valor (como resultado de los cambios al producto).
• La zona "azul" muestra el trabajo que fue seleccionado por el equipo para desarrollar en los distintos Sprints, es decir el trabajo que se seleccionó como Sprint Backlogs.
• La zona "verde" muestra cuántos ítems han sido completados en el tiempo. Idealmente, deberías ver un crecimiento estable en esta zona si el trabajo se está completando a un ritmo constante. Cuando la zona azul está por encima de la zona verde, normalmente significa que el equipo seleccionó más trabajo del que podía terminar, esto se conoce como "deuda técnica".
• La diferencia entre la zona "verde" y la zona "gris", está relacionada con el progreso del producto.
• Los puntos marcados en el gráfico muestran los distintos Sprints.

Aclaraciones sobre el Diagrama de Flujo Acumulado:

• Si una zona del gráfico se ensancha mientras las demás no, es una señal de que los ítems se están acumulando en ese estado y puede indicar que hay un cuello de botella.
• Si las zonas fluyen de manera paralela y sin muchas variaciones en su ancho, indica que el proceso es estable. Si se expanden y contraen drásticamente, puede indicar que hay inconsistencias en el flujo de trabajo.
• El responsable de este emisor de información es el Scrum Master, aunque normalmente es el Product Owner quien lo utiliza para mostrar el progreso a las partes interesadas.

Registro de obstáculos/impedimentos

El registro de obstáculos, o también llamado registro de impedimentos es una herramienta que se utiliza para llevar un registro y seguimiento de los obstáculos o bloqueos que impiden o ralentizan el progreso del equipo Scrum. Estos impedimentos pueden ser cualquier cosa que obstruya el flujo de trabajo del equipo, desde problemas técnicos hasta cuestiones organizativas.

Un impedimento es cualquier factor que impide que el equipo alcance su productividad potencial. Puede ser algo interno, como un desafío técnico o falta de habilidades específicas, o externo, como la espera de una aprobación de otro equipo o departamento.

Mantener un registro de impedimentos ayuda a asegurar que los problemas no se pasen por alto y que se les dé la debida prioridad. También proporciona una visión histórica que puede ser útil para futuras retrospectivas y para identificar patrones o problemas recurrentes.

Aclaraciones sobre el registro de impedimentos

• El Scrum Master es el rol encargado de abordar y eliminar los impedimentos que estén afectando al equipo. Sin embargo, es responsabilidad de todo el equipo identificarlos y comunicarlos.
• Durante el Scrum Diario (o Daily), los miembros del equipo informan sobre cualquier nuevo impedimento que haya surgido. El Scrum Master toma nota de estos y los añade al registro de impedimentos.
• Cada entrada en el registro de impedimentos debe tener una descripción clara del problema, la fecha en que fue identificado, su impacto potencial en el equipo o en el producto y cualquier otro detalle relevante.
• También es útil incluir el estado del impedimento (por ejemplo: identificado, en progreso, resuelto) y las acciones tomadas o necesarias para resolverlo.
• En algunas organizaciones este registro es global para todos los proyectos o equipos y sirve como base de conocimiento para todos los integrantes de los distintos equipos Scrum.

Registro de lecciones aprendidas

Registrar las lecciones aprendidas es una parte fundamental para la mejora continua de las prácticas Scrum dentro de una organización. En esta herramienta se registran las prácticas, experiencias, conocimientos y recomendaciones que favorecieron el desempeño del equipo en términos de costo, tiempo y calidad, también se registran aquellos errores que se cometieron y a los que se les dió solución. Estas soluciones hacen parte de las lecciones aprendidas, útiles para resolver problemas similares en el futuro.

Las lecciones aprendidas, además, favorecen el aprendizaje organizacional y la gestión del conocimiento. Así que las lecciones aprendidas deben almacenarse, alimentarse y transferirse de manera apropiada. Para esto, es importante que cada lección tenga una estructura para facilitar su búsqueda, como por ejemplo:

• Una identificación (ID)
• Descripción: Breve resumen de la situación o problema.
• Situación/Contexto: En qué fase o circunstancia del proyecto se encontró la lección.
• Lección Aprendida: Detalle de lo que se aprendió, ya sea un error que se debe evitar o una buena práctica que se debe repetir.
• Recomendaciones: Pasos o acciones sugeridos para futuros proyectos a partir de la lección aprendida.
• Responsables: Quiénes estuvieron involucrados o quiénes deberían ser informados sobre esta lección.
• Fecha: Cuándo se identificó la lección.
• Categoría: Por ejemplo, la fase del ciclo de vida del proyecto

Aclaraciones sobre el registro de lecciones aprendidas:

• Este artefacto normalmente es una de las responsabilidades del Scrum Master.
• Los equipos suelen tener reuniones específicas para discutir y documentar lecciones aprendidas; que pueden darse durante las sesiones de retrospectiva o en revisiones post-proyecto (cuando se manejan enfoques más tradicionales).
• Es crucial que estas sesiones se lleven a cabo en un ambiente abierto y sin culpas, para fomentar la sinceridad y el aprendizaje genuino.
• Al iniciar un nuevo proyecto o la construcción de un producto, el equipo debe revisar registros anteriores para identificar posibles riesgos, desafíos o mejores prácticas relevantes.
• La organización o el equipo debe tener un sistema para almacenar y acceder a estas lecciones, ya sea una base de datos, un repositorio centralizado o incluso herramientas digitales especializadas.

Portafolio de proyectos

El portafolio de proyectos consiste en un registro de información histórica, esta información podría ser útil (por ejemplo) cuando la organización empieza un proyecto similar a uno que haya ejecutado en el pasado y por tanto algunos elementos sean similares, esto reduce el tiempo de planificación, desarrollo, revisión, implementación y/o cierre, además de hacer uso de las lecciones aprendidas y brindar los insumos para la gestión del conocimiento.

Al igual que las lecciones aprendidas, el portafolio de proyectos debería tener información detallada y organizada que permita su alimentación, almacenamiento y transferencia. Un software específico para la gestión del portafolio de proyectos es útil, por lo que una organización debería considerar esta posibilidad.

Algunos de los elementos que podrían incluirse en el portafolio de proyectos son:

• Una identificación (ID)
• Nombre del Proyecto
• Categoría (Ej: Software – Implementación – Construcción – Investigación, Etc)
• Descripción corta del proyecto (buscando resumir la visión del mismo)
• Tiempo total de proyecto
• Costo total del proyecto
• Enlace a repositorio o herramienta de información (donde se podrá encontrar más información del proyecto)