User Stories: Story points.

Medir el esfuerzo que se necesita para realizar una actividad en el proyecto es un problema. Por definición es una medida subjetiva, aun cuando uses valores objetivos como horas, semanas o días, numero de recursos, etc. No todos los involucrados entienden el esfuerzo que cuesta producir algo. Algo fácil de construir puede ser difícil de probar, algo difícil de construir puede ser fácil de liberar y operar. El problema surge a la hora comunicarse con otros relacionados al proyecto, cada persona tiene una medición personal de esfuerzo y duración de las actividades, llegar a un acuerdo con otras puede complicarse. El tiempo es medible, el esfuerzo no.

No midas tus historias de usuario en horas.

Una historia de usuario representa un valor que se aportara a las personas,  cada historia tiene mas valor para un rol que otro, hablando de usuarios y hablando de áreas de la empresa. Si eliges medir las historias en términos de duración o de numero de programadores involucrados solo expones el coste y los intereses del equipo. Esto no comunica nada a los demás interesados, ¿vas a requerir dos programadores y  dos semanas para una historia?, muy bien, pero ¿esto que significa para las demás áreas interesadas en el proyecto?. Puede significar que la actividad es compleja o difícil, o que el equipo tiene dificultades para delegar,o también que parte del equipo no es competente. Esto visto en el tablero de actividades no dice absolutamente nada del valor que se aporta. Necesitas una unidad de medida diferente.

Los user points sirven para medir y sirven para comunicar.

Los puntos de usuario son una medida subjetiva del esfuerzo/valor que representa una actividad. Y representan un consenso por parte de los interesados del proyecto. Cuando el equipo se reúne en cada iteración del proyecto con los dueños del producto o interesados, al momento de definir que actividades se harán o que items se ingresaran al backlog se define el coste en puntos de usuario de cada actividad. El objetivo de definir el coste en puntos es llegar a un acuerdo de la relación coste/beneficio de cada actividad. Es posible que exista un desacuerdo entre el coste de actividades entre un área u otra, por ejemplo: hace varios años un aplicativo en una empresa donde trabajaba produjo inconsistencia en la información de la base de datos que estaba afectando a un cliente, al momento de hablar con el Project Manager de este bug, el lo califico como una actividad rápida ya que solo era un “query” el que se tenia que ejecutar. Y si, tenia razón pero el coste de producir, validar y garantizar ese query iba a tomar mas que un par de horas para ser llevado a cabo. Cada área tenia visiones distintas de la actividad.

Siguiendo con el ejemplo anterior, en una reunión  basada en story points al momento de cuantificar esta actividad el PM emitirá una cantidad de puntos de usuario que el cree que amerita esta actividad, el área de desarrollo hará lo mismo, la idea es buscar un punto medio y abrir la puerta al dialogo. Es posible que este bug este afectando al cliente en producción por lo que su urgencia y su importancia se vería reflejado tanto en la cantidad de puntos que pone el equipo de desarrollo como en la cantidad de puntos  que asigna el PM. Pero, ¿que tal si este bug no es critico?. Si es importante, pero no es necesario tomarlo en este sprint, la cantidad de puntos asignados a la actividad bajara. El consenso con el PM puede ser, esta actividad (el query) no es trivial, pero tampoco critica, vamos a asignarle un numero alto de puntos de usuario por arriba de la media para que sea considerada importante. El equipo de trabajo tiende a entregar 20 puntos de usuario por iteración, la actividad cuesta 10 puntos de usuario. Esto significa que en un sprint, al tomar esta actividad se va a tomar la mitad de la capacidad del equipo, es posible que en este sprint y el que sigue no exista el modo de colocar esta actividad sin afectar a otros clientes, pero dentro de 3 sprints se puede entregar esta corrección.

Los user points buscan igualar a los interesados, no hacer diferencias.

Como pudiste ver en el ejemplo anterior, jamas se hace mención de horas, ni complejidad. Se hace mención de esfuerzo y valor. Al equipo de desarrollo le importa el esfuerzo ya que, obvio, nosotros lo vamos a construir, pero al interesado del producto le importa el valor de cara a sus clientes y/o usuarios, según sea el caso. Es fácil para el desarrollador catalogar y descartar actividades si estas son muy complejas, alguien las tiene que hacer, sobre todo si son indispensables para el flujo productivo. La falla esta en no cuantificar, ni comunicar el esfuerzo que se dedica. Los puntos de usuario permitieron unir criterios y llegar a un acuerdo.

Cada persona es diferente, y el usar los puntos de usuario puede no terminar en un acuerdo al momento de definir actividades. La técnica no es perfecta, es un auxiliar para mejorar la comunicación. Si algo falla al momento de llegar a un acuerdo puede haber factores externos involucrados.

Los user points bien usados producen métricas.

Las métricas son importantes, demasiado. Permiten estimar y hacer predicciones. Es común que un equipo de trabajo nunca sepa cuanto valor esta aportando, si tu como área eres incapaz de comunicar cuanto valor aportas a la empresa con cada sprint, los demás van a tener la percepción de que no haces nada. La visibilidad del valor que aportas es crucial para tener un área de desarrollo sana. Si cada semana aportas un numero determinado de puntos de usuario acordados con los demás interesados, estos puntos tienen nombre y apellido, hablan acerca de lo que hiciste y son visibles por los demás. No es lo mismo decir: “gastamos 10 user points en este sprint en corregir los datos de un cliente que no podía cuadrar sus reportes de ventas trimestrales, con esta corrección el cliente se ahorro el tener que generar los reportes manualmente”, a decir: “invertimos una semana en generar un query”. La diferencia entre la primer oración y la segunda es que hubo un acuerdo entre el esfuerzo/valor de una actividad y en la otra no.

Aparte, en este caso en particular, se notifica que se va a gastar esfuerzo en corregir bugs. El tiempo de reparación y re trabajo por lo general se omite en las métricas. Esto es un error ya que el esfuerzo que se dedica por parte del equipo pasa desapercibido. Es valido decir que dejaras de hacer items del backlog para atender bugs, sigue siendo trabajo y sigue siendo necesario. Lo que no es correcto es pasar las correcciones por debajo de la mesa para que los demás no se enteren del error. Todo esfuerzo debe ser cuantificado, no importa su origen.