Cuando comenzamos a introducirnos en la práctica de Scrum muchos nos preguntamos por qué es mejor hacer las estimaciones basadas en puntos que hacerlas basadas en horas. No existe acaso una relación directa entre ambas medidas?
La gran mayoría de los expertos en el tema coinciden en que la respuesta a la segunda pregunta es NO.
Los puntos en Scrum son un reflejo del riesgo y la complejidad que cada miembro del equipo puede percibir sobre una historia, mientras que las horas asignadas a esa misma historia son una estimación absoluta, basada en forma casi exclusiva, en la experiencia previa.
La estimación con puntos es lo que usualmente se denomina "estimación relativa" y tiene como principal objetivo el agrupar cosas de similar medida en vez de darles a cada una una magnitud categórica y terminante.
Una de las ventajas de dimensionar las historias a través de puntaje es que nos permite mirarlas desde 3 ángulos distintos:
El medir una historia con puntos permite encarar un aspecto diferente de la estimación: cuando preguntamos "cuántas horas va a llevar una historia?" el número dado como respuesta está pensado, en la gran mayoría de los casos, sólo según la experiencia anterior. En cambio, el pensar una medida en puntos permite relativizar los 3 aspectos mencionados antes y compararlos contra las estimaciones hechas para otras historias dando la posibilidad de ajustar y afinar dichas estimaciones a cada paso. Estos ajustes son normales cuando recién comenzamos a usar esta forma de "medir".
Otro aspecto positivo es que esta técnica permite a todo el equipo estar involucrado. La decisión de qué valor darle a una tarea ya no depende exclusivamente de quien va a desarrollarla sino que todos los participantes deben aportar su punto de vista respecto de los 3 aspectos enumerados. Las distintas visiones al estimar una historia permiten a los miembros entender cuestiones que podrían no ser tenidas en cuenta en forma individual.
Algunos opinan además que las estimaciones por puntos no llevan la "carga psicologica" que tiene la estimación por horas, con el impacto negativo que puede llegar a provocar en alguien que excede el tiempo previamente estimado para terminar una tarea.
Al final de la estimación se suman los puntos de las historias para tener una dimensión total del sprint. Después de completar un par de sprints se podrá tener una idea más certera de cuántos puntos puede hacer el equipo en cada iteración, lo que determina la "velocidad" de ese equipo.
A partir de esto las estimaciones por puntos se harán cada vez más naturales y se irá mejorando la técnica hasta llegar a dejar de pensar en el reloj al momento de medir las entregas en cada intervalo.
Para leer más:
Story points vs. development hours
Sobre Ratas, elefantes y timeboxing
Twittear Seguir a @3p_ar
La gran mayoría de los expertos en el tema coinciden en que la respuesta a la segunda pregunta es NO.
La estimación con puntos es lo que usualmente se denomina "estimación relativa" y tiene como principal objetivo el agrupar cosas de similar medida en vez de darles a cada una una magnitud categórica y terminante.
Una de las ventajas de dimensionar las historias a través de puntaje es que nos permite mirarlas desde 3 ángulos distintos:
- complejidad
- esfuerzo
- duda - representada por las cosas que no sabemos si van a poder ser hechas o que no sabemos cómo van a ser encaradas porque incluyen factores con cierto grado de incertidumbre -
El medir una historia con puntos permite encarar un aspecto diferente de la estimación: cuando preguntamos "cuántas horas va a llevar una historia?" el número dado como respuesta está pensado, en la gran mayoría de los casos, sólo según la experiencia anterior. En cambio, el pensar una medida en puntos permite relativizar los 3 aspectos mencionados antes y compararlos contra las estimaciones hechas para otras historias dando la posibilidad de ajustar y afinar dichas estimaciones a cada paso. Estos ajustes son normales cuando recién comenzamos a usar esta forma de "medir".
Otro aspecto positivo es que esta técnica permite a todo el equipo estar involucrado. La decisión de qué valor darle a una tarea ya no depende exclusivamente de quien va a desarrollarla sino que todos los participantes deben aportar su punto de vista respecto de los 3 aspectos enumerados. Las distintas visiones al estimar una historia permiten a los miembros entender cuestiones que podrían no ser tenidas en cuenta en forma individual.
Algunos opinan además que las estimaciones por puntos no llevan la "carga psicologica" que tiene la estimación por horas, con el impacto negativo que puede llegar a provocar en alguien que excede el tiempo previamente estimado para terminar una tarea.
Una forma sencilla de comenzar a pensar en puntos
 |
| Planning Poker cards |
La forma de estimar es uno de los cambios más grandes al que tenemos que hacer frente cuando empezamos con la práctica de Scrum y puede ser muy frustrante no encontrar la manera de hacer ese "click" de dejar de pensar en "tiempo" para pasar a pensar en "puntaje". Cuando comenzamos a implementar esta técnica en Tercer Planeta, alguien nos recomendó arrancar con estos pasos, y realmente nos fue muy útil:
- Elegir un par de historias de nivel medio en complejidad, historias "conocidas" o "repetidas" en cualquier tipo de aplicación.
- Asignarles puntos de las cartas (la serie de Fibonacci reflejada en las cartas de Planning Poker)
- Estas historias elegidas pasan a ser entonces "historias de referencia" para puntuar el resto de las historias
- Luego, asignar puntos al resto de las historias, basándonos en puntajes relativos a los puntos asignados a las "historias de referencia": las historias que parezcan más complejas o más grandes que las de referencia recibirán puntajes más altos.
Al final de la estimación se suman los puntos de las historias para tener una dimensión total del sprint. Después de completar un par de sprints se podrá tener una idea más certera de cuántos puntos puede hacer el equipo en cada iteración, lo que determina la "velocidad" de ese equipo.
A partir de esto las estimaciones por puntos se harán cada vez más naturales y se irá mejorando la técnica hasta llegar a dejar de pensar en el reloj al momento de medir las entregas en cada intervalo.
Para leer más:
Story points vs. development hours
Sobre Ratas, elefantes y timeboxing
Twittear Seguir a @3p_ar
