¿Qué es una reunión de planificación de sprints?
Los equipos de desarrollo de software dependen de los sprints para ayudarlos a mantener el ritmo del lanzamiento de nuevas versiones de software, llamadas iteraciones. Con las demandas de la competencia sobre qué incluir en una iteración, un equipo de desarrollo debe tener muy claro en qué debe centrarse durante un sprint, por ejemplo, ¿deben primar ciertas correcciones de errores sobre el lanzamiento de nuevas funciones, o viceversa?
La metodología Agile también se ha vuelto popular en otros campos e industrias porque este enfoque centrado puede aumentar la efectividad, la productividad y la calidad.
Antes de que se ponga en marcha un sprint, el equipo del proyecto participa en una sesión de planificación de sprints. En esta sesión, se alcanzan dos decisiones clave:
-
Objetivo del sprint: se refiere a lo que se puede entregar durante el sprint.
-
Sprint Backlog: lista de tareas que se deben completar durante el sprint para alcanzar ese objetivo.
La planificación de sprints es un ejercicio limitado por tiempo y, por lo general, se lleva a cabo durante una hora a la semana por un período de aproximadamente ocho semanas.
Agile Project Management E-book
How can Agile PM help you do more with less?
Agile project management empowers teams to adapt to change with increased speed and flexibility. Learn how to implement Agile PM and get the most out of the methodology.
La planificación de sprints encaja con Scrum y otros métodos Agile
La planificación de sprints desempeña un papel importante en el universo de las metodologías de desarrollo Agile que priorizan la capacidad de respuesta, la flexibilidad y la mejora continua, y buscan ayudar a las organizaciones a sobresalir en la gestión del trabajo en un mundo donde las prioridades y los mercados están cambiando rápidamente. A medida que evolucionan los requisitos de los clientes y la competencia, la planificación de sprints determina qué trabajo abordar a continuación.
En software, la planificación de sprints determina qué cambios o funciones del producto se pueden lograr y cómo implementarlos de manera más eficiente en la próxima iteración. Este proceso de planificación garantiza que el equipo aborde una cantidad realista de trabajo y realice primero el que sea más importante. Después de todo, se puede lograr mucho durante un sprint sin comprometer la calidad.
La planificación de sprints también se utiliza para métodos Agile híbridos, como el enfoque Scrumban, una combinación de Scrum y Kanban, el sistema de trabajo basado en la visión y orientado a la demanda asociado con Toyota. Scrumban combina iteraciones de longitud fija con un proceso de entrega estandarizado, lo que significa que más de un equipo especializado puede trabajar en un solo elemento de trabajo.
Para comprender cómo funciona la planificación de sprints con Scrum, es útil revisar primero las funciones y procesos clave del método. Durante la planificación de sprints, el equipo del proyecto trabaja con el responsable del producto (la parte interesada clave de la empresa u organización del producto) y se facilita mediante un Scrum Master (la persona que actúa como líder de servicio y se asegura de que el proceso fluya, entrenando al equipo y ayudando a todos a comunicar y comprender la misión).
Estos participantes crean un sprint backlog, que es una lista de funciones o cambios extraídos del backlog del producto que se desarrollarán e implementarán al final del sprint. El backlog del sprint se forma a partir del objetivo del sprint, es decir, el que se puede lograr durante el sprint.
“The most common mistake I’ve seen is when a team tries to plan a sprint when the product backlog is not ready with good user stories that are immediately actionable,” says Scrum Master Scott Luse of Dassault Systèmes and other companies. “Another, less common, mistake is to conduct a sprint planning meeting without having the product owner in the room to discuss the work and sprint goals. In both cases, the sprint will typically start with a low chance of success. A good Scrum master should protect the team and ensure this doesn’t happen” he adds.
Scrum and Agile expert Laura Neves, Program Manager at Microsoft, urges teams to make sure at the start that everyone is on the same page in terms of language and terminology.
"Un hábito súper simple, pero muy útil: Siempre deletree sus acrónimos al escribir los objetivos del sprint, las hojas de ruta y la definición de hecho. Nunca asuma que todos saben exactamente qué son, especialmente cuando hay recién llegados al equipo. Ahorre mucho en explicaciones y repeticiones del trabajo. Deletrearlos [acrónimos] también lo obliga a volver a evaluar cuán frescos están los conceptos que se usan desde hace mucho tiempo. ¿Usted (y su equipo) realmente recuerdan lo que se supone que debe suceder de principio a fin en su flujo E2E?" pregunta.
¿Quiere un enfoque más ágil para la gestión de proyectos?
Descubra todo lo que hay que saber sobre la gestión de proyectos Agile y consejos que le permitirán empezar a implementar las mejores prácticas de Agile PM.
Obtenga el libro electrónico gratuito para implementar las mejores prácticas de Agile
¿Cuánto dura una reunión de planificación de sprints?
Los expertos de Scrum generalmente recomiendan dedicar alrededor de una hora a la planificación de sprints para cada semana del sprint, hasta un total de ocho horas. Los proyectos altamente complejos pueden requerir más tiempo. Y puede tomar casi el doble de tiempo en función de la madurez del equipo de Scrum.
Para identificar por qué la cantidad de tiempo que un equipo ha estado reunido es un factor tan significativo para determinar la duración de un sprint, analizaremos el trabajo del psicólogo Bruce Tuckman, quien en 1965 propuso la idea de que el desarrollo del grupo se lleva a cabo a través de etapas establecidas:
-
Formación: cuando se reúne un nuevo equipo o se introducen nuevos miembros en él
-
Conflicto: cuando empiezan a discutir sobre cómo trabajar
-
Normalización: cuando los miembros del equipo llegan a un acuerdo en cuanto a los roles y relaciones de todos en el grupo
-
Desempeño: cuando el equipo comienza a dar un paso adelante, maximizar la productividad y minimizar la fricción entre los compañeros de equipo
No es de extrañar, entonces, que los equipos que aún están en las primeras etapas del desarrollo necesiten más tiempo de planificación para crear consensos que los equipos que han estado trabajando juntos durante más tiempo.
Este factor de aclimatación puede explicar por qué algunos críticos consideran que la planificación de sprints es una pérdida de tiempo. Por el contrario, los expertos de Scrum dicen que la planificación de sprints es un precursor vital de cualquier sprint. Por un lado, la planificación de sprints mejora la eficiencia de un sprint y evita que los desarrolladores abarquen mucho y aprieten poco. El proceso también genera consenso con el responsable del proyecto sobre las entregas del sprint. Además, brinda a los desarrolladores Agile una sensación de autoridad sobre su trabajo y les impide sentir que están tratando constantemente de conciliar las demandas de la competencia con su propia capacidad de trabajo.
“It's vitally important that the team drives the sprint goal and commits to something it can deliver. As much as the product owner wants to hear team members promise the moon and the stars, they can always bring in more work later if they complete what they’ve committed to,” says Jeff Crowl, a Scrum Master and Agile coach who has worked at Nike, T-Mobile, and other companies. “This goes double for a scaled enterprise, where other teams' sprints could actively depend on the work being done in two weeks,” he notes
Definir el objetivo del sprint es crucial para tener éxito
Los expertos afirman que el esfuerzo realizado en definir el objetivo del sprint da sus frutos al ayudar al equipo a garantizar que el sprint proporcione el máximo valor a la organización y a sus clientes.
El equipo determina el objetivo del sprint en colaboración con el responsable del producto, y la declaración del objetivo es corta (solo unas pocas frases).
Richard Hundhausen, President of Accentient Inc., which coaches companies in Scrum, says that the sprint goal is crucial: “I’d say the most common mistake is not collaborating with the product owner to create a sprint goal. Scrum teams typically jump right to forecasting without any consideration for a common theme for the work (the sprint goal). Without having a sprint goal, what will the Scrum team commit to? During the daily scrum, what goal will the development team plan their next 24 hours around?”
Scrum Trainer David Sabine of Agile consultancy Berteig says that without a clearly defined sprint goal, participants will struggle to determine what to tackle in the sprint. “The most common mistake in Sprint planning is that the team fails to achieve a clear sprint goal, making it impossible for team members to regulate the types of activity that belong in the sprint and the types of activity that do not,” he says.
Así como los objetivos en general, los buenos objetivos de sprint son SMART (específicos, medibles, alcanzables, realistas y con plazos limitados). Por ejemplo, un buen objetivo de sprint para un equipo de desarrollo de plataformas independientes en línea puede ser algo como "Crear un elaborador de informes de ingresos que proporcione la verificación de los ingresos independientes obtenidos en un año fiscal" o "Crear una interfaz de mensajería multimedia dentro de la plataforma en lugar de que los trabajadores independientes y los clientes dependan de servicios de mensajería de terceros". Las metas claramente indicadas facilitan la comunicación de los objetivos y del progreso a quienes no participan directamente en el sprint.
Se deben considerar varias cuestiones al elaborar el objetivo de un sprint. Por ejemplo, ¿cómo encajan los objetivos de nivel inferior, diseñados para alcanzarse en un solo sprint, con los objetivos estratégicos de alto nivel o con la visión a largo plazo de un producto? ¿Cuáles de las tareas del backlog del producto son relevantes para el objetivo del sprint y deben incluirse en el backlog del sprint? Y, ¿los objetivos del sprint son alcanzables y realistas en función de la cantidad de recursos y desarrolladores disponibles? Recuerde tener en cuenta los feriados, las vacaciones de los miembros del equipo y los eventos de la empresa al considerar el tiempo disponible.
El objetivo del sprint no es una simple formalidad que debe completarse y luego dejarse de lado una vez que el sprint realmente se ponga en marcha. Además de definir las instrucciones para que todo el trabajo se complete durante el sprint, también es el estándar por el que se mide el éxito de un sprint en la revisión posterior a este. Por lo tanto, es importante tener un objetivo que el equipo, dados sus recursos, pueda cumplir realmente.
Definir el backlog del sprint establece el plan de trabajo del equipo
El backlog del sprint consta de una lista de tareas que se deben completar durante un sprint. Si bien se elabora en conjunto entre el equipo Scrum y el responsable del producto, este último no suele participar en el proceso de planificación granular del sprint. Los equipos Scrum por definición se auto-organizan, por lo que los miembros del equipo dirigen el proceso. A menudo, el responsable del producto no está en una buena posición como para saber cómo el equipo debe lograr las tareas. De hecho, la estrecha participación del responsable en esta parte de la planificación puede incluso ser contraproducente.
En cambio, la función del responsable del producto suele ser la de especificar el objetivo del sprint, preparar los elementos candidatos para el backlog del sprint, indicar los requisitos para estos elementos y negociar con el equipo del desarrollador sobre la constitución del backlog hasta que ambas partes alcancen un consenso.
Por supuesto, el responsable del producto se reserva el derecho de hacer preguntas sobre los elementos del backlog del sprint, su orden y cómo se supone que deben cumplirse. El equipo Scrum preparará una lista de elementos del backlog que se compromete a generar y una lista de tareas y subtareas necesarias para completarlos. En el proceso, el equipo también estima la cantidad de esfuerzo necesario para completar cada elemento del backlog, generalmente con términos abreviados, como tamaños de camiseta o puntos de una historia.
Ron Madison, a Scrum Master at PayPal, says that it’s important at this stage to know what work comprises each task. “A mature team does tasking of stories before sprint planning, including both development and quality assurance,” he points out.
La cantidad de trabajo de un solo sprint debe poderse administrar, por lo general con un tiempo de reserva asignado. Tener el 20 por ciento de la capacidad de sprints asignado como "tiempo de holgura" no es inusual. Para hacer esto, los equipos utilizan una métrica llamada velocidad de sprint, que es la cantidad de trabajo, en puntos de la historia, completado durante un solo sprint. Por lo general, se utilizan cifras del sprint más reciente; esta práctica se denomina uso del "tiempo de ayer", ya que se cree que la velocidad del sprint anterior es el indicador más preciso de los sprints siguientes. La velocidad del sprint se ajusta en función de la disponibilidad de los miembros del equipo y la constitución del equipo Scrum.
“The most common mistake is overfilling a sprint with work,” says Troy Magennis, President of Focused Objective, a software development consulting firm. “If you are doing lots of first time work, uncertainty will be very high, so it's preferable to acknowledge that fact up front and leave space to get customer satisfaction for and high quality from the stories you do choose. The second and third biggest mistakes of sprint planning are also overfilling. Don't let quality suffer because you bite off more than the team can chew.”
La planificación de sprints puede dividirse en dos fases separadas: la reunión del QUÉ y la reunión del CÓMO. Durante la reunión del QUÉ, se define el objetivo del sprint, se crea el backlog del sprint y se decide la capacidad del equipo. Durante la reunión del CÓMO, el equipo Scrum crea la lista de tareas necesarias para completar cada elemento del backlog. En software, estas tareas suelen abarcar el diseño, la implementación, las pruebas y la documentación, y cada una no debería tardar más de un par de días en completarse. Si una tarea lleva más de un par de días, significa que los elementos del backlog del sprint son demasiado grandes para el trabajo de sprint y es posible que deban dividirse.
Luego, el equipo Scrum estima la cantidad de horas de trabajo necesarias para completar los elementos del backlog y calcula la duración total probable de las actividades del sprint. Según la capacidad del equipo Scrum, si los miembros sienten que pueden abordar más (o menos) durante un sprint, pueden solicitar un ajuste de iteración para aumentar o reducir el alcance del trabajo.
Mike Cohn, President of Mountain Goat Software, cautions teams against overplanning. “The biggest problem I see during sprint planning is teams taking it too seriously. They do this by trying to identify every task they'll need to do. That level of detail isn't needed. Identify enough tasks to know you're selecting the right product backlog items, but that doesn't mean you have to include every little task. ‘Get in, get’ out should be the rule for sprint planning,” he says.
¿Quién está presente para las reuniones de sprints?
Una sesión de planificación de sprints implicará los aportes de tres partes interesadas principales: el equipo scrum, el scrum master y el responsable del producto.
El equipo Scrum está formado por los desarrolladores que se ocupan de los elementos básicos del proyecto. Durante la reunión de planificación de sprints, el trabajo del equipo es estimar y argumentar lo que se puede y debe asumir durante un solo sprint. Luego, el equipo Scrum se comprometerá a cumplir con los objetivos del sprint, trabajar en el proyecto y garantizar la entrega de una nueva iteración que cumpla con los requisitos que se detallaron durante la planificación de sprints.
El Scrum master es un facilitador, enlace y coach para el equipo Scrum. Por lo general, son desarrolladores mayores y más experimentados que entienden cómo el trabajo del equipo se basa en objetivos estratégicos generales, metas a largo plazo y relaciones con los clientes. El Scrum master gestiona las relaciones externas del equipo (incluida la relación con el responsable del producto) y se asegura de que el equipo respete los principios del desarrollo Agile. En la sesión de planificación de sprints, el Scrum master guía al equipo Scrum para establecer objetivos adecuados para cada sprint, sirviendo como negociador entre los desarrolladores y el responsable del producto.
Laurens Bonnema, a Scrum Consultant with Xebia, says the Scrum master’s role is crucial to making sure the team acts as “value-driven problem solvers.” Says Bonnema, “An experienced Scrum master will help the team recognize the importance of a sprint goal and work with it to craft one at the start of the sprint planning. Usually, just asking the question, ‘So, what shall we focus on next sprint?’ will help a team select and slice the work.”
El responsable del producto es la parte interesada principal del proyecto, la persona o parte para la que se está creando el proyecto. La medida en que el responsable del producto se involucra en la planificación de sprints varía, pero tienden a ser discreta con respecto a la planificación de tareas de nivel inferior. En cambio, se reserva su autoridad para indicar el objetivo del sprint, seleccionar y priorizar los elementos del backlog del sprint y establecer los requisitos de aceptación para cada elemento.
¿Cuál es el objetivo de la reunión de revisión de sprints?
La planificación de sprints, irónicamente, comienza con terminar el sprint anterior. Al final de cada sprint, realice una reunión de revisión, en la que el equipo Scrum repasa lo que ha logrado y demuestra cómo funcionan las nuevas funciones y características.
Por lo general, el equipo Scrum, el responsable del producto, el maestro Scrum, otros desarrolladores de la organización, la gestión y otras partes interesadas asisten a la revisión del sprint. Mantenga un ambiente informal y una conversación bastante fluida.
Durante esta sesión, evalúe el trabajo del equipo en contra del objetivo del sprint que se estableció durante la reunión de planificación de sprints. ¿El equipo logró cada elemento del backlog del sprint? ¿Cumplió con el objetivo general del sprint? ¿Hubo alguna lección que aplicar al siguiente sprint?
Preparación para una reunión de planificación de sprints
Antes de dirigirse a una reunión de sprints, es bueno comprobar la hoja de ruta del producto. En este documento estratégico se describe cómo evolucionará un producto a lo largo de una extensa serie de sprints e iteraciones. Los elementos que finalmente aparecen en el backlog del sprint deben estar alineados con la hoja de ruta del producto, por lo que es importante tener la hoja de ruta fresca en mente. Si los elementos del backlog del sprint no están alineados con la hoja de ruta del producto, este corre el riesgo de perder dirección.
También debe celebrar una reunión de planificación previa con representantes del equipo Scrum, el Scrum master y el responsable del proyecto. Esta reunión, que se celebra unos días antes de la reunión principal de planificación de sprints, ofrece a todos la oportunidad de preparar el backlog. La preparación del backlog es el proceso de priorizar, estimar, detallar y determinar los criterios de aceptación para los elementos del backlog. Acelera la sesión de planificación en sí y permite una mayor productividad durante un sprint al combinar con mayor precisión la cantidad de trabajo requerido con la capacidad disponible.
“One of the biggest mistakes that I see related to sprint planning is an overall lack of preparation and solid understanding of the stories prior to the meeting. This [problem] can cause a myriad of issues. Teams need to fully understand a story before they can commit to the work, and, most often, a single one-to-four-hour meeting just isn’t going to cut it,” says Jennifer Guilbert, a Scrum Master with Capstone Consulting.
"Recomiendo agregar un punto de control de mitad de sprint o una actividad de preparación para reunir al equipo con el responsable del producto para revisar las historias agregadas al próximo backlog de sprints, hacer preguntas y obtener aclaraciones mucho antes de la próxima reunión de planificación de sprints. [Hacer] esto hará que la planificación de sprints sea mucho más eficiente e incluso puede reducir el tiempo a la mitad", afirma.
Descargar la plantilla de backlog del producto - Excel
Descargar la plantilla de backlog de sprints - Excel
Otras partes interesadas importantes pueden beneficiarse al asistir a una reunión de planificación previa, ya que ofrece a todos la oportunidad de asegurarse de estar satisfechos con la priorización de los elementos del backlog. También es un buen momento para incorporar al diseñador de experiencia de usuario a fin de que se pueda empezar a pensar en los cambios de diseño necesarios para los elementos del backlog completados.
Cuando se trata de usar técnicas para determinar la priorización de los elementos del backlog, las correcciones de errores y las reparaciones de fallas suelen recibir más calificación en el backlog de sprints. Otra práctica común es usar la priorización de negocios, en la que se pregunta qué elementos del backlog benefician más al negocio y, por lo tanto, se les asigna la máxima prioridad. Hay algunos factores posibles que deben tenerse en cuenta, como el riesgo que implica o mitiga el elemento de backlog y la cantidad de valor empresarial que se espera que este genere. Cuando faltan esas métricas, el método de priorización MoSCoW (debe tener, debería tener, podría tener o quisiera tener), que prioriza cada elemento como uno imprescindible, también puede ser una técnica útil. Y, por supuesto, debe partir de la experiencia del Scrum master al priorizar los backlogs; después de todo, están allí como asesores del equipo.
Una reunión de planificación previa de este tipo también ayuda al responsable del producto a asegurarse de que los elementos del backlog cumplan con la definición de listo del equipo, es decir, que se puedan procesar. Dado que los sprints no dejan mucho espacio para perder tiempo, los equipos de desarrollo tendrán un conjunto de criterios para los elementos del backlog que indican si estos están listos para trabajar en ellos.
Por lo general, primero prepara los elementos del backlog con los mayores valores. Para un equipo típico que trabaja en tareas habituales, la definición de listo puede incluir algo o todo lo siguiente: valores de punto de la historia asignados; dependencias eliminadas; ejemplos comprobables creados; y criterios de aceptación creados. Un acrónimo simple para explicar una definición sólida de listo es INVEST: independiente, negociable, valioso, estimable, pequeño y probable. Las historias validadas con INVEST están listas para pasar al backlog del sprint.
Del mismo modo, el responsable del producto puede ahorrar algo de tiempo durante la reunión de planificación si establece criterios de aceptación para los elementos del backlog. Una descripción simple y objetiva de lo que debe, debería y podría lograr la implementación de un elemento de backlog acelerará los debates sobre los criterios de aceptación durante toda la reunión de planificación.
“The most common mistakes I see in sprint planning are stories that don’t have an acceptance criteria and product owners not showing up. Another mistake I see on the part of Scrum masters is trying to assign all stories to a specific team member,” says Aleksandr Kofman, a Scrum Master at information provider Elsevier.
Los pasos de una reunión de planificación de sprints
A continuación, le mostramos cómo se desarrolla la reunión típica de planificación de sprints:
-
Se expone el panorama general: antes de que se ponga en marcha la reunión, el Scrum master le recuerda al equipo lo que en términos generales está tratando de lograr y cómo eso encaja con los objetivos estratégicos o la hoja de ruta de un producto. También es útil que el responsable del producto venga preparado para hablar de dos sprints de elementos para contextualizar hacia dónde se dirige el producto en el mediano plazo.
-
Se pone a todos al corriente: ahora es el momento de intercambiar la información que los involucrados en el próximo sprint deban saber. Las adiciones recientes al backlog, los cambios en la disponibilidad de los miembros del equipo o los nuevos aportes de las partes interesadas podrían compartirse en este momento.
-
Se presenta la velocidad objetivo para el próximo sprint: la velocidad es el número total de historias de usuario completadas durante un sprint. Por lo general, esta cifra se deriva del último sprint completado (el principio climático de ayer). Si la membresía (no los números) del equipo Scrum ha cambiado desde entonces, use la velocidad promedio en los últimos tres sprints. Si este es el primer sprint de su equipo, una buena cifra es de ocho puntos de historia por desarrollador por sprint; siempre puede ajustarlo más adelante.
-
Se confirma la capacidad del equipo: la capacidad del equipo se calcula como la cantidad total de horas de personas que abarcará el sprint. Así que, para un equipo Scrum de 10 personas con días de trabajo de 10 horas en un proyecto de 10 días, la capacidad sería de 1000 horas. Sin embargo, los equipos suelen deducir entre el 20% y el 40% de la capacidad máxima para dar un número más realista que tenga en cuenta el tiempo de inactividad, los gastos generales y las horas laborales perdidas. Además, dadas las dependencias inevitables entre los elementos del backlog, la capacidad práctica puede reducirse aún más por una especie de efecto dominó, en el que las tareas retrasadas retrasan aquellas que tienen éxito. Si se prevé que algún factor afectará la velocidad del sprint o la capacidad del equipo, regístrelos en esta etapa.
-
Se revisa la definición de hecho: la definición de hecho es una instantánea de cómo será la iteración resultante al final del sprint. Es importante que quienes realizan el trabajo y quienes lo inspeccionan acuerden una definición de hecho antes de que comience el sprint.
-
Se decide qué elementos del backlog del producto pasarán al backlog del sprint: en esta etapa, el equipo Scrum también decidirá si alguno de los elementos del backlog es demasiado grande como para completarse en un solo sprint y debe aplazarse.
-
Se determinan las necesidades de recursos, se describe quién hará qué cosa y se calcula el trabajo propio: si hay demasiado trabajo para que el equipo Scrum lo maneje razonablemente, eso se volverá evidente para el Scrum master en este momento. Asigne el trabajo y asegúrese de que las asignaciones de las personas coincidan con su capacidad.
-
Se definen los criterios de aceptación: los criterios de aceptación son estándares medibles para determinar si un elemento del backlog se ha completado con éxito. Especificar estos criterios es una prerrogativa del responsable del proyecto, aunque el equipo Scrum puede tener cierto margen de acción para negociar a través del Scrum master.
-
Se confirma y registra cualquier suposición, los nuevos problemas o las dependencias identificadas durante la planificación: esta información debe integrarse en el backlog del producto.
-
Se llama al consenso: esta es la prerrogativa del Scrum master. Casi al mismo tiempo, el equipo Scrum y el responsable del producto indicarán si creen que este es el mejor plan posible para el sprint.
-
Se elaboran las tareas involucradas: si el equipo Scrum necesita más información, especialmente en lo que respecta a las especificidades de los elementos del backlog del sprint, realice las preguntas necesarias en este momento, para poder convertir las historias de usuario en tareas detalladas.
Cómo organizar y llevar a cabo una reunión de planificación de sprints
Es posible que esté ejecutando su primera reunión de planificación de sprints o que busque hacer que las reuniones sean más productivas. Es importante saber qué hay que abordar, pero también querrá asegurarse de tener la logística precisa y los suministros a mano.
Para un sprint de un mes, deberá presupuestar alrededor de cuatro horas, una hora de reunión para cada semana de tiempo de sprint. Lo ideal sería que se reúna en persona, pero si hay miembros del equipo que trabajan a distancia, asegúrese de que la tecnología de conferencias funcione bien.
En cuanto a quienes se reúnen en persona, necesita un espacio de trabajo lo suficientemente grande como para que quepan todos. Use un sistema visual como notas adhesivas, una pizarra o una herramienta electrónica. (Use notas adhesivas de diferentes colores para representar los elementos del backlog). Y, dado que el equipo estará allí un tiempo, necesitará bocadillos y café para evitar que las personas se pongan de mal humor.
Descargar la agenda de reuniones de planificación de sprints
Antes de que se ponga en marcha la reunión, publique el objetivo y la velocidad del sprint en la sala de reuniones, para que todos puedan consultarlo.
“Sprint planning should be highly interactive,” says Certified Scrum Trainer Adam Weisbart, who has worked with Oracle, Symantec, Hewlett Packard, and Pfizer. “If you use a software tool to wrangle Scrum artifacts, print out your product backlog items and tape them to the wall instead for this meeting. Have people close their laptops and shut off their phones, and have face-to-face conversations around these physical items. You'll be amazed at how much more life this brings to your meeting and your product,” he adds.
Utilice sus notas adhesivas para documentar los elementos del backlog: cada tipo de elemento va en una nota adhesiva de color diferente. Necesitará al menos tres colores: uno para las historias de usuario, uno para las tareas y otro para los errores. Las notas adhesivas fueron subiendo en la pared o el tablero por orden de prioridad. Querrá recrear este backlog visual para cualquier miembro del equipo que se encuentre a distancia.
Cuando esté listo para comenzar la reunión, iníciela celebrando lo que el equipo logró durante el último sprint para que las cosas comiencen con el pie derecho. A continuación, el Scrum master o el responsable del producto presentarán las historias de los candidatos para el backlog del sprint, incluida cualquiera que haya sobrado del último sprint. Si no se hizo antes de la planificación, las historias deberán medirse y hay algunas formas de hacerlo. Algunos equipos utilizan el tamaño de las camisetas (XS, S, M, M+, L, XL, XXL, XXXL), mientras que otros asignan puntos de la historia mediante la secuencia de Fibonacci (1, 2, 3, 5, 8, 13, 21).
Independientemente del sistema de determinación del tamaño que utilice, los valores relativos son más importantes que aquellos sin procesar. Empiece con dos historias, decida cuál es mayor y, luego, colóquelas en orden. A continuación, tome una tercera historia y decida qué tan grande es en comparación con las otras dos, agréguela al ranking, y así sucesivamente. La suma de los puntos de la historia debe ser menor que la velocidad del equipo. Cualquier elemento del backlog del producto que vaya al backlog de sprints también debe validarse como listo para trabajar en él.
Para el equipo Scrum, analizar cada historia de usuario puede llevar mucho tiempo, y hay una serie de pasos a tener en cuenta. Por un lado, ¿esta historia está actualizada o ha cambiado su definición? ¿Hay información nueva a tener en cuenta? ¿Las estimaciones para la historia siguen siendo válidas?
Scrum Master Andrey Grubin of gaming company PlasmaNet says stories should be evaluated in the context of the sprint goal. “Try to determine from capacity, past velocity, and an overall comfort level within the team whether the proposed stories are achievable within the sprint. Don’t hesitate to consult the product owner if there are any questions or concerns around the proposed stories,” he recommends.
Una vez que se establece la definición de la historia, debe desglosarse en tareas. (Algunas de estas tareas se convertirán en historias de usuario por derecho propio). El equipo decidirá qué conjuntos de habilidades especializadas, si las hay, son necesarios para gestionar estas tareas, y también preguntará cómo probar la historia.
Al igual que con los puntos de la historia y la velocidad, la duración estimada de las tareas debe ser menor que la capacidad del equipo para el sprint. A las tareas y las historias de usuario que se muevan al backlog del sprint se les asignarán fechas de entrega, teniendo en cuenta la cantidad de días laborables y si algún miembro del equipo se va de vacaciones o trabajará a tiempo parcial en el equipo Scrum.
Recuerde que no solo las historias de usuario y sus tareas constituyentes obtienen espacio en el backlog; las correcciones de errores también lo hacen, por lo que absorben parte de la capacidad del equipo Scrum. Pero, ¿cómo se decide cuánto espacio obtiene cada elemento del backlog? Una forma es asignar una proporción fija de capacidad, por ejemplo, el 20%, a la corrección de errores. Otra es relacionar las correcciones de errores con las historias de usuario y luego dimensionarlas y priorizarlas como historias de usuario.
Por último, el equipo Scrum, el Scrum master y el responsable del producto crearán una definición de hecho, incluido algún tipo de métrica de prueba para ayudar a garantizar la calidad de la nueva iteración.
Idealmente, la sesión de planificación de sprints concluirá al cumplirse algunos objetivos. Entre ellos se incluyen los siguientes: hacer que el equipo Scrum se sienta cómodo con el objetivo y, a su vez, que el objetivo se alinee con la visión estratégica y la hoja de ruta del producto; documentar adecuadamente el plan de sprint; crear un diagrama de quemado (un gráfico que traza el trabajo que queda por realizar en comparación con el tiempo restante) para mostrar el progreso del trabajo planificado; y hacer que cada desarrollador del equipo Scrum sepa exactamente en qué va a trabajar una vez que comience el sprint.
Con el backlog del sprint en orden y el objetivo del sprint en mente, el sprint está listo para comenzar.
Planificación de sprints para el marketing Agile
Si bien los desarrolladores de software son los profesionales Agile por excelencia, no son los únicos. Muchos equipos de marketing también adoptan con entusiasmo el enfoque Agile.
Por supuesto, los especialistas en marketing no tienen iteraciones fijas de software para poner en marcha. Lo que sí tienen son proyectos continuos (a menudo a largo plazo) que comprenden una variedad de actividades. Necesitan hacer malabares constantemente con las prioridades a corto y mediano plazo, a menudo con un objetivo claro en mente para cada nuevo conjunto de esfuerzos.
Por lo tanto, para los especialistas en marketing, adoptar métodos Agile es una forma de poder reaccionar de manera coordinada a los cambios en las condiciones del mercado, al tiempo que maximizan la eficiencia y avanzan hacia un objetivo claramente establecido.
En su mayor parte, los sprints y la planificación de sprints para el desarrollo de software y el marketing son muy similares. Sin embargo, hay algunas diferencias significativas.
Por un lado, la duración de los sprints de marketing tiende a ser más corta que la de los sprints de desarrollo de software. El sprint de marketing típico no tarda más de dos semanas, mientras que, en el desarrollo de software, no es raro que los sprints duren uno o dos meses.
En segundo lugar, los cambios en el backlog del sprint durante el transcurso de este último son más comunes en marketing que en desarrollo de software. Esta diferencia se relaciona con las limitaciones más estrictas que suponen las tareas técnicas involucradas en el desarrollo de software, mientras que el marketing parece ser más fluido.
En tercer lugar, es probable que haya especializaciones de mayor alcance en un equipo Scrum de marketing que en uno desarrollo de software, ya que la primera abarca más disciplinas.
Prácticas recomendadas para la planificación de sprints
Los expertos recomiendan algunas prácticas recomendadas para sacar el máximo provecho de su reunión de planificación de sprints.
Al enviar la invitación a la reunión, incluya la agenda. Además, considere la posibilidad de agregar un enlace a las historias de usuario candidatas al backlog del producto, a fin de que los desarrolladores tengan algo de tiempo para leerlas antes de la reunión de sprint.
Cuando el propietario del producto prepara una lista de historias de usuario candidatas al backlog del producto, debe seleccionar un total de historias mayor que la capacidad del equipo Scrum. Esto se debe a que es probable que el scrum master y el equipo Scrum rechacen algunas de ellas o las pospongan para un sprint posterior. Si el responsable del producto ha elegido historias que ocupa menos de la capacidad total del equipo, las que resulten rechazadas darán lugar a una capacidad desperdiciada durante el sprint.
Recuerde que durante la reunión de planificación de sprints, es el Scrum master, no el responsable del producto, quien está a cargo. Al igual que el equipo Scrum, el responsable del producto es más un colaborador de la reunión: los responsables de productos responden a cualquier pregunta que tengan los desarrolladores, explican historias de usuario y negocian los criterios de aceptación bajo la mediación del Scrum master.
También es útil recordarles a todos cómo contribuir de manera más efectiva y lo que pueden y no pueden esperar de otros participantes. El responsable del producto, por ejemplo, toma la iniciativa en la creación del objetivo del sprint y es responsable de definir el alcance del sprint, detallar extensamente cada historia de usuario (completa con una definición de hecho) y priorizar el backlog del producto.
El Scrum master organiza la logística de la reunión y negocia métricas clave, como la velocidad del sprint y la capacidad práctica del equipo. También toma la iniciativa en cuanto a la finalización del backlog del sprint y modera las negociaciones entre el responsable del producto y el equipo Scrum.
“The most common mistake made during sprint planning is not having a clear idea about the team's capacity and, hence, ending up with inconsistent velocity, which, again, induces errors on estimated commitments to be made by the team,” says Parashuram Bellikatti, a specialist in Agile transformations and Director of the Global Agile Centre for Excellence in Bangalore.
El equipo Scrum recopila toda la información que necesita para el próximo sprint y se compromete a un backlog de sprints que sabe que puede lograr razonablemente. También es deber del equipo informar al Scrum master si no va a estar disponible en algún momento durante el sprint.
Una fuente común de disfunción en la planificación de sprints, dice el coach de Agile, Kevin Brunner, es la persona a cargo del backlog. Si no se ha preparado para la reunión o no confía en que el equipo tome decisiones por su cuenta, la mentalidad de este último se vuelve evasiva en lugar de comprometida. Los desarrolladores, en particular, pueden quejarse de que la reunión es una pérdida de tiempo, dado que las historias de usuario no se han concretado o porque su presencia no es necesaria debido a que el Scrum master o el responsable del producto toman todas las decisiones de manera unilateral de todos modos.
A fin de fomentar una dinámica de equipo saludable, Brunner dice que el Scrum master puede seguir tres principios:
-
Visualización: avanzar rápido hasta el final de un sprint con una iteración completada con éxito y trabajar hacia atrás desde allí para negociar los criterios de aceptación y extraer la información necesaria para lograr la iteración completada. La visualización ofrece al equipo un producto final concreto en torno al cual se unen sus esfuerzos.
-
Cultivo: hábito de tomar decisiones en equipo por consenso y escuchar y respetar los aportes de los miembros del equipo. El cultivo también permite al equipo dedicar el tiempo que necesita para tomar decisiones y garantiza la aceptación de los aspectos clave del sprint, como el alcance y las estimaciones de tiempo.
-
Reflexión: la costumbre de mirar hacia atrás de un sprint una vez que ha terminado para preguntar qué salió bien, qué no y cómo se podrían mejorar las cosas.
Una dinámica de equipo saludable, dice el coach de Agile Tony Solomita, se define por tres hábitos: preparar el backlog antes de la reunión de planificación, escuchar lo que todos tienen que decir en el proceso de hacer estimaciones y finalizar el backlog del sprint, y respetar la autoridad del responsable del producto sobre por qué se necesita una función en particular y la autoridad de los desarrolladores sobre cómo se logrará esa función.
Preguntas frecuentes sobre la planificación de sprints
Estas son las preguntas más frecuentes sobre la planificación de sprints:
¿Cómo se gestionan mejor las dependencias entre las tareas? Existen varias formas de mitigar los posibles efectos de la falta de tiempo de las dependencias de las tareas. En primer lugar, la programación de tareas durante la reunión de planificación de sprints puede minimizar o eliminar activamente las dependencias complejas a medida que divide las historias de usuario en tareas. En segundo lugar, puede generar tiempo de búfer entre las tareas dependientes siempre que sea posible. En tercer lugar, el uso de diseños y técnicas de desarrollo flexibles y adaptables, como objetos simulados, puede ayudar a los desarrolladores a hacer frente a los efectos de las dependencias. Y, en cuarto lugar, hacer que los desarrolladores trabajen cerca entre sí puede evitar los problemas relacionados con la dependencia al facilitar la comunicación.
¿A cuántas tareas debe inscribirse cada miembro del equipo? Si usamos el principio climático de ayer, cada miembro del equipo debe inscribirse para abordar no más que la cantidad total de historias que hizo en el último sprint.
¿Cómo se planifican las iteraciones si los tamaños del equipo varían? Si bien los cambios recurrentes en el tamaño del equipo no son ideales, a veces son inevitables. Si el tamaño de un equipo cambia, calcule el número promedio de puntos de la historia abordados por desarrollador en el último sprint y multiplíquelo por la cantidad de desarrolladores que participarán en el próximo sprint para obtener una cifra aproximada para la velocidad del sprint. Es posible que tenga que ajustar aún más esta cifra en función de exactamente quién se va y se une al equipo.
¿Cómo se contabilizan las cuestiones administrativas, como el tiempo dedicado a las reuniones o a la redacción de correos electrónicos? No hay una regla general para calcular las cuestiones administrativas, ya que varía de un equipo a otro. La mayoría de los equipos simplemente asumen que se dedica un tiempo constante a las cuestiones administrativas en cada sprint y que la velocidad del sprint de los sprints anteriores refleja con precisión el tiempo dedicado a ellas.
¿Cómo se debe representar la corrección de errores? Hay un par de formas de abordar esto. Una es tratar los errores como historias de usuario, estimando la cantidad de trabajo involucrado al igual que con otros elementos del backlog del sprint. Otro enfoque más arriesgado es no asignar puntos de la historia a los errores, lo que reduce la velocidad del equipo. El riesgo de este enfoque es que solo funciona si se destina la misma cantidad de trabajo a la corrección de errores en cada iteración. Si la cantidad de trabajo destinado a la corrección de errores varía, la velocidad cambiará drásticamente de un sprint a otro, lo que dificulta mucho la planificación de futuros sprints.
¿Por qué las iteraciones deberían tener siempre la misma longitud? La respuesta, en pocas palabras, es el ritmo y la coherencia. La secuencia de un sprint avanza mucho más sin problemas si sigue un ciclo regular y fácilmente predecible, lo que simplifica en gran medida la planificación de sprints.
¿Cómo se cuenta el tiempo dedicado a las pruebas y la documentación? La forma más sencilla de hacerlo es incluir el tiempo dedicado a las pruebas y la documentación como una tarea separada para cada historia de usuario. Una alternativa es crear un elemento separado en el backlog del sprint para las pruebas y la documentación.
¿Deben revisarse las estimaciones de funciones durante la planificación de iteración? Solo si la estimación original es muy inexacta.
¿Deben revisarse las estimaciones de tareas durante la iteración? No. Una vez que haya completado la planificación de iteración, deje las estimaciones de las tareas tal como están. Por supuesto, es probable que el Scrum master tome nota de por qué el equipo eligió cambiar una tarea, para que pueda reflejarse esta información en la futura planificación de sprints.
¿Deberían todos los equipos trabajar en el mismo cronograma de iteración? Esto depende de la cantidad de equipos Scrum que trabajen en conjunto y de la disponibilidad de personal de apoyo. Si no hubiera restricciones en cuanto a que varios equipos trabajen en iteraciones que comenzaran y terminaran en el mismo horario, la sincronización resultante sería de gran beneficio para la administración. Reduciría el riesgo de que el trabajo de un equipo forzase cambios en el backlog de sprints de otro, ya que los equipos se coordinarían entre sí en cuanto a la planificación de sus sprints. Sin embargo, en la práctica, los equipos Scrum no funcionan de forma aislada, y hay un número limitado de personas que desempeñan funciones de apoyo en varios equipos Scrum y aprecian las iteraciones con fechas de inicio y finalización escalonadas.
Errores comunes en la planificación de sprints y señales de advertencia
Un Scrum master experimentado conoce las señales de advertencia que indican que la planificación de sprints no va tan bien como debería. A continuación, le mostramos lo que hay que tener en cuenta.
Si un equipo no completa repetidamente su backlog de sprints, si introduce continuamente las historias de usuario en el siguiente sprint, eso es una señal de que el grupo está sobrestimando su propia velocidad y reservando demasiadas tareas para sí mismo. Para garantizar que la planificación sea precisa (y realmente útil), el Scrum master deberá ajustar la velocidad del equipo Scrum hacia abajo.
Sin embargo, si las mismas funciones se introducen repetidamente en el siguiente sprint, es probable que el equipo evite deliberadamente abordar ciertas historias de usuario o correcciones de errores. Esta situación merece que se investigue si hay problemas en estas historias de usuario o errores que no se plantean durante la planificación de sprints.
El hecho de que no se complete el backlog del sprint también podría apuntar a un sobrediseño, que es un caso en el que los desarrolladores van más allá de su trabajo y, efectivamente, hacen más de lo necesario. Esto llevará a realizar una revisión de los requisitos de las funciones solicitadas para asegurarse de que el equipo no esté haciendo más esfuerzos de los necesarios.
Qué no hacer: errores típicos en la planificación de sprints
Una sesión de planificación de sprints puede verse saboteada por algunos inconvenientes comunes:
-
El responsable del producto crea el backlog del sprint por su cuenta sin la opinión de los desarrolladores: esto compromete al equipo Scrum con un backlog sobre el que no pudieron opinar. Reduce tanto su compromiso con el proceso de planificación como la probabilidad de que el sprint cumpla con su objetivo establecido.
-
El Scrum Master muestra las historias de usuario candidatas a los desarrolladores por primera vez en la reunión de planificación de sprints: una pérdida innecesaria de tiempo, esto hace que las reuniones de planificación se alarguen mucho más de lo que deberían. Siempre que haya preparado el backlog, es bastante sencillo incluir las historias de usuario candidatas en la agenda de la reunión. Si hay historias de usuario que no cumplen con los criterios INVEST, eso dará lugar a problemas similares.
-
El equipo no llega a un acuerdo en cuanto a la definición de hecho: cuando esto sucede, el equipo llega a un producto incompleto al final de la iteración. Una señal de que este problema puede ser inminente es no tener todos los elementos del backlog del sprint divididos en una serie de tareas manejables.
-
Las subtareas no se estiman con detenimiento: puede detectarse este problema cuando las tareas no parecen haberse estimado con precisión entre sí. (Una tarea muy compleja no es un múltiplo lo suficientemente grande de una tarea simple).
-
El Scrum Master tarda demasiado tiempo en recopilar el Backlog del sprint en una herramienta electrónica: esto puede implicar que el equipo Scrum deba trabajar a ciegas durante los primeros días del sprint, y sea incapaz de ver su verdadero progreso.
-
Las historias de usuario candidatas no se debaten con otras partes interesadas antes de agregarse al backlog del sprint: una vez más, este tipo de error hace que las partes interesadas no conformes soliciten que se cambie el backlog después de que el sprint se ha puesto en marcha. Algunos responsables de productos también pueden hacerlo, incluso después de haber firmado el backlog original del sprint, y esto puede ser muy frustrante. Para algunos equipos Scrum, un cierto grado de cambio en el backlog puede ser prácticamente inevitable. Si este es el caso, hay algunas opciones. Una es aumentar la duración del sprint o subestimar intencionalmente la capacidad del sprint para que haya más margen de acción en caso de que sea necesario agregar trabajo. En el caso de los equipos cuyo trabajo se interrumpe con frecuencia, la mejor solución puede ser simplemente aprender a los golpes y reducir la cantidad de tiempo dedicado a la planificación de sprints, ya que la actividad no puede cumplir realmente con el propósito previsto.
-
El equipo Scrum no detalla las tareas y las subtareas adecuadamente: esto suele ser una señal de que el equipo se aburre de la planificación y solo quiere ponerse en marcha. La falta de detalles pone en riesgo las estimaciones cuando los desarrolladores descubren que las tareas llevaban más tiempo de lo que se había anticipado.
-
Los miembros del equipo son reacios a debatir los pasos: esto priva al resto del equipo de la oportunidad de aprender.
-
El equipo no tiene un Scrum Master que se haga cargo de la planificación: sin un Scrum master para controlar el ritmo de la sesión de planificación, todos buscarán realizarla lo antes posible, lo que puede dar lugar a una sesión de planificación frustrantemente ineficaz o a la falta de detalles clave.
Mejore la planificación de sprints con Smartsheet para la gestión de proyectos
De la administración básica de tareas y de proyectos hasta la administración compleja de recursos y portafolios, Smartsheet lo ayuda a mejorar la colaboración y acelerar el trabajo. Esto lo empodera para lograr más. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas clave y obtenga visibilidad en tiempo real acerca de trabajo gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en menos tiempo. Pruebe Smartsheet gratis hoy mismo.