Un bonus económico por historia de usuario completada

Historias de usuario, aquello que surgió, como no podía ser de otra manera, de una historia que un usuario le contó a Kent Beck (principal creador de eXtreme Programing, te dejo post y vídeo, por si quieres ampliar info) sobre un nuevo producto: “Yo quiero escribir el código postal y que automáticamente el formulario se complete con la ciudad y el estado”.

Las historias de usuario son ya muy viejunas, vienen de los 90. Y a pesar de ello, aún hoy, mucha gente las asocia a Scrum, cuando realmente las empezamos a conocer en aquel libro eXtreme Programming Explained (en la foto de abajo te dejo una foto que hice hace un rato a mi libro del 2001, con la primera referencia).

PEROOO pensando en el 2023… ¿Te imaginas que un equipo cobrase sus objetivos económicos en base al número de historias de usuario que termina y, obviamente deja en el producto cumpliendo el DoD? What? ¿Te suena muy sensato o muy a Don Eulalio Bocanegra?

Nuestro Mr. NoBody de hoy era (y espero que siga siendo) un gran Scrum Master. Un programador veterano, de colmillo retorcido, que entendía muy bien que su rol iba de trabajar, Ágilmente, y de manera continua, en que un equipo mejore su eficiencia y eficacia (más info aquí). 

Yo, como otras veces, asistí a una de las retros que organizaba y la dinámica que usó aquel día fue… cuanto menos… interesante:

—Como los de RR.HH aún no me han dejado que sea una realidad vamos a tener que imaginarlo —empezó diciendo—. Si al equipo nos dieran un bonus económico por Historia de Usuario completada… ¿Qué cambiarías en la manera de trabajar del equipo?

Él lo tenía bastante claro, hacía aquella dinámica porque pensaba que los equipos hacían demasiadas cosas por placer tecnológico, cosas no directamente relacionadas con aportar valor, porque no había verdadera preocupación (y motivación) por la eficiencia.

Y aquel Scrum Máster tenía muy bien pensada la propuesta… pago por HISTORIA terminada

Podría haber sido por historia que realmente aporte valor al usuario real, pero eso saldría de las competencias del equipo técnico, que se escudaría en que no es su responsabilidad y, además, no podría medirlo al final de cada iteración. 

Podría haber sido por ítem terminado (tareas, documentar, testear, etc.), en vez de historia, pero esto entonces podría pervertir el Backlog, animando a introducir ahí tareas que no terminan en Working Software o Incremento de producto.

Podría haber sido un pago por persona, pero eso mermaría la cohesión del equipo.

Realmente lo tenía pensado, y realmente creía que muchas retrospectivas salían sin acciones útiles de mejora de eficiencia porque no había un sentimiento real de mejorar la eficiencia, entendida como número de historias de usuario en el producto al final del Sprint.

¿Y tú qué piensas?

Antes de terminar, y que me lo digas, me adelanto… claramente, la propuesta tiene algunos Lados Oscuros que habría que depurar, por ejemplo, por enumerar algunos, habría que contemplar de alguna manera los errores provocados por esas historias de usuario, no sea que generemos un modelo que premie hacer rápido historias… reduciendo, por ejemplo, el Testing y creando un gran problema.

O que aquella propuesta mermaría el interés en hacer tareas de investigación, tareas de reducción de deuda técnica, etc. Otro Oscuro problema.

Pero, a modo de debate y reflexión, me ha parecido interesante contártelo y, como moraleja de fondo … ¿realmente tenemos en mente, lo suficiente, qué gran parte de las acciones de mejora deben ir orientadas a incrementar el número de historias que terminamos sin introducir el Lado Oscuro de hacer las cosas mal con deuda técnica o bugs?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba