Scrum: Sprints, Artefactos y Mejores Prácticas

Gestión de Sprints

Revisión del Sprint

En la revisión del sprint, se analiza e inspecciona el incremento generado. Se adapta la pila del producto si es necesario. Se revisa el sprint para ver el incremento y adaptar el Product Backlog. Se determina qué hacer para incrementar el valor. Es una reunión informal que facilita la retroalimentación y fomenta la colaboración. El Scrum Master lidera la reunión y se asegura de que todos la entiendan. Asiste todo el equipo Scrum y los interesados claves invitados por el Product Owner, quien informa sobre lo terminado y lo no terminado. El Product Owner habla de la foto del Product Backlog y muestra objetivos y fechas de entrega basados en el progreso. El equipo ve qué se hará después y cómo pudo haber cambiado el objetivo.

Retrospectiva del Sprint

La retrospectiva del sprint es una revisión de lo sucedido durante el Sprint. Es una reunión en la que el equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el próximo sprint. El equipo se inspecciona a sí mismo y crea un plan de mejoras. Se realiza después de la revisión del sprint y antes de la planificación. La lleva a cabo el Scrum Master, quien se asegura de que todos la entiendan. El propósito es inspeccionar cómo fueron las personas, las relaciones y los procesos (herramientas). Se identifican y ordenan los elementos más importantes (buenos, malos, mejoras). Se crea un plan para mejorar la calidad del producto o adaptando la definición de «DONE».

Cancelación del Sprint

Un sprint se puede cancelar antes de que llegue a su fin. Solo el Product Owner puede hacerlo, bajo la influencia de los interesados, el equipo de desarrollo o el Scrum Master. Se cancela solo si el objetivo queda obsoleto (si la compañía cambia de dirección o si las condiciones del mercado o la tecnología cambian), cuando no hay sentido seguir con él. Al cancelar un sprint, hay que revisar los elementos del Product Backlog completados y terminados. Los no completados se vuelven a estimar y se reintegran al Product Backlog. Las cancelaciones son traumáticas y poco comunes.

Artefactos de Scrum

Los artefactos representan trabajo o valor y promueven los pilares de Transparencia, Inspección y Adaptación, sobre todo, la transparencia.

Product Backlog

Responsable: Product Owner.
Contenido, orden y disponibilidad: Lista ordenada de todo lo necesario para el producto. Es la única fuente de requisitos para cambios. Nunca está completa. Solo refleja los requisitos conocidos y mejor entendidos. Evoluciona con el producto y el entorno. Cambia para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Existe mientras exista el producto.
Uso: Enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que son cambios para entregas futuras.

Sprint Backlog

Conjunto de elementos del Product Backlog seleccionados para el sprint, más el plan para entregar el incremento del producto y conseguir el objetivo del sprint. Es una predicción del equipo de desarrollo de qué funcionalidad formará parte del siguiente incremento y el trabajo necesario para entregar esta funcionalidad en un incremento «DONE». Hace visible el trabajo que el equipo de desarrollo considera necesario para el Sprint Goal. Incluye una mejora de procesos de alta prioridad indicada en la Sprint Retrospective.
Uso: Es un plan con el nivel de detalle suficiente para ser entendido en el Daily Scrum. El equipo de desarrollo lo modifica y emerge a lo largo del sprint. Mientras se trabaja en él, si se necesita algo nuevo, el equipo de desarrollo lo agrega aquí. Se actualiza la estimación del tiempo restante. Si algún elemento se considera innecesario, se elimina.

Incremento

Suma de los elementos del Product Backlog completados durante un sprint y el valor de los incrementos de todos los sprint anteriores. Al final del sprint, el nuevo incremento debe estar «DONE». El incremento es un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo. Es un paso hacia una meta. Debe poder ser usado, aunque el Product Owner puede elegir si liberarlo o no.

PRINCE2

PRINCE2 ayuda a definir quién debe participar en el proyecto y cuáles son sus responsabilidades. Posteriormente, mediante su proceso, ayuda a conducir la ejecución para asegurar el éxito del proyecto, proporcionando una guía fácil y repetible para la entrega de proyectos exitosos. Al dividir los proyectos en fases manejables, permite el control eficiente de los recursos y el control periódico de su evolución.

Principios de PRINCE2

1. Justificación comercial permanente.
2. Aprendizaje basado en la experiencia.
3. Roles y responsabilidades definidos.
4. Gestión de proyectos por fases.
5. Gestión por excepción (delegar autoridad y solo intervenir en casos excepcionales).
6. Orientación a productos.
7. Adaptación.

Product Backlog vs. Sprint Backlog

El Product Backlog corresponde con todas las tareas, funcionalidades o requerimientos a realizar. El Product Owner es la persona que se encarga de marcar las prioridades y, al final, es quien mantiene y actualiza, dado el caso, la lista de tareas. El Sprint Backlog corresponde con una o más tareas que provienen del Product Backlog. Es decir, del Product Backlog se extraen una o más tareas que van a formar parte del Sprint Backlog.