Cómo se estima en Scrum

¿Cómo se estima en Scrum? Mira como se hace:

¿Te ha sucedido que a lo largo de un proyecto  Project Managers estiman de una forma errónea comprometiendo entregables antes de tiempo? En Scrum sucede algo similar, aunque con Scrum no es una persona sino todo el equipo quienes estiman los entregables de un proyecto, también es cierto que esto puede llegar a ser o no mucho más difícil de lo que parece.

Aunque la estimación en Scrum se realiza mediante el Scrum Team quienes han tenido experiencia previa del tiempo que requiere cada tar0ea, en muchas de las ocasiones y sobre todo cuando son equipos inmaduros estimar tareas es realmente difícil. Sabiendo esto, ¿Cómo podemos obtener las mejores estimaciones de nuestras Historias de Usuario?

Para saber ¿Cómo redactar buenas Historias de Usuario da click ahora?

Bueno, la estimación es definitivamente difícil. Para lograr buenas estimaciones se requiere de experiencia del Scrum Team, pero seamos sinceros, esta experiencia requiere de tiempo valioso que no podemos desaprovechar sobre todo en un proyecto ágil. Por ello en Kaizenia Institute tenemos algunas recomendaciones que tu como Scrum Master o como participe de un proyecto puedes aplicar en el momento de realizar estimaciones.

1. Planing Poker

Si ya has tomado algún curso como Scrum Master seguramente visualizaste lo que es el Planing Póker, un método basado en la serie de Fibonacci, básicamente es un juego creado por James Grening que consiste en el levantamiento de cartas por cada participante.

Dentro de la metodología Scrum, el encargado de realizar esta reunión es el Scrum Master, quién es responsable de otorgar un paquete de ocho cartas a cada participante, con números del  1, 2, 3, 5, 8, 13, 21 y 36.

De esta forma se toma el número 1 como un esfuerzo mínimo que puede involucrar 3 horas de trabajo; hasta la tarjeta más grande que en este caso sería el numero 36 colocando como una semana de esfuerzo. Esta temporalidad la define el Scrum Master con base a su experiencia en proyectos, por lo cual antes de llevar a cabo el Planing Póker se debe realizar una tabla similar a la que se muestra a continuación.

Una vez que ambos argumentaron el porqué de sus votos el Scrum Master procede a otra técnica llamada Point Five, una técnica rápida de votación sobre cada argumento, gana quien más votos tenga.Una vez obteniendo esta estimación de tiempo el Scrum Master procede con cada tarea, es decir, cuando se realiza una página web el Scrum Product Owner define la tarea de crear el Login como primordial, cuando se hace esta reunión el Scrum Master saca esta tarea y el equipo tiene 8 cartas para sacar de acuerdo a su experiencia en la tardanza de esa tarea, si el equipo vota muy similar se toman en cuenta la carta que más veces salió, si el equipo vota muy disparejo y una persona vota 1 que en este caso serían 3 horas y otra persona vota 21 que en este caso serían 6 días, el Scrum Master procede a preguntar a estas personas que votaron 1 y 21 el porqué de su estimación.

2. Point Five

El Point Five es un mecanismo sencillo y rápido para lograr el consenso en un grupo, sirve para resolver disputas o empates también dentro del Planing Poker o en cualquier otra reunión de Scrum (Time Boxing). Tras un debate inicial sobre una propuesta o una decisión pendiente se pide a los miembros del Scrum Team que voten en una escala del 1 al 5 usando sus dedos.

De esta forma rápida y sencilla se hace un consenso de reflexión por parte del Scrum Team y se les pide que argumenten el porqué de su votación, de acuerdo a su votación dentro de la metodología Scrum depende del número de dedos que involucre, el número de dedos que se utiliza para la votación indica el nivel de acuerdo y el deseo para el debate:

  1. Un dedo: No estoy de acuerdo con la conclusión del grupo y tengo grandes inquietudes.
  2. Dos dedos: No estoy de acuerdo con la conclusión del grupo y me gustaría hablar sobre algunos asuntos menores.
  3. Tres dedos: No estoy seguro y me gustaría sumarme a la conclusión de consenso del grupo.
  4. Cuatro dedos: Estoy de acuerdo con la conclusión del grupo y me gustaría discutir algunos asuntos menores.

Cinco dedos: Estoy totalmente de acuerdo con la conclusión del grupo

3. Elementos de acumulación de cubos por tamaño de la historia

Es difícil de estimar y extremadamente difícil de estimar con precisión. Entonces es bueno hacer la estimación más fácil al no requerir que los equipos pongan valores exactos en cada elemento que estiman. Un equipo puede elegir estimar usando 1, 2, 4, 8 y 16. Otro equipo puede usar la secuencia de Fibonacci de 1, 2, 3, 5, 8 y 13, que es más preferencia.

Los números en estas secuencias se pueden ver como cubos. Usando la última secuencia, tenemos un cubo de 5 puntos y un cubo de 8 puntos. El equipo no tiene que estimar con precisión el tiempo que tardará un elemento acumulado del producto. En su lugar, el equipo solo tiene que poner el elemento de la cartera de pedidos del producto en el cubo correcto: “¿Este elemento pertenece al cubo de 5 puntos o al cubo de 8 puntos?” (O tal vez algún otro cubo).

Esto ahorra tiempo al estimar reuniones al eliminar la presión para que sea perfecto. Al eliminar la presión, también ayuda a los miembros del equipo a participar en el proceso.

4. Estimación de costos*

La estimación de costos se puede lograr mediante el uso de unidades relativas (por ejemplo: las estimaciones de esfuerzo) en lugar de unidades absolutas (los costos reales incurridos). A fin de estimar los costos para implementar una historia de usuario, el equipo Scrum puede utilizar puntos de historia. Cuando se da este caso, el costo estimado de cada tarea se representará en forma de puntos de historia en vez de unidades monetarias. A fin de lograrlo satisfactoriamente, el equipo Scrum debe identificar una historia de usuario de referencia con la que se puedan identificar todos los miembros del equipo. Una vez identificada dicha base, todas las estimaciones de costo de las historias de usuario deben compararse con la base.

Dichos cálculos permanecen fijos durante el sprint debido a que los equipos no deben cambiar durante un sprint.

*Tomado del SBOK 6ta edición.

 

Otras formas de estimar

Wideband Delphi

Es una técnica utilizada para determinar la cantidad de trabajo y el tiempo que tardara en completarse. Los individuos en el equipo proporcionan estimaciones anónimas para cada característica y las estimaciones iniciales se trazan en una gráfica. Posteriormente, el equipo analiza los factores que influyeron en sus estimaciones y proceden a una segunda ronda de estimación. Este proceso se repite hasta que las estimaciones de los individuos quedan cerca una de la otra y se puede llegar a un consenso para la estimación final.

También es importante destacar que la opinión individual recopilada por un mecanismo, lo cual evita el pensamiento en grupo. Después, las opiniones individuales se utilizan para una decisión colectiva.

¿Quieres aprender más de como estimar en Scrum?

Mira el siguiente video:

Además te regalamos tus propias Scrum Cards

Descárgalas ahora e imprímelas en tu lugar de trabajo. Planea y estima de forma increíble con estas Scrum Cards de KZI-Kaizenia

Sigue aprendiendo más sobre Scrum Master