Muchas veces tenemos un backlog lleno de historias de usuario y, cuando llega el momento de empezar a trabajar en ellas, nos preguntamos por cuál deberíamos empezar. Decidir qué la prioridad de cada historia de usuario es tan importante como el hecho de concebir y definir cada user story, ya que nuestro producto o servicio necesita que el aporte de valor continuo con el que lo estamos alimentando tenga sentido y, además, responda a sus necesidades reales.
Existen muchas técnicas de priorización. Aunque todos tenemos nuestra favorita, es interesante conocer varias de ellas y experimentar para poder usar unas u otras según las necesidades del proyecto. ¿Pueden usarse en un mismo proyecto diferentes técnicas de priorización? Se puede (en diferentes sprint planning, por supuesto). Según el estado del proyecto y sus características, y según la etapa en la que se encuentre el producto o servicio, puede ser interesante cambiar el sistema de priorización.
Así que vamos a ver cuatro de los sistemas más comunes. Son todos sencillos de aplicar e, incluso, algunos tienen ciertas semejanzas entre sí, pero se distinguen porque usan diferentes patrones a la hora de decidir qué historia de usuario es más importante que otra.
Matriz de urgencia
Este sistema se basa en dos conceptos para decidir la importancia que tiene una historia de usuario:
- Urgencia: se mide con valores de 1 a 5, donde el 5 implica que esa historia de usuario debe estar lista pronto o de lo contrario perderá sentido, mientras que un valor de 1 indica que no hay prisa en ponerla en producción.
- Valor de negocio (Business Value): el valor que le asigna negocio a la historia de usuario. Representa el beneficio que va a recibir cualquiera de los usuarios implicados* en el producto cuando desarrollemos esta historia y publiquemos la nueva funcionalidad. De nuevo, el 1 se le asigna al valor más bajo y el 5 al más alto.
*El usuario que recibe el beneficio no tiene por qué ser el «usuario final». Puede tratarse de los propios stakeholders o de un usuario administrador de la plataforma o, incluso, del propio equipo de desarrollo.
Una vez evaluadas la urgencia y el valor de negocio, usaremos la siguiente matriz para medir la importancia de esta historia de usuario:
Lo único que tenemos que hacer es el multiplicar el valor de negocio por la urgencia. Cuanto más alto nos salga el valor (el máximo será una puntuación de 25), más alto queda esta historia dentro del orden de prioridad. Por ejemplo, imaginemos que tenemos las siguientes historias de usuario:
- Historia 1 ⮕ Como comprador, quiero una sección donde poder ver mis compras realizadas para repetir algunas de mis compras.
- Historia 2 ⮕ Como stakeholder, quiero actualizar las condiciones de uso para evitar que nos denuncien por incumplimiento de las mismas.
- Historia 3 ⮕ Como admin de la tienda, quiero un panel con los datos de cada compra para poder obtener estadísticas de ventas.
Todas estas historias de usuario tienen su relevancia, pero ¿cuál es la más importante? ¿en cuál debemos poner el foco ahora mismo? En este caso, para cada historia asignaríamos una puntuación en cuanto urgencia y valor de negocio. Podrían quedar así:
- Historia 1
- Urgencia: 2
- Valor de negocio: 3
- Total: 2×3=6
- Historia 2
- Urgencia: 5
- Valor de negocio: 5
- Total: 5×5=25
- Historia 3
- Urgencia: 4
- Valor de negocio: 4
- Total: 4×4=16
Tras este ejemplo, las historias a abordar irían en el siguiente orden: Historia 2, Historia 3, Historia 1.
MoSCoW – Técnica de priorización de tareas
Esta técnica es de las más usadas en el mundo del agilismo. Básicamente trata de establecer la prioridad en función de cuatro valores que determinan la importancia de cada historia de usuario. Estos valores son:
- M → esta funcionalidad debe estar (MUST HAVE).
- S → esta funcionalidad debería estar (SHOULD HAVE).
- C → esta funcionalidad podría estar (COULD HAVE).
- W → esta funcionalidad no estará ahora, quizás en un futuro (WON’T HAVE).
Cada HU debe ser etiquetada con alguna de estas letras. Las prioridades irán en el siguiente orden: primero las etiquetadas con M, luego con S, en tercer término aquellas con C y finalmente aquellas con W.
Los términos deben regirse por las siguientes definiciones:
Must have
Estos requisitos no son negociables. Si no se entregan, el producto o módulo funcional deja de tener valor o sentido. Por ejemplo, un login podría ser un must have de libro. O, en una tienda digital, el buscador de productos.
Should Have
Son requisitos importantes pero no son imprescindibles para la entrega en el plazo actual, ya que el software también puede demostrar su valía sin estas funcionalidades. Con el tiempo podrían llegar a ser Must Have, pero hoy en día no lo son. Por ejemplo, incluir comentarios y valoraciones de los clientes en una tienda digital.
Could Have
Son requisitos deseables. Podrían ser no estrictamente necesarios, como, por ejemplo, una mejora UX que facilite alguna acción del usuario.
Won´t have
Son requisitos que sabemos que ahora mismo no deben ser abordados. Puede ser bien porque no sea el momento apropiado o porque hay dependencias de otras historias que aún no han sido desarrolladas.
Los requisitos pueden pasar de un estado a otro, según el proyecto vaya iterando y el conocimiento del mismo se vaya incrementando.
Puntos de esfuerzo & Valor de negocio
Para esta técnica vamos a trabajar con dos conceptos que son muy conocidos para cualquier Project/Product Manager/Owner:
- Puntos de valor de negocio (business value points): es el valor que el PO junto con los Stakeholders asignan a una historia de usuario. Es decir, la importancia (relevancia) de ese desarrollo para el producto o servicio que estamos construyendo.
- Puntos de esfuerzo: es la estimación del equipo respecto al esfuerzo necesario para llevar a buen término una historia de usuario. Normalmente se usan puntos de esfuerzo, pero a veces también se usa como medida el número de horas necesarias.
Teniendo estos dos conceptos claros, el ejercicio a realizar es muy sencillo. Tenemos que valorar cada historia de usuario con ambos, después buscaremos el cociente resultante entre los dos valores, lo que nos permite obtener el mayor valor en el menor tiempo posible.
De esta manera, tendríamos una matriz como la siguiente:
Cuanto mayor sea el cociente, mayor es la prioridad de la historia de usuario y, por tanto, más importancia le daremos en el sprint planning.
Kano
Esta técnica está basada en la percepción y necesidades que tienen los usuarios sobre nuestro producto. De alguna manera, delegamos en ellos la prioridad de los futuros desarrollos, basándola en sus opiniones. Pero vamos por partes. Lo primero es comentar que este método se basa en las siguientes premisas:
- La satisfacción del usuario con nuestro producto es directamente proporcional al nivel de calidad de la funcionalidad que desarrollamos, es decir, lo correctamente que la hayamos implementado.
- Las funcionalidades se pueden clasificar en cuatro categorías.
- Podemos determinar cómo perciben nuestros usuarios una funcionalidad a través de un cuestionario.
La aplicación de Kano se realiza mediante encuestas o entrevistas con usuarios. Es importante que los usuarios que participen sean una muestra fiel de las personas que utilizan o utilizarán estas funcionalidades.
Por cada requisito o historia de usuario que queramos analizar, debemos hacer dos preguntas, una funcional y otra disfuncional:
¿Cómo te sentirías si en la pantalla para hacer log in como usuario…
…existe…
…no existe…
…X funcionalidad?
Por ejemplo, tendríamos la siguiente pregunta en sus dos modalidades:
- «¿Cómo te sentirías si en la pantalla para hacer log in como usuario existe una opción para hacerlo a través de tu cuenta de gmail (Google)?»
- «¿Cómo te sentirías si en la pantalla para hacer log in como usuario no existe una opción para hacerlo a través de tu cuenta de gmail (Google)?»
Para cada pregunta que hagamos, el usuario ha de escoger una respuesta de entre:
- Me gusta de esa forma.
- Espero que sea de esa forma.
- Me es indiferente.
- Puedo vivir con eso.
- No me gusta de esa forma.
Con los resultados obtenidos, tendremos una matriz que nos dirá cómo de importante es para el usuario el que esté o no esté la funcionalidad:
Los distintos valores de resultado que hemos obtenido tienen la siguiente definición:
- Cuestionable: aquí hay un sinsentido. La respuesta no se puede dar por válida.
- Rechazo: funcionalidad que genera rechazo en el cliente. No la quieren.
- Indiferente: no parecen tener un peso importante en ninguna dirección. Son funcionalidades que no molestan aunque tampoco parecen ayudar.
- Atractivo: funcionalidad que gusta, aunque no esperan tenerla. Es interesante hacerlo, pero no parece demandar prisa.
- Obligatorio: no tenerlo es un problema. Al cliente le gustaría tenerlo, aunque no le encantaría. Hay que desarrollar esta funcionalidad.
- Deseado: es un win-win. No solo se desea, sino que no tenerlo es un problema.
Este modelo no es práctico para la totalidad de las HU, ya que exige mucho esfuerzo. Pero es muy interesante para aquellas funcionalidades que consideremos clave o tengan un riesgo importante a la hora de ser desarrolladas. También puede usarse cuando estemos planificando la creación del PMV de nuestro producto y estemos en la fase de validación del problema.
Conclusiones
Las diferentes técnicas de priorizar responden a diferentes modelos de gestión, en función del contexto del proyecto (tipología, stakeholders, estado). Usa la que veas conveniente según las necesidades del servicio o producto con el que trabajas.
Puede que la técnica Kano sea mejor cuando nos enfrentamos a desarrollos muy arriesgados. Puede que MoSCoW sea una buena opción si hay dificultades para evaluar esfuerzos o el valor de negocio. La matriz de urgencia es bastante versátil y se adapta a muchos proyectos. Puntos de esfuerzo & valor de negocio es muy sencilla de aplicar, ya que maneja conceptos muy claros tanto para el cliente como para el equipo que desarrolla.
No importa tanto cuál uses como el hecho de que uses una bien clara y bien definida, con la que todos los involucrados en el proyecto estén alineados.
