Continúo esta pequeña historia personal sobre un tema al que todos nos hemos enfrentado que son las estimaciones. Tras declararme en rebeldía, me refugié en el movimiento #noestimates pero duré poco sin estimar. Ahora os cuento cómo termina este pequeño viaje intelectual.
Si tienes dudas de algo de Scrum, ojo a la perogrullada que voy a saltar, ¡mira en la guía!. Me sorprende que hay gente que no ha releído la guía en meses o años. Yo por lo menos, cada poco tiempo, me surge alguna duda o debate y me toca consultar en detalle.
Tabla de contenido
Busquemos “estimar” en la guía:
- Sprint Planning
El trabajo podría ser de tamaño o esfuerzo estimado variables. - Product Backlog
Los elementos del Product Backlog tienen como atributos la descripción, la ordenación, la estimación y el valor. - Refinamiento
El refinamiento (refinement) del Producto Backlog es el acto de añadir detalle, estimaciones y orden a los elementos del Producto Backlog. - Se realizan estimaciones más precisas basándose en la mayor claridad y detalle; cuanto más bajo es el orden, menor es el detalle.
- El Equipo de Desarrollo es el responsable de proporcionar todas las estimaciones. El Dueño de Producto podría influenciar al Equipo ayudándoles a entender y seleccionar soluciones de compromiso, pero las personas que harán el trabajo son las que hacen la estimación final.
- Sprint Backlog
A medida que el trabajo se ejecuta o se completa, se va actualizando la estimación de trabajo restante.
La primera conclusión es que estimar es claramente algo propio de Scrum. Me sorprendió que con lo abierta que es la definición de PBI, (si no me equivoco con la idea de que un PBI sea un elemento que genere conversación entre el PO y el DT) las estimaciones sean algo obligado dentro de cada PBI.
Ahora me falta saber porqué y para qué son tan importantes así que seguí buscando y encontré varios post y una conversación que recomiendo leer: what-scrum-says-about-estimates, faking-it-estimates-and-metrics-scrum, myth-9-story-points-are-required-scrum y Purpose estimating PBIs
Reflexiones, conclusiones y citas
-
- Las estimaciones dan valor al PO.
El PO cuando tiene que alinear prioridades y ordenar el backlog estudia esa relación de coste/valor. Sin la estimación, sólo tendríamos el valor, y no sería posible para el PO saber cúal es esa opción ideal a priorizar. - Las estimaciones dan valor al equipo Scrum:
El ritmo del equipo debería ser sostenible y buscamos dar predictibilidad sobre nuestro trabajo por tanto las estimaciones nos ayudan a poder pronosticar el futuro ofreciendo incluso un roadmap o una velocidad. Algo que será muy útil para el PO y los Stakeholders. Sin estimación nos quedamos sin dar visibilidad hacia fuera del equipo rompiendo la transparencia sobre nuestro trabajo. - Las estimaciones dan valor al DT:
Estimar provoca ese debate técnico entre el DT para comprender qué y cómo van a terminar ese PBI. Sin estimaciones, se puede perder esa conversación que termina en el entendimiento mutuo, y nos llevará a no planificar bien el sprint incumpliendo el sprint goal. - Personas por encima de procesos.
Creo que a veces se abusa de cosas como el Planning Poker, y se tiende a usar como herramienta/proceso que dada una tarea nos devuelve un valor de puntos de historia para la misma; olvidando que el objetivo es que el DT hable sobre qué entiende que hay que hacer en cada PBI, ya que un 5 para dos personas puede ser que venga de entendimientos muy diferentes. - “La entrega de funciones de trabajo, temprano y con frecuencia, es la única medida de progreso que puede ser verdaderamente satisfactoria a cualquier escala. Sin embargo, lo que una estimación puede hacer razonablemente es dar transparencia a un equipo sobre un evento complejo”
- “Desafortunadamente, una vez que los PBIS tienen estimaciones individuales, puede causar que los objetivos se devalúen y el Sprint Planning degenere en más de un ejercicio de acotación. Este antipatrón es muy común en organizaciones menos maduras. Por lo tanto, la ambición de «entregar puntos», en lugar de incrementos que cumplan los objetivos, está tan extendida y necesita una protección especial en contra”.
- Las estimaciones dan valor al PO.
Final
«Estimar es a menudo útil, las estimaciones a menudo no lo son” Esther Derby
Y una vez leído todo esto, yo por lo menos, creo que entiendo mucho mejor por qué necesitamos estimar, cuál es el valor concreto que aporta a cada rol y para qué se debe hacer.
¿Qué pensáis vosotros? ¿Sois fieles a Scrum o preferís el #noestimates? ¿Estimar con número de PBIS es un método de estimación o es parte del movimiento #noestimates?
Entradas relacionadas
¿Entregamos valor? ¡Tengo evidencias! Parte 1!5 (2)
Comentarios recientes