NicolasRuiz81
commented
2 years ago Definición del Sprint Backlog
El Sprint Backlog es la suma de el Objetivo del Sprint, los elementos del Product Backlog elegidos para el Sprint, más un plan de acción de cómo crear el Incremento de Producto.
Es uno de los 3 artefactos de Scrum y se construye durante el evento del Sprint Planning. Es un plan realizado por y para los Developers.
El equipo generalmente divide el trabajo en elementos llamados Sprint Backlog Ítems (SBI). Estos elementos pueden representar tareas que el equipo debe completar, bloques de construcción intermedios que se combinan en una entrega, o cualquier otra unidad de trabajo que ayude al equipo a comprender cómo lograr el Sprint Goal dentro del Sprint.
El compromiso del Sprint Backlog: El Objetivo del Sprint
Como todos los artefactos en Scrum, el Sprint Backlog también contienen un compromiso asociado. El compromiso del Sprint Backlog es el Objetivo del Sprint y se crea durante la Sprint Planning.
El Objetivo del Sprint es el único propósito del Sprint. Si bien el Objetivo del Sprint es un compromiso de los Developers, proporciona flexibilidad en términos del trabajo exacto necesario para lograrlo.
El Objetivo del Sprint también crea coherencia y foco, lo que alienta al Equipo Scrum a trabajar en conjunto en lugar de en iniciativas separadas.
Visibilidad del avance del Sprint
Es importante que el Sprint Backlog esté visible para todo el equipo, ya que tiene como objetivo proporcionar transparencia sobre el estado del trabajo planificado para el Sprint. Es por esta razón que me gusta llamarlo un radiador de información.
Los Developers realizan un seguimiento del trabajo total restante al menos una vez por día en la Daily Scrum para proyectar la probabilidad de lograr el Sprint Goal. Al reconocer el trabajo restante a lo largo del Sprint, los Developers pueden administrar su progreso.
Ejemplo de Sprint Backlog
Si bien la guía Scrum no define como implementar este artefacto, creo que una manera recomendada de hacerlo es a través de la implementación de un tablero Kanban.
Tablero Kanban
El tablero Kanban es una herramienta compuesta por columnas para representar el estado de una tarea y filas que representan diferentes tipos de actividades (por ejemplo tareas descompuestas de las Historias de Usuario).
Cada tablero de Kanban tiene al menos tres columnas con estados base:
«To Do» / Por hacer (punto de entrada de una tarea) «W.I.P» / Trabajo en proceso «Done» (Terminado)
A este tablero se le pueden agregar más columnas como por ejemplo «QA»
Ejemplo de implementación en un tablero Kanban:
¿Quién es el responsable del Sprint Backlog?
Este artefacto de Scrum pertenece únicamente al los Developers. Los Developers modifican este artefacto durante todo el Sprint. Este surgimiento ocurre cuando el Developers trabajan a través del plan y aprende más sobre el trabajo necesario para lograr el Sprint Goal.
Cuando los elementos del plan se consideran innecesarios, se eliminan. Solo los Developers puede cambiar el Sprint Backlog durante un Sprint.
La diferencia entre Product Backlog y Sprint Backlog
El Sprint Backlog se crea durante el evento de Sprint Planning. Se compone de los elementos seleccionados de la parte superior (lo más prioritario) del Product Backlog que se consideran necesarios a realizarse para cumplir el Objetivo del Sprint y que los Developers cree factible terminar según su velocidad y capacidad.
¿Qué es el Increment en Scrum?
El Increment (“Incremento” en español) o también conocido como Incremento de Producto es la suma de todos los ítems del Product Backlog (PBIs) completados durante un Sprint y el valor de los incrementos de todos los Sprints pasados. Es uno de los 3 artefactos de Scrum y se presenta en cada Sprint Review.
El compromiso del Increment: El Definition of Done
Como todos los artefactos en Scrum, el Increment también contienen un compromiso asociado. El compromiso del Increment es el Definition of Done.
¿Qué es el Definition of Done?
El Definition of Done «DoD» (o “Definición de terminado” en español) es una descripción formal del estado del Increment cuando cumple con las medidas de calidad requeridas para el producto.
Podemos decir que es un acuerdo común que nos sirve para determinar cuándo un elemento de la lista del producto está finalizado. Si un elemento del Product Backlog no cumple con la Definition of Done, no se puede publicar ni presentar en la Sprint Review. En su lugar, vuelve al Product Backlog para su consideración futura.
¿Quién crea el Definition of Done?
Si el Definition of Done para un Increment es parte de los estándares de la organización, todos los Scrum Teams deben seguirla como mínimo. Si no es un estándar organizacional, el Scrum Team debe crear un Definition of Done apropiada para el producto.
¿Qué pasa con el Definition of Done cuando hay múltiples equipos?
Cuando hay varios Equipos Scrum trabajando sobre un mismo producto, deberán establecer un único Definition of Done y cumplirlo en conjunto.
Ejemplo de Definition of Done
Podemos decir que el Definition of Done más básico de cualquier equipo es el siguiente:
- Cumple todos los Criterios de Aceptación.
A medida que el equipo desea aumentar la calidad de entrega de su producto puede agregar más ítems al Definition of Done.
Por ejemplo, en un contexto de desarrollo de software, un equipo podría agregar los siguientes ítems:
- Cumple todos los Criterios de Aceptación.
- El código cumple los estándares de sintaxis establecidos.
- La solución fue implementada con Test-Driven Development (TDD).
- El código tiene 100% de cobertura de test unitarios.
- …
En cambio, en un contexto de servicios un equipo podría agregar los siguientes ítems:
- Cumple todos los Criterios de Aceptación.
- Todas las tareas de la User Story fueron completadas
- Todo el trabajo y documentación requerida está adjuntado en la User Story para que el Product Owner pueda revisarlo.
- …
¿Cuál es la diferencia entre el Definition of Done y los Criterio de Aceptación? Mientras que los Criterios de Aceptación son condiciones particulares de cada elemento del Product Backlog, el Definition of Done son condiciones que se deben cumplir en todos los elementos del Product Backlog.
¿Se puede tener más de un Definition of Done?
Si bien en la mayoría de los casos tenemos un único Definition of Done que se aplica a todos los elementos del Product Backlog podríamos identificar elementos que requieran tener su propia definición. Por ejemplo podríamos tener un DoD general, que se aplique a todos los elementos del Product Backlog y otro DoD adicional que se aplique solamente a los requerimientos de documentación legal o que requieran diseño gráfico.
El Increment en Scrum y el empirismo
Hay veces que puede ser complicado comprobar si el equipo ha creado valor en cada Sprint. No obstante, el Product Owner quiere asegurarse de que el producto aumente su valor en cada Sprint.
El Product Owner desea crear un producto valioso de la forma más adecuada. El mercado tiene distintas necesidades y siempre existe la posibilidad de un desequilibrio entre ellas y los objetivos del Product Owner. Por lo tanto, el Product Owner debe corroborar regularmente que las cosas que se desarrollaron estén en buen camino para crear el valor que imaginó.
Haciendo uso de Scrum como marco de trabajo empírico, debemos buscar que nuestro Incremento nos permita obtener información nueva y relevante sobre el mercado y el contexto para poder adaptarnos rápidamente. Es por esto que debemos prestar atención al momento de inspeccionar este artefacto, qué hipótesis de negocio estamos validando y qué aprendimos del producto.
Equipos multidisciplinarios y multifuncionales
Las partes interesadas esperan que los Developers entregue algo concreto al finalizar cada Sprint, algo que les aporte valor a ellos. Un de especialistas de varios silos organizativos, o incluso varios equipos de desarrollo que trabajan juntos, puede creer que tienen un producto real cuando estos especialistas completan su trabajo. Pero, debido a la falta de una perspectiva de equipo compartida, es posible que no hayan producido nada más que componentes aislados. Todo el producto es más valioso que la suma de estos componentes, y el valor real proviene de la integración de estos componentes en un todo coherente. Es improbable que al mercado le importe cómo el equipo particionó el producto para su conveniencia de desarrollo.
Para entregar el Incremento, los Developers debe ser multifuncional, es decir, que cuente con todas las habilidades necesarias para entregar un incremento de valor al finalizar cada Sprint. Desde mi punto de vista creo que este es uno de los mayores desafíos que vengo observando en distintas organizaciones que intentan adoptar Scrum, dado que suelen existir incentivos hacia las personas y equipos en especializarse en un área o tecnología lo cual dificulta que un equipo solo pueda crear un Incremento completo.
El incremento debe ser un paso hacia la visión del producto o algún objetivo que responde a esa visión. En este sentido es muy útil tener bien presente el Objetivo del Sprint a la hora de construir cada Incremento.
Recabar información sobre sprint backlog e increment ,se pueden incluir imágenes y videos adicionales que aporten al tema.