-
-
-
-
URL copied!
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.
Top Insights
Escribiendo User Stories en Agile
AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnologyWhat is TM Forum Frameworx and how to...
UncategorizedAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnologyImpact Mapping en Metodologías ágiles
AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnologyTop Authors
Blog Categories
Trabajemos juntos
Contenido Relacionado
5 razones por las que tu proyecto necesita un Business Analyst
Contar con un Business Analyst (BA) en tu equipo no solo te ayudará a delegar tareas más operativas, sino que también potenciará al equipo de desarrollo y contribuirá significativamente al éxito de tu proyecto de desarrollo de software.
Conocer más
7 claves para ser un miembro de un equipo efectivo
Un gran desarrollador necesita trabajar tanto en sus habilidades técnicas como en sus habilidades blandas, ya que estas forman la base para cualquier profesional que quiera ser una pieza efectiva e inspirar un cambio positivo en su equipo y organización. He recopilado una serie de recomendaciones que considero básicas y de vital importancia para trabajar … Continue reading 5 consejos para una planificación eficaz del sprint →
Conocer más
Share this page:
-
-
-
-
URL copied!