Guía Scrum | 28. Sprint en Scrum

Publicado: 2022-06-08

Varios eventos más pequeños conforman un Sprint en Scrum. Los Sprints, a su vez, forman juntos un camino destinado a desarrollar y lanzar un Producto. Cada Sprint tiene un Sprint Goal específico y un Sprint Backlog mantenido por el Equipo de Desarrollo.

¿Qué es Sprint en Scrum? Tabla de contenidos:

  1. Sprint en Scrum – Introducción
  2. Sprint en estructura Scrum
  3. Sprints y los tres pilares del empirismo
  4. Transparencia
  5. Inspección
  6. Adaptación
  7. ¿Qué cambios hacer durante un Sprint?
  8. Sprint en Scrum – Resumen

Sprint en Scrum – Introducción

Sprint es el evento más grande de Scrum, sobre el cual escribimos en este artículo. Los Sprints siguen un ciclo continuo desde el principio hasta el final del trabajo en un Producto. Y cada iteración acerca al equipo a la consecución del objetivo del producto.

Cada Sprint tiene un Sprint Goal específico para garantizar la coherencia en el trabajo del Equipo de Desarrollo. Toma la forma de un objetivo comercial y responde a la pregunta "¿Por qué?", ​​"¿Con qué fin?" , o "¿Por qué?" .

El flujo de trabajo de un Sprint se documenta en el Sprint Backlog, que enumera el trabajo necesario para lograr el Sprint Goal. Su descripción detallada se puede encontrar aquí.

sprint in scrum

Sprint en estructura Scrum

Cada Sprint tiene una estructura específica e incluye los siguientes eventos:

  • Planificación de Sprint: comienza el Sprint. Durante este evento, el Equipo Scrum selecciona el trabajo planificado del Product Backlog para realizarlo en el nuevo Sprint.
  • Daily Scrum : un evento diario donde los desarrolladores planifican las tareas del día
  • Revisión de Sprint : abierta a las partes interesadas, realizada el último día de un Sprint. Su propósito es resumir el Sprint en términos de progreso en el Producto
  • Retrospectiva de Sprint : el evento de cierre de un Sprint, donde el Equipo Scrum analiza las formas de trabajar y las ideas para mejorar

La repetición de eventos Sprint promueve la implementación de buenas prácticas organizacionales. En otras palabras, el Equipo Scrum implementa las rutinas necesarias para una planificación efectiva y, mientras trabaja, llama la atención sobre los problemas que se pueden discutir en los eventos apropiados.

Sprints y los tres pilares del empirismo

Los Sprints hacen que el Equipo Scrum divida el trabajo en el Producto en segmentos de tiempo iguales que no duran más de un mes. Este marco fijo refuerza los tres pilares del empirismo:

  • transparencia
  • inspección
  • adaptación

Escribimos sobre los tres pilares del empirismo y su papel en Scrum con más detalle aquí. Pero hoy veremos cómo se aplican a Sprint y su estructura.

Sprints in Scrum and the three pillars of empiricism

Transparencia

Dividir el trabajo en Sprints mejora la transparencia ya que todas las personas involucradas pueden obtener la información requerida sobre el estado del trabajo del Producto en cada Sprint. Sprint Planning y Sprint Review, el comienzo y el final de un Sprint, combinados con una actualización del Product Backlog, brindan a todas las partes interesadas información valiosa sobre el estado actual del Producto.

Inspección

Al dividir el trabajo en Sprints, es posible monitorear frecuentemente su progreso. Esto promueve la identificación constante de problemas en dos áreas clave. Estos son:

  • problemas relacionados con el logro del objetivo del producto , al inicio y al final del Sprint, es decir, durante la planificación y la revisión del Sprint
  • Obstáculos en la forma en que trabaja el Equipo Scrum : durante las reuniones diarias y al final de cada Sprint, es decir, durante Daily Scrum y Sprint Retrospective

Adaptación

La adaptación es una parte muy importante del trabajo del Equipo Scrum, ya que permite solucionar los problemas identificados durante la inspección. Durante cada Sprint, Daily Scrum y Sprint Retrospective brindan un espacio seguro para hablar sobre cómo mejorar el Scrum Team. La implementación de las soluciones propuestas ocurre inmediatamente o al comienzo del próximo Sprint.

Sprint Planning y Sprint Review crean un espacio seguro para la discusión sobre los Objetivos y los métodos para alcanzarlos. Un buen Scrum Team autogestionado descubre con éxito qué y cómo implementar para el próximo Sprint.

¿Qué cambios hacer durante un Sprint?

Cada Sprint deja suficiente espacio para que Scrum Team mejore e improvise su forma de trabajar. Por lo tanto, identifica qué cambiar durante un Sprint. La Guía Scrum no proporciona una lista de dichos cambios. Sin embargo, la noción de empirismo proporciona pautas a seguir y adaptarse a la forma en que trabaja un Equipo Scrum en particular.

  1. Todos los cambios pueden poner en peligro el logro del Sprint Goal. De acuerdo con la primera regla, durante un Sprint no puedes, por ejemplo, reducir el número de tareas pendientes en ese Sprint, o cambiar significativamente sus características. Un Sprint está estrechamente relacionado con el Sprint Goal. Por lo tanto, cuando cambia la Meta, debemos abortar el Sprint. Sin embargo, esto casi nunca sucede, ya que la única razón por la que un Sprint falla es cuando el Objetivo se vuelve obsoleto. Tenga en cuenta que la decisión de finalizar un Sprint pertenece únicamente al propietario del producto.
  2. La calidad del trabajo no puede verse comprometida. Esta regla pretende evitar que el trabajo realizado durante un Sprint se convierta en un Incremento porque no cumple con la Definición de Finalización. Reducir la calidad del trabajo puede dar como resultado que se cumpla ostensiblemente el Sprint Goal, pero la forma en que se completan las tareas individuales no cumple con los estándares de calidad establecidos por la organización o requeridos por las partes interesadas.
  3. El Product Backlog puede llegar a ser detallado. Mientras se trabaja en un Producto, aumenta el conocimiento sobre el mismo. Por lo tanto, el detalle de las tareas a realizar aumenta de forma natural. Por tanto, es un cambio aceptable e incluso aconsejable durante un Sprint para detallar el Product Backlog.
  4. El alcance del trabajo puede aclararse o renegociarse. Este cambio, al igual que el anterior, implica una comprensión creciente de la naturaleza del trabajo que se realiza. El Equipo de Desarrollo puede hacerlo en consulta con el Propietario del Producto. Sin embargo, la condición básica para su introducción es la ausencia de conflicto con los principios 1. y 2.

Sprint en Scrum – Resumen

Sprint es el evento Scrum cíclico que contiene todos los demás. Tiene un sub Sprint Goal separado del Product Goal. Y el Sprint Backlog es diferente del Product Backlog. La naturaleza de los Sprints es cíclica. La duración fija de los Sprints es propicia para mantener buenas prácticas de flujo de trabajo y nutrir los tres pilares del empirismo. Durante un Sprint, el Equipo Scrum no puede cambiar su Objetivo. Sin embargo, puede refinar el Product Backlog y, a medida que crece el conocimiento, refinar y negociar el alcance del trabajo.

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

Autora: Natalia Jarós

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