Las ventajas que te ofrece Microsoft Azure y el mundo.NET

Scrum Poker: evaluando el esfuerzo de tareas

Volviendo a la formación en ALM, he vuelto a releer el punto en el que se hablaba de la «evaluación de esfuerzo de tareas», donde se explican ciertas cosas muy interesantes entorno a los Story Points, como la técnica del Planning Poker, la cual ya hemos comenzado a implementar en la planificación de algún proyecto.

En el siguiente artículo sobre los Story Points veremos cómo a pesar de no aparecer como una medida del Core sobre ninguna metodología ágil, ni ser imprescindible, podremos sacar gran partido trabajando con ellos.

Story Points

¿Qué son los Story Points?

Los Story Points son un sistema alternativo para la medida del esfuerzo que requerirá una historia de usuario en concreto. La cantidad/carga de trabajo, grado de conocimiento/experiencia entorno a la tarea y complejidad de la misma, se postulan como principales factores a tener en cuenta a loa hora de evaluar el esfuerzo que requerirá cada historia de usuario.

¿Qué debemos conocer sobre los Story Points?

  • Es una valoración propia y particular del equipo que vaya a abordar la tarea. Es decir, se trata de una valoración subjetiva que no será, necesariamente, la misma para dos equipos distintos, y por lo tanto no equiparable.
  • Cuando trabajamos con Story Points nos atenemos a una medida arbitraria, no supeditada al tiempo, meramente consiste en una estimación de la dificultad del trabajo.
  • El punto anterior no exime de que, de manera aproximada, preestablezcamos relación reglada entre número de jornadas y la dificultad supuesta.

¿Cuál es su objetivo?

“Obtener un consenso en la previsión de coste. Esta es la mejor manera de obtener una estimación.”

Anthony Borton ALM MVP.

El principal objetivo es obtener de la mejor manera posible, la estimación del coste entorno a cada tarea. Ésta técnica defiende que la forma más precisa y productiva de lograr esta estimación, es hacerlo bajo consenso del equipo, justamente lo que nos facilita trabajar con Story Points.

Planning Poker

¿Qué es el Planning Poker?

Existiendo distintas metodologías para el cálculo de los Story Points, se posiciona como más recurrente (y divertida) la de Planning Poker

El Planning Poker es una práctica ágil de estimación de software de naturaleza gamificada. Este método nace con el afán de que todo el equipo pueda participar y llegar a consenso en la estimación de una tarea, evitando alargar posibles discusiones, propias de un grupo de personas tiene que llegar a un acuerdo, y haciendo amena y divertida una actividad que a priori puede resultar aburrida.

El sistema utiliza un rango de valoración basado en la secuencia Fibonacci 0, 1, 1 , 2, 3, 5, 8, 13, 21, 34, 55, 89.

A partir de esta secuencia, se estipula una adaptación que presenta las siguientes opciones: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ∞, (coffee).

0 Recurrimos al 0, cuando se trate de una tarea que podremos resolver gracias a una funcionalidad out of the box.

Aplicamos el infinito cuando se considera que el esfuerzo para realizar la tarea es superior a las opciones anteriores, en cuyo caso habría que descomponer la tarea en varias.

? El interrogante lo mostraremos cuando nuestra respuesta sea “No estoy seguro..”  Se recomienda que si en 30 segundos no puedes determinar qué esfuerzo requiere esa tarea, no deberías mostrar ninguna carta, puesto que careces de la experiencia/criterio para poder evaluar.

Café Entorno al café existen dos teorías posibles:

a) “Necesito un descanso”

b) El coste de la tarea resta el mismo tiempo que el de tomar un café.

¿Cómo podemos trabajar Planning Poker mediante TFS?

Para poder trabajar con Planning Poker en Visual Studio Team Services, haremos uso de la herramienta Estimate, extensión disponible en Visual Studio Team Services Extensions.

¿Cómo se desarrolla el Planning Poker?

La valoración mediante Planning Poker se realizará durante una reunión que convoque al equipo al completo, donde por cada historia de usuario, cada uno mostrará simultáneamente el valor que considere al resto de los compañeros. Originalmente se trabajaba con una baraja de cartas física, mientras que, en nuestro caso, ya transformados digitalmente 😉 hacemos uso de nuestra herramienta Estimate desde TFS.

En los siguientes puntos detallamos paso por paso como desarrollamos una estimación mediante Planning Poker:

  1.  Elmoderador(TL en nuestro caso) anuncia una historia de usuario a estimar, explicando en qué consistirá y resolviendo las posibles dudas que pueda surgir al equipo. Los miembros del equipo también pueden intervenir y realizar apuntes de cómo se realizar el trabajo.
  2.  ElTLrealiza un resumen descriptivo de lo que se ha explicado entorno a las tareas de la historia, tomando anotaciones cuando se requiera.
  3.  Cada miembro del equipo selecciona un valor con la estimación que considere más acertada para la tarea a realizar desde la opción Estimar sobre la historia de usuario (escogería una carta de su mazo en el caso de trabajar con baraja), sin comunicarlo al resto de compañeros. Este paso es esencial, ya que permite a cada persona elegir el valor que considera más adecuado, sin estar influenciada por el resto de compañeros.

  1. Una vez los miembros del equipo hayan elegido un valor, el TL podrá ver (levantar las cartas) y conocer las estimaciones emitidas por éstos. Recalquemos que estas valoraciones no serán visualizables entre los compañeros, y que el administrador podrá verlas una vez todos hayan valorado, haciendo click en Revelar; mostrando además el resultado de la valoración media.

Captura 1. Tras hacer click en Revelar vemos cómo se muestran todas las valoraciones, además del cálculo de la media obtenida

  1. En caso de existir estimaciones máximas y mínimas muy distanciadas, los miembros autores de estas valoraciones tan alejadas del resto explicarán el porqué de su valoración; cuando es más alta (comentan algún problema en el que nadie más ha pensado o el resto no haya tenido en suficiente consideración) o más baja (se da cuando conocen mejor la tarea, tienen experiencia al respecto, o disponen de recursos para resolverla). El resto del equipo también puede participar en el debate, para aclarar dudas o resolver algún punto de la discusión.

*   Sobre este punto hay controversia, existiendo teorías que recomiendan directamente, descartar las estimaciones más bajas y más altas, quedándose con la estimación media o más repetida. En nuestro caso no aplicamos esta práctica, partiendo de la premisa que explica que en Planning Poker no hay democracia, y que siempre se debe llegar a un consenso. Entendiendo así, que elegir la estimación de la mayoría sería un error.

  1. ElTL buscará un consenso, entre todos, sin necesidad de volver a jugar y determinará un valor para asignarle a la historia.

Captura 2. La media resultante será un valor referencial y editable por el TL

  1. Finalmente se registra la valoración designada, pudiendo continuar con la valoración del resto de historias.

Captura 3. El TL cerrará la sesión de valoración, registrando la valoración de esfuerzo consensuada

Captura 4. Por último, vemos como se presenta el esfuerzo designado desde el Backlog

Pros y contras

Como principal ventaja, aparte de lograr valores estimativos de esfuerzo que se ajustarán de manera más veraz al requerido finalmente, el hecho de trabajar haciendo uso de esta metodología, permite al equipo conocer los recursos que tiene a su alcance, y que quizás no conocía.

Siempre puede darse el caso en que un miembro del equipo justifique una previsión de esfuerzo más liviana que la del resto entorno a una tarea, por contar con el recurso/herramienta/conocimiento/experiencia para realizar esa tarea con menos esfuerzo…

Acerca de esto, debemos valorar la importancia de conocer los puntos fuertes de cada componente del grupo, ya que además de hacer más eficiente al equipo (permitiendo lograr una mejor estimación de las tareas), influirá positivamente a nivel individual, puesto que todo el equipo sabrá a quién recurrir para empaparse de esos nuevos recursos, y así sacar el mayor partido posible.

A la hora de hablar de desventajas, apuntaremos que en el caso de no ser exquisitos con la valoración que apliquemos, no respetando el rango de valoración o bien estimando algo con una puntuación media (por aquello de «no saber qué puntuar”), podemos caer en generar una estimación que no se ajuste a la dedicación real.

mm

Sobre Adrián Prats

Experto en Administración de Sistemas Informáticos en Red, Sharepoint y Windows Server 2012R2 (MCP 70-410 y MCP 70-497). Tengo amplia experiencia como Analista QA, realizando pruebas funcionales, test de carga y rendimiento, automatización de pruebas, pruebas unitarias (unit test), pruebas de integración, pruebas exploratorias, elaboración del test plan, etc. Actualmente soy Quality Assurance Specialist en ENCAMINA.
Esta entrada ha sido publicada en Story Points. Enlace permanente.
Suscríbete a Piensa en Sofware desarrolla en Colores

Suscríbete a Piensa en Sofware desarrolla en Colores

Recibe todas las actualizaciones semanalmente de nuestro blog

You have Successfully Subscribed!

ENCAMINA, piensa en colores