Scrum Framework

Concepto

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.

Reglas

  • Duración máxima de 8 horas en Sprints de 4 semanas. Tiempo proporcional para ciclos más cortos
  • Participantes Dueño de producto, Scrum Master y equipo de desarrollo obligatorios

Elementos necesarios

  • Sala de reuniones (de preferencia el mismo sitio donde se desarrolla)
  • Pila de iteración (Sprint backlog)
  • Velocidad conocida del equipo
  • Capacidad del equipo
  • Definición de Listo (DoR Definition of ready)
  • Definición de Hecho (DoD Definition of done)
  • Si el equipo es distribuído, las herramientas telemáticas necesarias

Desarrollo

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.

Resultado

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.

Problemas habituales

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.

Licencia de Creative Commons
Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional.

Jorge Hernández

Agile Coach con experiencia en implantación y adopción de marcos de trabajo ágiles Transmito a las organizaciones las habilidades y herramientas necesarias para adoptar nuevas formas de trabajo basadas en la mejora continua y el aprendizaje. Ingeniero informático, trainer y Scrum Master