Este documento presenta una introducción a la estimación y planeamiento ágil. Explica por qué la planificación tradicional falla, como priorizar el valor del cliente, estimar tamaños de trabajo con story points en vez de horas, y usar técnicas como estimación análoga y poker planning. También cubre cómo planificar sprints y releases de manera iterativa, monitorear el progreso, y reconocer la incertidumbre como parte natural del proceso de desarrollo.

1. Estimación y Planeamiento

Sebastián Diéguez
Lider Técnico – Scrum Coach

2. Agenda

Porque la planificación Falla?

Porque la planificación sirve?

Una aproximación Agil

Estmar tamaño con Story Points

Tecnicas de Estimación

Re-Estimando

Sprint Planning

Release Planning

3. Porque Falla?

Se planifican actividades

El multitasking causa demoras

Las Features no se hacen por prioridad

Ignoramos lo incierto

Las estimaciones se convierten en compromisos

4. Porque Sirve?

Reduce el riesgo

Reduce la incertidumbre

Ayuda a mejorar la toma de decisiones

Establece confianza de lo que se hace

Junta información de otra manera dispersa

5. Porque Falla?

6. Una aproximación ágil

TODO el equipo

Time-boxing (limitación de tiempo)

Equipos auto gestionados

Simular roles no presentes

El cliente presente

Planear para el cambio

7. Estimando en Story Points

Hay problemas cuando se entima en:

Duración

Costo

Complejidad

Hay que deshacerse de conceptos relacionados
con el tiempo

8. Técnicas de estimación

Estimación análoga (relativa)

”Esta Story es parecida a esta otra...”

Calculamos mejor el tamaño relativo que el
absoluto

Poker Planning

Se establece un valor por concenso

Se estima ”en iteraciones” de concensos

Se usa la serie de Fibonacci para establecer
diferencias mas significativas entre participantes

9. Re-Estimación

Muchos piensan que esta mal

Conocimiento a priori y a posteriori

¿Cuándo re-estimar?

10. Sprint Planning

El equipo entero se reune al principio de la
iteración

Puede incluir a las gallinas (Product Owner,
Cliente)

Se (re)estima cada item

Se priorizan los items

Se usa la valocidad para meter la cantidad de
items en el Sprint

11. Sprint Planning

Datos históricos

Del Sprint anterior

Promedio de Sprints anteriores

Solo válido cuando no cambia mucho:

Tecnología

Dominio

Product Owner

Herramientas

Tamaño y conformación del equipo

12. Sprint Planning

Pronóstico

Estimar las horas ideales:

Considerar: reuniones, diarias, planeamiento,
retrospectiva

Considerar: curvas de aprendizaje

Considerar: entrenamientos

Considerar: vacaciones, feriados, tiempo flexible

Determinar horas ideales por Sprint

Expandir User Stories en Tareas

Como bloques LEGO, deben entrar perfectamente

13. Release Planning

Igual que la Sprint Planning pero para todo el
release

Los Items son mas gruesos

Dos técnicas

Dada una fecha de entrega, continuar llenando
hasta que la fecha se cumpla

Dado el contenido, agregar sprints hasta que este
completo

Las fechas pueden ser anteriores si se agrega

14. Estimar Velocidad

Usando datos históricos

Sprint de prueba

Hacer Pronósticos

15. Monitoreando un Sprint

El TaskBoard

Burndown Charts

Esfuerzo consumido

Velocidad Individual

16. Porque la estimación ?

Re-Planeamiento es parte del ciclo

Estimacion de Tamaño y duracion, separadas

Planeamiento a diferentes niveles

Los planes son por características, no esfuerzo

Stories chicas mantienen el flujo de trabajo

Multitasking es eliminado en cada iteracion

El Tracking es a nivel equipo, no por miembro

La incertidumbre es reconocida y se planea para

17. Preguntas?

18. Gracias....

Sebastián Diéguez
Lider Técnico – Scrum Coach