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.

4.1 - Product Backlog

El Product Backlog es una lista ordenada de todo 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 y correcciones que constituyen 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 requisitos nunca dejan de cambiar 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 proyecto a la hora de refinar el Product Backlog.

4.2 - Sprint Backlog

El Sprint Backlog es el conjunto de los elementos del Product Backlog seleccionados para un Sprint, más 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.

4.2.1 - Incremento

Un Incremento es la suma de todos los elementos del Product Backlog completados durante un Sprint y el 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 la Definición de “Terminado” del Equipo Scrum.

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

4.3 - Emisores de Información

Los emisores de información son artefactos que permiten visualizar gráficamente el estado de los Sprints o del proyecto en general. Sirven para garantizar la transparencia y para realizar seguimiento y control del proyecto.

4.3.1 - 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 de un proyecto 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.

Está compuesto por 4 columnas: Pendiente, En Progreso, En Prueba (En Revisión), “Terminado”.

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).

dibujo

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” el Scrum Board (para así poderlo usar para el próximo Sprint)
• Para considerar “terminado” un elemento y moverlo a esta zona en el Scrum Board, se debe considerar la “definición de terminado (DoD)” (Sección 7.1.1.3).
• 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 integrante del Equipo de Desarrollo tiene autonomía para actualizar su conjunto de elementos asignados en el Sprint Backlog.

4.3.2 - Burndown chart del Sprint

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

Es un emisor gráfico de 2 dimensiones:

• El eje vertical se construye a partir de la sumatoria de puntos de historia a desarrollar en el Sprint
• El eje horizontal corresponde a la duración del Sprint en días hábiles.

dibujo

Aclaraciones sobre el Burndown Chart

• Una posible variación es el Burnup chart que muestra el trabajo completado en el Sprint
• El Equipo de Desarrollo es el responsable de la actualización del Burndown Chart
• Por lo general la actualización se realiza durante los Scrum Diarios.

4.3.3 – 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.

Este emisor de información muestra el progreso del proyecto respecto a los ítems del Product Backlog.

dibujo

• La zona “gris” muestra el comportamiento del Product Backlog.
  • Los incrementos significan la adición de nuevos requerimientos/tareas/historias de usuario.
  • Los decrementos significan el retiro de requerimientos/tareas/historias de usuario que ya no generan valor (producto de cambios).
• La zona “azul” muestra el trabajo que fue seleccionado por el equipo para desarrollar en los distintos Sprints.
• La zona “verde” muestra el trabajo terminado en el proyecto alrededor del tiempo.
  • 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 proyecto.
• Los puntos marcados en el gráfico muestran los distintos Sprints.
• El eje vertical podría ser el “tamaño de los requerimientos”, esto permitiría tener mayor precisión a la hora de calcular el progreso del proyecto.
• El diagrama de flujo acumulado es único por proyecto.
• La técnica originalmente es de la metodología Kanban.
• El responsable de este radiador de información es el Scrum Master, aunque normalmente es el Product Owner quien lo utiliza para mostrar el progreso del proyecto a las partes interesadas.

4.4 – Registro de obstáculos/impedimentos

El registro de obstáculos, o también llamado registro de impedimentos es un artefacto en el que se registran todos los obstáculos que se presentan en los proyectos y su respectiva solución.

Este artefacto es responsabilidad de los Scrum Masters y se actualiza por lo general durante los Scrum Diarios.

En algunas organizaciones este artefacto es global para todos los proyectos y sirve como base de conocimiento para todos los integrantes de los distintos equipos Scrum.

4.5 – 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 este artefacto se registran las prácticas 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 estructuración que permita su búsqueda, una manera de hacerlo sería definiendo:

• Una identificación (ID)
• Título
• Categoría (Ej: Fase del ciclo de vida del proyecto)
• Descripción
• Proyecto asociado.

Este artefacto normalmente es una de las responsabilidades del Scrum Master.

4.6 – 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)