Una herramienta es un instrumento que permite desarrollar determinadas actividades, y estas se utilizan en el día a día en un negocio para hacer las funciones del puesto. Al igual que en una organización, en Scrum existen herramientas conocidas como artefactos, las cuales ayudan a desarrollar las actividades de los diferentes roles que forman parte del equipo y están diseñadas para generar valor y poder facilitar la ejecución de un sprint en Scrum de forma ordenada y sistemática, pero sobre todo que pueden ser adaptadas para ir aprendiendo de forma empírica durante el desarrollo, de tal forma que facilitan al equipo su ejecución.

En esta experiencia de aprendizaje, revisarás los artefactos de Scrum, los cuales consisten en las user stories, el product backlog, el sprint backlog, y las burndown charts.

User stories

Las user stories (o historias de usuario, aunque habitualmente se maneja en inglés) en Scrum son los artefactos que sirven para representar la unidad más pequeña de trabajo como parte del marco de referencia, proporcionando una descripción natural e informal de la característica del producto a desarrollar desde la perspectiva de usuario (Arun, 2022; Obergfell, s.f.-b).

En la figura 1 se presentan los beneficios de las user stories de acuerdo con Arun (2022) y Cohn (2022b) y posteriormente en qué consiste cada uno:

Figura 1. Beneficios de las user stories.

• Entregan alto valor: ayudan al scrum team a enfocarse en las necesidades más pequeñas e inmediatas del cliente, lo cual ayuda dramáticamente a proporcionar retornos más rápidos, reducir la inversión significantemente y a incrementar el retorno de la inversión (ROI).
• Posibilitan la colaboración: el scrum team trabaja para proveer soluciones creativas e innovadoras para las necesidades del cliente.
• Acercan a los usuarios:  El scrum team puede conectar directamente con los usuarios, entender sus perspectivas, oportunidades requeridas y otras cuestiones.
• Generan bloques de construcción del proyecto: facilitan la adición o eliminación de características del producto.
• Incrementan la transparencia: son visibles para todos, ya que las notas adhesivas o tarjetas donde son escritas son visibles para todos, permitiendo un entendimiento, colaboración y rápida toma de decisiones.

Una user story utiliza un lenguaje informal y corto (estructura de oración simple), expresa lo que se quiere hacer, utilizándose para poder establecer una conversación con el usuario sobre lo que quiere agregar o cambiar del producto a desarrollar, ya que el objetivo principal es satisfacer sus necesidades a través del valor (Digité, s.f.), lo cual se expresa a través de una plantilla que incluye habitualmente tres elementos (Cohn, 2022b):

Como <usuario>, quiero <meta, necesidad> para <razón>

• <Usuario>: es el usuario o la persona que solicita el requerimiento. Por ejemplo, especialista en finanzas, director de finanzas, etc.
• <Meta, necesidad>: es el deseo del usuario, lo que considera que necesita. Por ejemplo, una app que permita monitorear las operaciones de la empresa.
• <Razón>: por qué se necesita, justificación o razón de ser de la necesidad. Por ejemplo, para reducir los gastos innecesarios.

Figura 2. Modelo INVEST de las user stories.

Fuente: Arun, R. (2022). An Introduction to the World of User Stories [Archivo de video]. Recuperado de https://www.simplilearn.com/tutorials/agile-scrum-tutorial/user-stories

Para ayudar a evaluar una user story, se utiliza el acrónimo INVEST (figura 2):

• Independiente (independent): la user story debe poder autocontenerse, es decir, se debe asegurar su liberación sin recaer en otra.
• Negociable (negotiable): no debe ser escrita como un contrato, solo comprender el requerimiento esencial, abierto a la conversación.
• De valor (valuable): Valor entregado al usuario final.
• Estimable (estimable): debería poder estimarse para priorizarlas y poder ejecutarlas en los sprints.
• Pequeña (small): debe ser de tal forma que sea completada entre 3 y 4 días.
• Que se pueda probar (testable): debe poder confirmarse a través de un criterio prescrito.

Para que se pueda mantener el propósito de las user stories, se utilizan normalmente tarjetas adhesivas (Post-it), en las cuales se coloca la estructura de oración simple, para poder mantener una discusión entre los usuarios, el Scrum Team y otros interesados, y confirmar que efectivamente se han satisfecho sus requerimientos.

Product backlog

Un product backlog es una lista ordenada de todo lo que se requiere ser hecho para mejorar o crear un producto basado en las necesidades de los usuarios finales, siendo la única fuente de trabajo utilizada por el scrum team (Scrum.org, s.f.).

Los elementos del product backlog, mostrados en la figura 3 (Innolution, s.f.; Radigan, s.f.), que pueden ser desarrollados por el scrum team en un sprint, son considerados como listos para selección dentro de un evento llamado sprint planning, con lo que se da transparencia.

Figura 3. Product backlog.

El dueño del product backlog es el product owner, y cada elemento recibe el nombre de product backlog item (PBI), y representa una característica (user stories, casos de uso, prueba en forma libre), defecto, trabajo técnico, adquisición de conocimiento. Dichos PBI pueden refinarse, estimarse (agregar tamaño), repriorizarse o eliminarse, dependiendo de lo que haya obtenido como resultado de la conversación con el usuario al que se le entregará el valor.

El product backlog priorizado debe ir ordenado de mayor a menor prioridad, siendo los de mayor prioridad los que se encuentran al inicio (parte superior de la pila).

Sprint backlog

El sprint backlog (figura 4, elaborada con base en Cohn (s.f.-a) y ProductPlan (s.f.)) es una lista de tareas identificadas por el scrum team que se deben completar en un sprint, lo cual ocurre durante el sprint planning, que es cuando el equipo selecciona algún número de PBI, los cuales tienen la estructura de user story e identifican cada tarea para completarla, estimado cuánto tiempo (en horas) le tomará a alguien del equipo terminarla (Cohn, s.f.-a).

Figura 4. Sprint backlog.

Aunque el dueño del product backlog es el product owner, el scrum team – scrum master, product owner, scrum development team – es el dueño del sprint backlog, ya que todos poseen conocimiento y visión del proyecto, ejecutándolo en conjunto al inicio del proyecto.

Los elementos del sprint backlog son aquellos que se planean entregar como incremento del producto en el sprint actual, definido con el desarrollo de lo que el equipo necesita hacer para convertir los PBI en incrementos de lo que se denomina "done" (trabajo terminado), clarificando el trabajo a realizar en la meta del sprint.

El sprint backlog debe ser suficientemente específico para tener cambios de progreso entendible durante las daily scrum. El scrum development team modificará el sprint backlog a lo largo de la ejecución del sprint, y el sprint backlog irá gradualmente emergiendo en el proceso, conociendo el trabajo restante a realizar (Visual Paradigm, s.f.-b).

Burndown charts

El scrum burndown chart (o gráfico de quemado en español, pero habitualmente se nombra en inglés) es una herramienta visual que muestra el trabajo completado de manera diaria contra lo que se ha completado del proyecto en el sprint actual en ejecución, teniendo como propósito mantener la ejecución en tiempo para entregar el resultado del sprint en la fecha establecida (Obergfell, s.f.-a).

Figura 5. Burndown chart.

Fuente: Obergfell, Y. (s.f.-a). Scrum Burndown Chart - International Scrum Institute. Recuperado de https://www.scrum-institute.org/Burndown_Chart.php

Como se observa en la figura 5, la burndown chart muestra la cantidad de trabajo restante, calculado en story points (medida habitual utilizada para priorizar los PBI, o la medición utilizada, por ejemplo, horas) de tal forma que se pueda ir observando el esfuerzo adicional que debe hacer el equipo para poder cumplir con los requerimientos del cliente.

Para poder realizar una burndown chart se siguen los siguientes pasos (Visual Paradigm, s.f.-a):

1. Determinar el esfuerzo estimado: dividir la duración del sprint entre el número de días. Por ejemplo, si el sprint se estima en 50 story points y son 5 días, entonces se ejecutarán 10 story points por día, entonces se irá reduciendo la estimación de 10 en 10 hasta llegar a cero.
2. Monitorear el proceso diario: capturar el proceso en una tabla, en una columna separada de la estimación (las unidades deben ser las mismas que las de la estimación, en este ejemplo se usaron story points).
3. Calcular el esfuerzo restante: determinar cuánto se avanzó en el día y al final recalcular el trabajo restante. En este caso si se supone que el día 1 se avanzó solamente 6 story points, quiere decir que restan por hacer 44 story points.
4. Crear la burndown chart: graficar tanto el estimado como el actual usando gráficas de líneas.

A continuación, revisa la explicación sobre el producto mínimo viable (PMP).

El uso de los artefactos en Scrum es importante para permitir la visualización del avance por parte del equipo y cumplir con el principio de transparencia; sin embargo, se pueden utilizar otros, dependiendo de lo que el equipo haya acordado utilizar.

Se recomienda que cuando inicia la adopción del marco de referencia Scrum, se usen los artefactos propios (user stories, product backlog, sprint backlog, burndown chart) y con la estructura estándar, pero conforme el equipo vaya madurando, se vayan utilizando otros, de tal forma que se cuente con un conjunto de herramientas que permitan entregar el valor. Además, las herramientas, como se observó, son sencillas, aplican el principio de control empírico (a través de la observación de la evidencia y experimentación se va mejorando), priorizan basándose en el valor y tomando en cuenta lo que el usuario quiere, utilizando una unidad mínima y un vocabulario sencillo pero estandarizado.

Asegúrate de:

• Aprender que las user stories son la unidad mínima de trabajo que se utiliza en Scrum y representa las características/funcionalidades esperadas por el usuario.
• Comprender que el product backlog contiene todas las características/funcionalidades que obtendrá el producto o que se mejorarán (en caso de que contenga defectos, trabajo técnico, entre otros).
• Conectar el sprint backlog con user stories donde se priorizaron y seleccionaron los principales aspectos de valor para ejecutar en el sprint.
• Establecer el uso de las burndown chart para mostrar la cantidad de trabajo faltante para terminar el sprint.
• Comprender la importancia del uso de artefactos como herramientas usadas por el marco de referencia scrum para poder ir aplicando los principios ágiles y el empirismo.

Los siguientes enlaces son externos a la Universidad Tecmilenio, al acceder a ellos considera que debes apegarte a sus términos y condiciones.

Videos

Para conocer más acerca de Artefactos, te sugerimos revisar lo siguiente:

• Agile611. (2020, 30 de julio). ¿Qué son las historias de usuario? ¿Usas User Stories? [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=XIMtR5GFPOk
• Centripio. (2018, 3 de marzo). Que es el Product Backlog [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=BiTzUpv6ADs
• Javier Garzás. (2020, 3 de marzo). El Product Backlog vs el Sprint Backlog [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=pAMXbCNw0Zc

Lecturas

Para conocer más acerca de Artefactos, te sugerimos leer lo siguiente:

• Asana. (2022). Backlog: qué es el trabajo pendiente del sprint y ejemplos. Recuperado de https://asana.com/es/resources/sprint-backlog
• Rehkopf, M. (s.f.). Historias de usuario con ejemplos y plantilla. Recuperado de https://www.atlassian.com/es/agile/project-management/user-stories
• Roche, J. (s.f.). Diagramas Burndown: herramienta o arma de destrucción. Recuperado de https://www2.deloitte.com/es/es/pages/technology/articles/diagramas-burndown-herramienta-o-arma-de-destruccion.html

• Arun, R. (2022). An Introduction to the World of User Stories [Archivo de video]. Recuperado de https://www.simplilearn.com/tutorials/agile-scrum-tutorial/user-stories
• Cohn, M. (s.f.-b). User Stories. Recuperado de https://www.mountaingoatsoftware.com/agile/user-stories
• Cohn, M. (s.f.-a). Sprint Backlog. Recuperado de https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog
• Digité. (s.f.). User Stories: What They Are and Why and How to Use Them. Recuperado de https://www.digite.com/agile/user-stories/
• Innolution. (s.f.). Chapter 6: Product Backlog. Recuperado de https://innolution.com/essential-scrum/table-of-contents/chapter-6-product-backlog
• Obergfell, Y., (s.f.-b). Scrum User Stories - International Scrum Institute. Recuperado de https://www.scrum-institute.org/Scrum_User_Stories.php
• Obergfell, Y. (s.f.-a). Scrum Burndown Chart - International Scrum Institute. Recuperado de https://www.scrum-institute.org/Burndown_Chart.php
• ProductPlan. (s.f.). Sprint Backlog. Recuperado de https://www.productplan.com/glossary/sprint-backlog/
• Radigan, D. (s.f.). The product backlog: your ultimate to-do list. Recuperado de https://www.atlassian.com/agile/scrum/backlogs
• Scrum.org. (s.f.). What is a Product Backlog? Recuperado de https://www.scrum.org/resources/what-is-a-product-backlog
• Visual Paradigm. (s.f.-a). What is a Burndown Chart in Scrum? Recuperado de https://www.visual-paradigm.com/scrum/scrum-burndown-chart/#:~:text=A%20burn%20down%20chart%20is,containing%20measurable%20progress%20over%20time
• Visual Paradigm. (s.f.-b). What is Sprint Backlog in Scrum? Recuperado de https://www.visual-paradigm.com/scrum/what-is-sprint-backlog-in-scrum/