En ocasiones he visto artículos donde se relaciona el uso de Puntos de Historia con la madurez del equipo o del Scrum Master. Vamos a analizar si esta relación tiene sentido con opiniones reales de personas que los usan y no los usan.
¿Es viable poner en duda la madurez del equipo por usar Puntos de Historia? He leído en alguna ocasión que incluso se ponía en duda la madurez del Scrum Master. Sobretodo por usarlos como métrica. Es decir, se interpretaba que su uso no debería darse en equipos muy maduros. Y de ser así, entonces quizá el Scrum Master era el que tenía que crecer profesionalmente.
Para los que no estáis familiarizados con los Puntos de Historia, son una forma de estimar el esfuerzo, incertidumbre y complejidad de cualquier tipo de tarea a la que se enfrente el equipo en lugar de prever las horas que se van a dedicar a ella, de manera que podamos tener una velocidad de trabajo del equipo.
Esta deducción me hizo pensar si yo estaba de acuerdo o no con esa reflexión. Y al final me dí cuenta que lo mío podía ser sólo una opinión, que lo mejor era preguntar a los equipos que usaban Puntos de Historia y a los que no, para saber qué beneficios tenían o si realmente aquellos que lo hacían desde hacía tiempo, lo hacían por mera rutina. Y digo mera rutina porque estoy de acuerdo en que cómo métrica no aportan valor cuando los equipos aprender que el valor no va de cuántos Puntos de Historia haces en un determinado tiempo.
Las opiniones sobre el uso de los Puntos de Historia
Equipos que usan estimación en sus tareas
Creo que los puntos de historia fueron uno de los aspectos clave para que el equipo cambiara de mentalidad y nos permitiera avanzar en el desarrollo de una cultura ágil. Los puntos de historia consiguieron que el equipo olvidara las horas y las estimaciones por tiempo y pasáramos a pensar en complejidad. Todos se sienten más implicados, se liberan de la presión de las horas, permite un margen de desviación por el que unas tareas se ven compensadas con otras, nos permite saber si una tarea es demasiado compleja para abordarla en un sprint…
Product owner
Dejar de medir en horas y empezar a hacerlo en puntos de historia supone un cambio de mentalidad, en el que el acompañamiento del Scrum Master es clave. Una vez te acostumbras, creo que el equipo se quita presión respecto a los tiempos de entrega y lo que tarda un miembro u otro en hacer una misma tarea. Personalmente, aunque haya gente que le cuesta más este proceso al ser una medición un poco abstracta, me parece una estimación mucho más acertada.
Desarrollador C#
Desde mi punto de vista es útil por varios motivos; te ayuda a controlar la cantidad de tareas que asumes por sprint una vez sabes la velocidad de desarrollo. Pero por otro lado también sirve cuando puntúas para ver si el resto del equipo ve la misma complejidad o no que tu.
Desarrolador Java
Tengo que reconocer que trabajar con puntos de historia al principio rompe los esquemas. Estamos acostumbrados a trabajar con el concepto del tiempo, que es lo que nos suelen pedir los responsables y de pronto tienes que darle una vuelta mental y cambiar “el idioma”. Podemos trabajar igualmente en un marco de tiempo, pero ya estamos dejando de hacerlo de forma directa. Una vez saltada la primera barrera te das cuenta de que es más cómodo para el equipo el ser consciente del esfuerzo que conlleva cada tarea. Como nota final, pero no menos importante, hacer hincapié en que tener un buen Scrum Master que te acompañe en la transición y te ayude con las dudas durante el proceso de re-aprendizaje es esencial.
Desarrolladora Cobol
Me da una guía de lo que pueda asumir un equipo en futuros sprints. Si necesito saber el % de avance de una épica, o para trabajar con las versiones de release, me va mejor por puntos que por número de tareas, pues nos es más complicado detectar tareas que son muy grandes si no usamos un tipo de estimación como este.
Product Owner
Equipos que NO usan estimación en sus tareas
Nos gusta usarlos sólo en los refinamientos, para saber si vamos todos alineados. Además, esa alineación ayuda a compartir conocimiento. Tenemos como norma no crear historias que puedan costar más de un cierto esfuerzo, así que más o menos todas tienen el mismo tamaño y no lo informamos. Trabajamos en Kanban y el tamaño unificado nos ayuda a mantener el flujo de entrega, que es lo que medimos.
Desarrollador Java
No usamos ningún tipo de estimación, simplemente vamos creando tareas y realizándolas en modo Kanban. Controlamos mucho el hecho de limitar el trabajo en progreso y procuramos hacer mucho pull para mantener un flujo constante. En el equipo somos pocos y nos entendemos bien a la hora de dividir tareas para que no sean muy grandes.
Desarrollador Java
Conclusiones
Desafortunadamente no he encontrado más opiniones de equipo que no usen estimación por puntos de historia, u otros métodos de estimación.
Con estos testigos me atrevería a decir que no pienso que unos sean más o menos maduros que otros. Cada equipo tiene que trabajar como mejor le vaya para medir su velocidad y ver dónde pueden mejorar.
Dejemos de valorar la madurez de los equipos por cómo trabajan y cómo miden sus cosas. Empecemos a medir el valor que entregan y cómo llevan su auto-crítica para mejorar constantemente. Para mí un equipo es maduro cuando:
- sabe porqué entrega lo que está entregando y qué implicación comporta al negocio
- recapacita para mejorar
- usa el feedback para aprender
- hay confianza entre ellos y con su relación exterior
- es completamente transparente
- sabe que cualquier tipo de medición es para prever de forma empírica, no para compararse con nadie.
¿Cuál es vuestra opinión al respecto? Sea la que sea será bienvenida, podéis dejarla como comentario a continuación ??.