Una de las grandes preocupaciones de los equipos Scrum es cómo ordenar el Product Backlog. Existen muchas técnicas como el modelo Kano, Moscow o Eisenhower. En todas ellas tratamos de conseguir una ordenación basada en valor del negocio. Sin embargo, acabamos estrellándonos por culpa de la Paradoja del Login. Un elemento que, a priori, no aporta valor pero que es esencial en sistemas que requieren de autenticación y autorización. ¿Debemos ordenar el Product Backlog por valor?
¿Cómo ordenar tu Product Backlog?
Según nuestro grado de incertidumbre y de la estrategia que sigamos con nuestro producto, tendremos diferentes formas de ordenarlo.
Cómo hemos visto en otros artículos, un Scrum Team debe responder a la pregunta “¿para qué hacemos este producto?”, cuya respuesta será el Product Goal. A la hora de ordenar, cambia mucho si vamos a desarrollar un producto nuevo de cero que reconstruir uno existente o ampliar uno que funciona bien.
Sea como fuere el objetivo de cualquier equipo Scrum es maximizar valor, es decir, que el incremento que construyamos mejore el valor actual. Midiendo valor podremos entender si hacemos un buen trabajo.
Por tanto, la ordenación del Product Backlog es más complicada de lo que podemos pensar en un primer momento, hay que entender muy bien el contexto de nuestro Scrum Team.
Ordenar por valor… ¡Espera!
Muchas personas afirman que el Product Backlog se ordena por valor. Esta definición es incorrecta ya que desarrollar un producto requiere de muchas más dimensiones que el valor. El objetivo de un Producto es maximizar valor, desarrollar elementos del Backlog de alto valor pero que conllevan mucho trabajo puede ser mala idea. Debemos encontrar aquellos elementos de bajo tamaño, que tengan un gran impacto y que no tengan dependencias que impidan desarrollarlos.
Además, para ordenar por valor debemos asumir que podemos definir un valor número al valor. Hay técnicas como Kano o WSJF (Weighted Shortest Job First) que tratan de asignar un valor numérico a cada item. Ese dato, lo confrontamos contra el valor de estimación de esfuerzo que den los developers. El problema de está estrategia es que tanto la estimación de esfuerzo (o tiempo) como el valor asignado son siempre una invención hasta que nos enfrentamos a la realidad del problema.
Un problema siempre puede ser más difícil de lo que esperamos o con llevar más tiempo del previsto por múltiples causas: falta de entendimiento técnico, falta de experiencia, problemas en el equipo o fallo de tecnología entre otros.
El valor asignado dispone del mismo problema. Aunque la comunicación con tu cliente sea muy fluida hasta que el usuario final reciba el producto y conviva con él, podremos validar que le entregamos valor. Incluso existen productos de alta calidad técnica que cuando llegan al usuario y este lo valora positivamente, continúan sin aportar valor, ya que los usuarios no están dispuestos a pagar por ello.
La paradoja del login
Vamos a ilustrar la Paradoja del Login con un ejemplo. Imagina que tenemos un Product Backlog con varios elementos y queremos estimar el esfuerzo y por otro lado el valor que consideramos que nos aportará cada uno de ellos. ¿qué valor y esfuerzo le darías al Login?
El esfuerzo que conlleva hacer un login no suele ser muy elevado salvo que tengamos algún sistema de autenticación complejo. También, puede ocurrir que tengamos muchos sistemas de login como pueden ser cuentas de Google o Microsoft unidas a cuentas de terceros. Sin embargo, la paradoja aparece cuando tenemos que darle un valor o un número al valor recibido por el login.
El login es una funcionalidad que aporta poco valor, un cliente no pagaría por tener un login pero que es necesario construirlo en los primeros Sprints para garantizar la seguridad posterior y una buena experiencia de usuario. Una aplicación que arranca con un login necesita del mismo aunque no aporte valor de negocio.
El login es un elemento básico de muchas apps. Si aplicamos cualquier técnica de ordenación dejaríamos al login en un segundo plano al tener un valor numérico inferior. Esto nos lleva a la Paradoja del Login, hay elementos que tienen que construirse antes que otros por su importancia en el Producto aunque no aporten valor.
El valor es del producto no del backlog
Para entender y resolver la Paradoja de Login tenemos que diferenciar entre el valor del producto y el valor de los ítems del Product Backlog.
Muchas bibliografía te dice que podrías medir el valor de cada ítem. En mi experiencia realizar esta labor es prácticamente imposible. Si hicieras eso, algunas features de alto valor se antepondrían a otras básicas que soportan el producto. Por ejemplo, los usuarios se compran un coche por un buen sistema de música y no porque tenga cuatro puertas, ahora bien, un coche sin cuatro puertas no se puede vender. ¿Te compras el coche por las puertas o por la música?
Hay muchas características que son básicas para el funcionamiento de. producto a pesar de que el cliente no pague por ellas. Cualquier móvil moderno tiene que tener acceso a internet como característica básica, no es diferencial pero es importante disponer de ello.
Por tanto, tenemos que entender que asignar valor a los ítems no nos ayuda a ordenar el backlog. Lo que sí nos ayuda es asignar valor al producto y métricas de valor que me den información sobre las decisiones que estamos tomando. ¡El valor es del Producto!
Análisis Kano
De todas las técnicas que existen para ordenar un backlog, una de mis favoritas es el análisis Kano. El análisis Kano asigna un determinado color a los diferentes ítems que tenemos en el backlog en función del coste de ejecución y de la satisfacción percibida por el usuario. Lo interesante del modelo Kano es que te muestra que hay características básicas que generan mucha insatisfacción cuando no están presentes. Esto significa que debes de cubrirlas para evitar que la percepción final sea negativa.
Por otro lado, el análisis Kano muestra aquellas características de tu producto que son estándar. En estas, a mayor cantidad mayor satisfacción pero se puede disparar el coste. Por último, aquellas características atractivas que sí atraen a tu usuario por su alto impacto. De estas, tenemos que seleccionar algunas.
El análisis Kano podemos unirlos a otras técnicas como un RoadMap o un User Story Map para visualizar el ordenar y la estrategia de construcción de nuestro producto. Así, conseguimos unir tanto satisfacción de usuario, ejecución y tiempo. ¡Podremos tomar mejores decisiones!
Y tú, ¿Cómo ordenas el Login en tu Product Backlog?
Eres el mejor Javi 💪👏👏👏