5 consejos para una planificación eficaz del sprint

La sprint planning es una de las ceremonias de Scrum en donde se define el objetivo de las siguientes semanas de trabajo. Debido a su importancia y complejidad, suele demorarse más que las otras ceremonias y puede ser difícil para el equipo sobrellevarla. 

Como queremos cumplir con los objetivos de la misma y que nadie pase un mal rato en el camino, es que aquí presentaremos 5 cualidades que toda planning debería cumplir para ayudar a que no se alargue innecesariamente. 

Sprint backlog priorizado

Es fundamental llegar a la sprint planning con el backlog ya priorizado. Ese trabajo se debe hacer de antemano para que durante la planificación directamente se empiece por las historias de usuario y tareas más importantes. Si queremos tener una planificación efectiva, es inaceptable que en el medio de la reunión los involucrados se vean las caras y digan: “¿y ahora con que ticket seguimos?”. 

User stories que cumplan con definition of ready

El Definition of Ready (DoR) es un conjunto de características que debe cumplir una historia de usuario para considerarse lista para ser trabajada. Es una especie de contrato que firma el equipo de desarrollo con la PO. Lo que se incluya en el mismo va a depender de cada proyecto. Es de vital importancia que todos los tickets cumplan con el DoR de antemano porque eso garantizará que habrá mayor entendimiento a la hora de planificarlo y menos discusiones innecesarias. 

Algunas pautas que podría involucrar un DoR son: dependencias entre historias de usuario identificadas, diseños o referencias adjuntos, criterios de aceptación completos, caminos alternativos definidos, etc. Si por ejemplo la historia de usuario que se está abordando en la planning no tiene los caminos alternativos definidos, eso sin duda que va a desencadenar una serie de preguntas por el equipo de desarrollo, que si bien son imprescindibles y muy útiles, incrementarán drásticamente el tiempo de duración de la ceremonia. 

Colaborativa

Además de ser bueno para el trabajo en conjunto del día a día, es importante que una sprint planning sea colaborativa, es decir, que todos los miembros del equipo están alineados y colaborando. El Product Owner (PO) debe estar presente durante la reunión para aclarar cualquier duda sobre las historias de usuario, y el equipo debe tener la oportunidad de hacer preguntas y ofrecer comentarios. 

Todos los miembros del equipo deben sentirse cómodos compartiendo sus opiniones y debe haber un ambiente de colaboración y respeto mutuo. Podría parecer que esa confianza desembocaría en mayor cantidad de charlas aumentando el tiempo de duración de la planning, pero por el contrario lo que sucede es que si bien habrá más diálogos, habrá menor cantidad de retrabajo. 

Si por ejemplo el PO del proyecto decide que no quiere participar de la planning porque ya está todo completo en base a su opinión, podría ocurrir que el equipo de desarrollo planifique tareas que luego no sean del todo correctas o encaradas desde otro ángulo y que termine siendo necesario hacer otra sesión de planificación, generando un retrabajo adicional. O peor aún, capaz que se da cuenta de esa diferencia entre expectativa y realidad luego que ya está desarrollada. 

Objetivos claros

Como toda ceremonia, es fundamental para que se puedan cumplir sus objetivos en tiempo y forma, que todos los involucrados sepan qué hay que lograr y qué se espera de cada uno. Va a ser fundamental en ese aspecto el trabajo del Scrum Master para educar y ser el moderador que vela por la integridad de la reunión. Sólo se deben tratar temas que incumban a la planning en sí, no es momento de refinar tickets. Obviamente que con eso no quiero decir que no sea posible hacer alguna pregunta concreta que pueda dar claridad sobre cómo encarar un problema, pero no estar desarrollando temas que no sean estrictamente necesarios para la planificación curso. Cualquier otro tema puede y debe ser desarrollado luego.

Participantes limitados

Para evitar que la sprint planning se convierta en una reunión eterna, es importante limitar el número de participantes a las personas que realmente necesitan estar presentes. Se recomienda que el equipo de desarrollo, el Scrum Master y el Product Owner sean los únicos participantes en la reunión de planificación del sprint, a menos que se necesite la presencia de otra persona para proporcionar información específica. Esto ayudará a reducir el número de discusiones innecesarias y evitará que la reunión se prolongue demasiado.

Bonus track!

¿Aún cumpliendo todas esas características consideras que la planning se está tomando más tiempo del deseado? Algunas ideas que podrían implementarse dependiendo del proyecto podrían ser:

  • Llegar a la planning con el tasking out pensado: Si tenemos una historia de usuario que ya por su naturaleza va a ser abordada por una persona en particular, esa podría tener el listado de tareas ya pensado y estimado de antemano. No se busca evitar conversaciones, que son fundamentales, sino más bien el tiempo de pensar los lineamientos iniciales. Hay veces que sobre el cierre del sprint algún participante terminó todas las historias de usuario y no puede ayudar al equipo con las que quedan. ¿Por qué no en vez de tomar algo nuevo no dedicarle las horas restantes del día a ganar entendimiento sobre los tickets que se van a desarrollar en la siguiente planning?
  • Contar con una agenda clara: Una sugerencia podría ser establecer una agenda clara para la reunión y asegurarse de que se siga. Eso va a ayudar a que todos los participantes sepan cómo se va a desarrollar la reunión y permitirles acomodarse para que la sobrelleven de la mejora manera. ¿Por qué no incluso ya establecer un recreo? ¿Por qué no partirla en dos? Hay que lograr que no sea un sufrimiento para los participantes sino algo que todos veamos como útil.  

¿Cómo saber si estamos yendo por el buen camino? 

La planning es una ceremonia muy importante y es deseado no sea un martirio para todos los participantes mientras se busca que se cumplan sus objetivos. 

Siguiendo estas ideas seguramente se mejore la calidad de la misma, pero sin dudas que el mejor indicador lo van a obtener hablando con el equipo durante las retrospectivas. Es fundamental aprovechar esta instancia de retrospectiva para identificar cómo se siente cada uno y qué cosas se pueden mejorar para que la planificación sea más efectiva.

Author

Manuel-Asenzo

Author

Manuel Asenzo

Manager at GlobalLogic Latinoamérica

View all Articles

Top Insights

Ciclos de vida BPM

Ciclos de vida BPM

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Criterios de Aceptación

Criterios de Aceptación

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Escribiendo User Stories en Agile

Escribiendo User Stories en Agile

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
What is TM Forum Frameworx and how to apply it to your business?

What is TM Forum Frameworx and how to...

UncategorizedAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Impact Mapping en Metodologías ágiles

Impact Mapping en Metodologías ágiles

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Top Authors

Sergio Fiorillo

Sergio Fiorillo

Engineering Manager

Pablo Alvarez

Pablo Alvarez

Delivery Director, Finance & Commerce

Manuel Asenzo

Manuel Asenzo

Manager at GlobalLogic Latinoamérica

Rodrigo Paschetta

Rodrigo Paschetta

Manager at GlobalLogic Latinoamérica

Blog Categories

  • URL copied!