Guía Scrum | 17. Pila de Sprint

El Equipo de Desarrollo crea un nuevo Sprint Backlog durante la Planificación del Sprint. A partir de ese momento, se convierte en el compromiso actual de los Desarrolladores, es decir, una lista de nuevas funcionalidades, mejoras y modificaciones del Producto a implementar en el Sprint de partida. Después del inicio de un Sprint, el Backlog se convierte en una cola vinculante desde la cual los Desarrolladores eligen las tareas a realizar.

¿Qué es un Sprint Backlog? - Tabla de contenido:

1. Introducción
2. ¿Cómo se crea el Sprint Backlog?
3. ¿Qué contiene el Sprint Backlog?
4. Usando el Sprint Backlog
5. Resumen

Introducción

Un Sprint Backlog describe el trabajo del Equipo de Desarrollo durante un solo Sprint. Por lo tanto, se expresa en lenguaje técnico. Describe tareas detalladas y sus soluciones planificadas. Por lo tanto, consiste en una lista de tareas elaborada de manera clara para los Desarrolladores. El Sprint Backlog normalmente tiene poco en cuenta el lenguaje de valor comercial del Producto, una forma de descripción propia del Product Backlog, que presentaremos aquí.

El Sprint Backlog surge:

• basado en la cartera de productos
• durante la duración de un Sprint
• durante un evento Scrum llamado Sprint Planning
• por todo el equipo Scrum, pero el equipo de desarrollo tiene un papel clave en su creación

¿Cómo se crea el Sprint Backlog?

Durante la Planificación del Sprint, el Product Owner propone cómo agregar valor al Producto en el próximo Sprint. Luego, todo el Equipo Scrum trabaja en conjunto para formular el Sprint Goal, es decir, selecciona qué funcionalidad implementar del Product Backlog. El Sprint Goal define cómo implementar el Producto o posponer la fecha límite para cumplir con las expectativas del Cliente.

El siguiente paso es pensar y establecer de manera realista el alcance del trabajo a realizar en el próximo Sprint y cómo lograrlo.

Los resultados de estos hallazgos vienen en forma de una descripción técnica de las tareas a realizar. Y esta lista se convierte en el nuevo Sprint Backlog.

El Sprint Backlog recién creado existe en una ubicación a la que todos los miembros del equipo de desarrollo pueden acceder fácilmente. En el espacio físico, suele ser una pizarra colgada en el espacio de trabajo. Mientras que en el espacio digital existe como un documento compartido basado en la nube que todos los desarrolladores pueden actualizar. Si bien cada miembro de un Equipo Scrum debe mantenerlo actualizado diariamente, es el Scrum Master o uno de los Desarrolladores quien suele asumir esa responsabilidad.

¿Qué contiene el Sprint Backlog?

El Product Backlog no especifica cómo ejecutar exactamente las tareas. Es el rol del Equipo de Desarrollo decidir. Ese movimiento crea suficiente espacio para que el equipo maniobre, mejorando así sus capacidades de autoorganización. Además, esta libertad para seleccionar la secuencia y los métodos de acción faculta a cada Desarrollador otorgándole un sentido de independencia y responsabilidad.

La misma idea se aplica al tratamiento del Sprint Backlog como una lista desordenada de tareas para ejecutar. A diferencia del modelo push tradicional (donde el Equipo o Desarrollador actúa de acuerdo con una agenda predefinida e impuesta), en el modelo pull, los Desarrolladores seleccionan qué tareas hacer (modelo pull).

El Sprint Backlog especifica:

1. El Sprint Goal : es decir, una respuesta a la pregunta de por qué realizar las tareas programadas este Sprint
2. La lista de nuevas características y mejoras del Producto para desarrollar en este Sprint. Esto se debe a que contiene los elementos del Product Backlog seleccionados para su implementación en este Sprint.
3. La lista de tareas a realizar , es decir, una descripción técnica de cómo y por quién el trabajo que resultará en Incremental…

Usando el Sprint Backlog

Varias herramientas métricas reflejan el progreso del trabajo escrito en el Sprint Backlog. La mayoría de las veces es el Burndown Chart , que cubriremos completamente en un artículo separado dedicado. Con tal visualización, el Equipo de Desarrollo puede ver fácilmente si el trabajo en el Sprint Goal avanza según lo planeado.

Puede suceder durante un Sprint que descubras que el plan de trabajo se ha diseñado de manera poco realista. En otras palabras, el número de tareas pendientes en el Product Backlog Sprint Goal es demasiado alto o demasiado bajo. En cualquier caso, los desarrolladores y el propietario del producto se ponen manos a la obra para averiguar qué cambios aplicar al Sprint Backlog actual. Es posible reducir la cantidad de trabajo, seleccionar tareas adicionales del Product Backlog o ampliar las soluciones ya planificadas. Sin embargo, tenga en cuenta que el Sprint Goal en sí mismo debe permanecer inalterado.

Resumen

Un Sprint Backlog es una lista de tareas que los desarrolladores planean realizar durante un Sprint. Es una especie de contrato detallado con el propietario del producto. El Sprint Backlog surge durante la Planificación del Sprint en la que participa todo el Equipo Scrum. El Burndown Chart refleja el grado de cumplimiento de las tareas aceptadas para su implementación.

Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autora: Carolina Becker

Como Project Manager, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos