Artefactos Scrum

Publicaciones

Artefactos Scrum: las 3 herramientas clave de gestión

Elementos para la gestión de un proyecto de desarrollo de software

Incremento, Product Backlog y Sprint Backlog

En el marco de trabajo Scrum, denominamos Artefacto a aquellos elementos físicos que se producen como resultado de la aplicación de Scrum. Los tres principales artefactos o herramientas Scrum son: el Product Backlog, Sprint Backlog y el Incremento.

Product Backlog

El Product Backlog es un inventario que contiene cualquier tipo de trabajo que haya que hacer en el producto: requerimientos, casos de uso, tareas y dependencias. Es la principal fuente de información sobre el producto en Scrum, una lista, en cualquier formato, que contiene todos los requerimientos que necesitamos implementar en el producto. Esta lista es el resultado del trabajo del Product Owner con el cliente, los distintos stakeholders, sponsors, comités, etc, y refleja el estado real del trabajo pendiente de implementar en el producto, así como el ya realizado. 

El Product Backlog debe ser gestionado en exclusiva por el Product Owner, siendo su principal función la de priorizar aquellos elementos que tienen más valor en cada etapa y detallarlos para que el equipo de desarrollo sea capaz de valorarlos y ejecutarlos.

Al comenzar a utilizar Scrum, no es necesario una lista completa y exhaustiva de todos los requerimientos. Es recomendable empezar con los dos o tres requerimientos más urgentes arriba e ir añadiendo elementos conforme vamos descubriendo más necesidades de nuestro producto.

Un Product Backlog contiene distintos elementos:

  • Funcionalidades
  • Bugs
  • Historias de usuario: una forma de expresar elementos de un Product Backlog. Para obtener el máximo valor de una historia de usuarios es necesario expresarlas desde el punto de vista del usuario.
  • Tareas técnicas
  • Trabajo de investigación

Sprint Backlog

¿A qué denominamos Sprint Backlog? Se trata de una lista de elementos en los que trabajar durante la etapa de Sprint. Estos elementos normalmente se componen de tareas técnicas más pequeñas que permiten conseguir un incremento de software terminado.

Todo el trabajo que el Development Team haya seleccionado para hacer durante el siguiente Sprint pasa al Sprint Backlog. Este artefacto es un elemento para visualizar el trabajo a realizar durante cada Sprint y está gestionado por el equipo de desarrollo. Su propósito es mantener la transparencia dentro del desarrollo, actualizándolo durante toda la iteración especialmente a través de los daily Scrums.

El Sprint Backlog permite visualizar, durante cada Sprint, aquellos elementos que aún no han empezado a desarrollarse, aquellos que sí y quiénes están trabajando en los mismos, así como aquellos que están esperando a desplegarse o están completamente terminados.

Este artefacto permite entender cuál es la evolución del trabajo durante el Sprint, así como hacer un análisis de riesgos. Dado que cada Sprint tiene una meta específica (p.e. permitir que los usuarios se registren en la app móvil) y hay elementos seleccionados del Product Backlog que tienen más o menos valor, el Sprint Backlog permite analizar hasta donde se ha cumplido el objetivo y que se podría eliminar. De esta forma, maximizamos el retorno de la inversión en desarrollo.

Incremento

Si Scrum tuviera que ser reducido a una sola cosa, sería a entregar una pieza de software terminado en cada Sprint. Un Incremento es el resultado del Sprint, es la suma de todas las tareas, casos de uso, historias de usuario y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de software, aportando un valor de negocio al producto que se está desarrollando.

Construir software de manera ágil se basa en hacerlo de manera iterativa e incremental. Mediante las iteraciones, nos aseguramos que todo el ciclo de vida del software (planificación, diseño, desarrollo, testeo y entrega) ocurre en 4 semanas o menos. Por supuesto, no podemos construir toda la funcionalidad que queremos en solo cuatro semanas y tenemos que buscar la manera de ir entregando los componentes necesarios justo a tiempo.

Otros artefactos

El marco de trabajo Scrum destaca los 3 elementos expuestos previamente como imprescindibles. Sin embargo, hay otros que, a pesar de no formar parte del core, son necesario para asegurar la calidad de la metodología Scrum.

  • Definition of Done (DoD): La DoD es un documento que define qué se considera hecho en un equipo Scrum. La idea es establecer una serie de criterios comunes para especificar cuando un ítem está completamente terminado y que aplique a todos los ítems que forman parte del incremento.
  • Definition of Ready (DoR): El DoR es un documento que define cuándo un requerimiento (historia de usuario o similar) se considera listo para que el equipo de desarrollo pueda entenderlo, valorarlo e incluirlo en un Sprint Planning con idea de acometerlo en un Sprint.
  • Burndown Chart: El Burndown Chart es un gráfico de trabajo pendiente a lo largo del tiempo que muestra la velocidad a la que se están completando los objetivos, requisitos, o historias de usuarios. Permite extrapolar si el equipo podrá completar el trabajo en el tiempo estimado.

Puedes encontrar más información al respecto de este y otros temas relacionados con lo que comentamos en el artículo en el site de nuestro colaborador, Jerónimo Palacios. http://jeronimopalacios.com.

Julio Roche

Julio Roche es Specialist Director del área de System Development&Integration, en la práctica de DxD de Deloitte. Profesional con más de 25 años de experiencia en el mundo del desarrollo de soluciones tecnológicas, su labor se encuentra actualmente focalizada en el terreno de la movilidad y la transformación digital, lo que le ha llevado a estar involucrado en procesos de implantación de metodologías ágiles desempeñando todos los roles que estas enumeran. Ha sido Agile Coach&Trainer, Scrum Master, Product Owner y parte del Development Team.