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 para los Desarrolladores, es decir, una lista de nuevas funcionalidades, mejoras y modificaciones al Producto que se implementarán en el Sprint inicial. Después del inicio de un Sprint, el Backlog se convierte en una cola vinculante de la cual los Desarrolladores eligen tareas para realizar.
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. Así, consiste en una lista de tareas elaborada de manera que sea clara para los Desarrolladores. El Sprint Backlog generalmente toma 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:
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 junto para formular el Objetivo del Sprint, es decir, selecciona qué funcionalidad del Product Backlog implementar. El Objetivo del Sprint define cómo implementar el Producto o posponer la fecha límite para cumplir con las expectativas del Cliente.
El siguiente paso es reflexionar 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 un lugar que es fácilmente accesible para todos los miembros del Equipo de Desarrollo. En el espacio físico, suele ser una pizarra colgada en el lugar de trabajo. Mientras que en el espacio digital, existe como un documento compartido en la nube que todos los Desarrolladores pueden actualizar. Aunque cada miembro de un Equipo Scrum debería mantenerlo actualizado a diario, es el Scrum Master o uno de los Desarrolladores quienes generalmente asumen esa responsabilidad.
El Product Backlog no especifica cómo ejecutar exactamente las tareas. Es papel 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 empodera a cada Desarrollador, brindando un sentido de independencia y responsabilidad.
La misma idea se aplica a tratar el Sprint Backlog como una lista desordenada de tareas a ejecutar. A diferencia del modelo tradicional de empuje (donde el Equipo o Desarrollador actúa según una agenda predefinida e impuesta), en el modelo de tirón, los Desarrolladores seleccionan qué tareas realizar (modelo de tirón).
El Sprint Backlog especifica:
Varios herramientas métricas reflejan el progreso del trabajo escrito en el Sprint Backlog. Más a menudo es el Gráfico de Quema, 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 Objetivo del Sprint está avanzando según lo planeado.
Puede suceder durante un Sprint que descubras que el plan de trabajo ha sido diseñado de manera poco realista. En otras palabras, el número de tareas pendientes en el Objetivo del Product Backlog es demasiado alto o demasiado bajo. En cualquier caso, los Desarrolladores y el Product Owner se dedican a averiguar qué cambios aplicar al Sprint Backlog actual. Es posible reducir la cantidad de trabajo, seleccionar tareas adicionales del Product Backlog o extender las soluciones ya planificadas. Sin embargo, ten en cuenta que el Objetivo del Sprint en sí debe permanecer inalterado.
Un Sprint Backlog es una lista de tareas que los Desarrolladores planean realizar durante un Sprint. Es una especie de contrato detallado con el Product Owner. El Sprint Backlog surge durante la Planificación del Sprint en la que participa todo el Equipo Scrum. El Gráfico de Quema refleja el grado de finalización de las tareas aceptadas para implementación.
Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Como Gerente de Proyectos, 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 presión de tiempo la convierten en la mejor persona para hacer realidad proyectos complicados.
¿Eres un freelancer que busca formas de promocionar su portafolio? Hoy en día, no solo…
La gestión financiera digital y la contabilidad en línea se han vuelto cada vez más…
Los estatutos del proyecto son el pan y la mantequilla de la gestión de proyectos.…
Las organizaciones de diversas industrias establecen relaciones con posibles empleados, proveedores y socios todos los…
Hay más que suficientes técnicas de gestión por ahí. Algunas parecen intrincadas, mientras que otras…
¿Sabes cómo empezar una ONG? ¿Has estado pensando en ello? ¿Eres consciente de lo que…