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

---

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.

Product Goal (Objetivo del Producto)

Es el compromiso del Product Backlog

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

---

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

Sprint Goal (Objetivo del Sprint)

Es el compromiso del Sprint Backlog

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.

---

4.2.1

Incremento -de Incremento

Producto

Un Incremento es lael resultado que entregan los Desarrolladores al final de cada Sprint, el cual se suma de todos los elementos del Product Backlog completados durante un Sprint y elal 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 o meta del proyecto.producto (Product Goal).
• El incremento debe estar en condiciones de utilizarse sin importar si el Product Owner,Owner decide liberarlo o no.

4.3

Definición de Terminado (DoD - EmisoresDefinition deOf Información

Done)

Los emisores de información son artefactos que permiten visualizar gráficamenteEs el estado de los Sprints ocompromiso 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).

dibujoIncremento

AclaracionesEs sobreuna descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el Scrum Boardproducto.

• CuandoLa 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óDefinición de terminado (DoD)”Criterios (Secciónde 7.1.1.3).terminado) es definida en conjunto por el Equipo Scrum.
• ParaLa facilitarDoD puede ser definida para cada incremento o para el producto en general.
• Si un incremento no cumple con la lecturaDefinición delde ScrumTerminado, Board,no apuede cadaser miembroaprobado.

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

• Los elementos fueron revisados por otros miembros del equipo puede(se asignárselerealizaron unlas colorpruebas de tarjetascolegas). (a
manera
• No existen defectos o los defectos están arreglados.
• Se completaron las pruebas unitarias.
• Se finalizó toda la documentación técnica y de convenciones).usuario final.
• Aunque porTodos lolos generalarchivos ely Scrum Board se actualiza durante la reunión diaria, cada integrantedocumentos del Equipoproyecto de Desarrollo tiene autonomía para actualizar su conjunto de elementos asignadosestán 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 partirrepositorio de la sumatoriaorganización. 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)