Artefactos en Scrum

Antes de 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.

Artefactos

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

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.

Tema complementario: Los emisores de información

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.

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

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.

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.

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.

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)