Hace algunos días nuestro amigo Carlos Jaramillo nos
preguntaba a algunos colegas si estábamos de acuerdo con el legendario Mike
Cohn cuando dice que los sprints deberían planearse con horas y no con puntos. Carlos
se refirió específicamente al artículo Why
Sprints Should Be Planned with Hours, Not Points (Por qué los sprints
deberían planearse con horas, no con puntos).
Como lo dice Cohn al inicio de su artículo, para mí y creo que para
muchos de los que hemos leído su libro Agile Estimating and planning (Estimación
y Planificación Ágil) fue una sorpresa cuando vimos el título ya que sabemos
que él es un gran referente y promotor de los puntos de historia y de su uso. Pero
pasemos a la que fue mi respuesta entonces:
¡Estoy de acuerdo!
En particular, estoy de acuerdo con Mike cuando dice que “los puntos
(de historia) son demasiado imprecisos para ser útiles en el corto plazo”, es
decir, en un sprint de menos de un mes. También me gustaría destacar aquello de
que la velocidad, aunque ligeramente, puede variar de sprint a sprint.
Además de lo que dice Cohn en su artículo algunas otras razones me
llevan a pensar así:
No hay una correlación directa entre puntos de historia y el esfuerzo
de implementación de la historia de usuario. Es decir, no existe tal regla o
ley que señale que si un punto de historia toma H horas implementarse, N
puntos de historia tomarán N x H
horas implementarse (por ejemplo: si la implementación de una historia de un
(1) punto toma 25 horas, entonces la implementación de una historia de 2 puntos
tomará 50 horas, no).
Es probable, eso sí, que al final, después de muchos sprints, el
promedio muestre tendencia hacia esos números, pero nada evita, en el escenario
propuesto, que una historia de 2 puntos le tome al equipo 15 horas y otra
también de 2 puntos le tome 35 horas para implementarla o cualquier otro número,
incluso podríamos tener una historia de 2 puntos cuya implementación tome 10
horas o menos. En cualquier caso, eso apenas sería la tendencia natural.
Además, aun con ritmo sostenido y con entrega de valor constante en
cada sprint, no es lo mismo un equipo en el primer sprint del proyecto que en
el séptimo o en el décimo noveno. No es lo mismo un equipo en abril que en
septiembre o en diciembre. No es lo mismo un equipo si el proyecto va bien
desde varios puntos de vista, como el valor entregado, la calidad, el consumo
de presupuesto, etcétera, o si va regular o mal; y no es lo mismo si el equipo
y aun la organización a la que pertenece han estado mejorando continuamente o
si su crecimiento personal y profesional se ha estancado por acción del
proyecto.
Todos esos factores que acabo de mencionar impactan positiva o
negativamente la motivación del equipo y por consiguiente, el rendimiento de
los miembros del equipo. Lo que finalmente se traduce en número de horas de
esfuerzo necesarias para implementar una historia, o sea, para llevarla de
‘Propuesta’ o ‘En proceso’ a ‘Terminada’.
La misma calidad y el tamaño de las historias de usuario también afectan
de una forma u otra el esfuerzo requerido para su implementación. Me refiero a
la calidad con que son comunicadas al equipo por el Dueño de Producto o por
quien corresponda, así también perturba de manera distinta una historia de 2
puntos que una de 5 o una de 8.
Y todo esto para concluir que en cada Planificación de Sprint se debe
hacer el ejercicio de, precisamente, planear por horas de esfuerzo, de eso se
trata esta ceremonia inicial de Scrum después de todo. La gran diferencia con
la planificación de los métodos tradicionalistas es que no vamos a planear seis
meses de trabajo o un año o dos, no, se trata solo de adelantarnos a lo que va
a pasar en las próximas 2 semanas de trabajo, quizás tres.
Nuestros equipos deben o deberían tener el conocimiento y la
experiencia para decirle al Dueño de Producto y al mismo Scrum Master, al final
de la Planificación, cómo intentarán hacer su trabajo en el sprint que comienza
y eso incluye contarnos el número de horas de esfuerzo que tomará implementar
una historia de usuario en particular. Se trata es de dilucidar cuando nos
tomará el diseño, la programación, las pruebas, la integración, la
documentación y cualquier otra actividad concerniente a la construcción de la
historia. Después de todo, para eso fue que precisamente se conformó el equipo.
¡Pero hay más!
Usamos Puntos de Historia para estimar el backlog y el esfuerzo a
mediano y largo plazo porque son o representan un valor abstracto. También sabemos
que es posible usar otros métodos abstractos de estimación como 'tallas de
camisetas', días ideales, colores, tamaño de los planetas o, incluso como dice
mi amigo Jorge Abad en sus Lecciones
Aprendidas, podemos usar la técnica del ‘ojo de buen cubero’, estimar con Garrapatandamandapispuntos
o con cualquier otra medida cuyas convenciones sean bien conocidas por todo el
equipo.
El precepto fundamental aquí es que todos estos métodos producen estimados
y los estimados, sobre todo en
software, están condenados al error.
Casi 50 años de experiencias después de aquella remota conferencia de la OTAN
en Garmisch en la que de alguna manera se dio vida a la Ingeniería de Software
nos han demostrado eso.
En cualquier caso para estos escenarios de mediano/largo plazo, si un
usuario o cliente está exigiendo estimar en horas un proyecto Ágil, todavía no
ha entendido el enfoque y necesita guía en ese sentido. Las horas son algo
concreto sí, pero solo para lo que he explicado arriba, estimar un sprint corto
o muy corto, de muy pocos días a dos semanas.
Pero igual que con los puntos, estimar con horas no nos eximirá del
error inherente a las estimaciones. Así que en vez de salir corriendo detrás de
las horas, deberíamos enfocarnos en habilitar y empoderar nuestros equipos para
que hagan un mejor trabajo.
----------
¿Ustedes qué creen? ¿Cómo estiman los sprints? Déjenmelo saber en el
foro - la sección de comentarios más abajo.
----------
Más sobre Planificación en:
El artículo de referencia de Mike Cohn lo pueden
encontrar en:
