En la ceremonia de planeamiento de la iteración o Sprint planning se decide qué se construirá durante el ciclo y cómo se llegará a ese resultado.
La reunión suele dividirse en dos partes.
En la primera, el Product Owner expone el objetivo del Sprint y que historias de usuario son necesarias para alcanzar esta meta. Los elementos de la pila de producto (PBI Product Backlog Item) propuestos deben cumplir con la Definición de Listo (DoR – Definition of ready) consensuada entre el PO y el equipo. Es muy recomendable que estas sean ya conocidas por los desarrolladores. Un proceso de refinamiento a conciencia permite llegar a la planning con el conocimiento y la certeza requerida para generar un plan efectivo.
Durante la segunda parte, el equipo estima las user stories seleccionadas, las descompone en tareas y crea un plan de construcción. Primero se realiza una estimación grupal. Es clave explotar la diversidad o diversity score y evitar el sesgo. La manera más habitual de emprender esto es utilizando la técnica de poker planning. Una vez sumadas las estimaciones, si el esfuerzo excede la capacidad real (es fundamental tener en cuenta tanto la velocidad como la disponibilidad para la siguiente iteración), se negocia el alcance con el PO. Tras acordar el objetivo y la porción de la pila de producto que se construirá, el equipo procede a desglosar las historias en tareas técnicas y diseña un plan de acometida. Finalmente, estos elementos se trasladan al Sprint Backlog.
Al finalizar el planeamiento, obtenemos un Sprint Backlog acorde a la capacidad del equipo y la previsión del incremento que cumpla la meta o Sprint Goal.
El inconveniente con mayor frecuencia es enfocar la reunión desde una planificación y cronograma inicial del proyecto. Esto constituye una aproximación por fases y no por incremento de funcionalidad. Esta predicción inevitablemente se desvía durante la ejecución y el dueño de producto presiona al equipo para cumplir los hitos, con la previsión más el atraso incurrido. Los problemas de estimación también son comunes, así como la extensión del evento fuera del tiempo estipulado.
Un apartado adicional merece el desglose de las historias de usuario. Si el equipo adopta una visión predictiva, e intenta crear una secuencia completa, o peor aún, busca asignar tiempos en horas y luego traducirlos a puntos, el plan probablemente fallará. Las investigaciones empíricas han llegado a la conclusión que sólo el 60% de las tareas necesarias para completar los elementos del backlog comprometidos pueden llegar a ser identificados durante la planning. Otras se descubrirán a lo largo de la ejecución (trabajo encontrado o found work), especialmente las relacionadas con dependencias no previstas. Esto no es un fallo o error del planeamiento. Es saludable, sin embargo, llevar un registro o métrica de estos items, con el fin de ser más precisos en la estimación.
Muchas veces ocurre que se estiman las historia y tareas sin tener en cuenta que debe entregar un incremento potencialmente entregable. No se tiene presente la Definición de hecho (DoD), y luego los elementos son entregados a medias, o se acumula deuda técnica. Esto se suele originar en una DoD más allá de las capacidades técnicas del equipo. Es fundamental comprender la criticidad de la DoD, y que esta no es un documento sepultado en el repositorio, o un letrero inocuo pegado en el muro.
Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional.
Para quienes trabajan en el desarrollo y la creación de productos y servicios electrónicos, conocer…
La Manufactura Lean con SMED es una técnica altamente efectiva para mejorar la eficiencia en…
Descubre cómo llevar la agilidad empresarial a nuevas alturas con Scrum@Scale. En este artículo, exploramos…