Uno de los grandes retos para un Product Owner a la hora de liderar un producto es cómo ordenar los backlogs sin perder el foco.
Las necesidades cambiantes y el continuo feedback, la convierten en una compleja tarea de backlogs que por suerte nunca dejan de crecer.
Existen diferentes variables a tener en cuenta a la hora de priorizar historias de usuario: el valor que aporta (ya sea a nivel funcional o a nivel de mercado), el retorno de inversión, el tiempo y esfuerzo, los riesgos potenciales, la suma de las opiniones de los diferentes integrantes del equipo y stakeholders, los objetivos de producto y estratégicos de compañía, etc.
Habitualmente, con toda esta información, las historias se van ordenando casi de forma automática en nuestro Product Backlog y si trabajamos con Scrum fluyen hasta los Sprint Backlogs, pero siempre surgen puntos de debate que ninguna de las variables puede desempatar y la decisión final acaba en manos del Product Owner.
¿Cómo podemos tomar la mejor decisión sin miedo a equivocarnos? Tranquilo todo el mundo. Existen herramientas útiles para darnos esta seguridad.
Dejando a un lado la técnica que divide el valor para negocio entre los puntos de esfuerzo —que según mi experiencia es poco efectiva, entre otros motivos, porque aumenta la diferenciación entre negocio y técnicos, no genera conversaciones y el resultado no siempre se corresponde con lo esperado—, vamos a exponer y a comparar las dos herramientas que más me han ayudado a la hora de tomar decisiones: Matriz de Eisenhower y MoSCoW.
Matriz de Eisenhower
Dwight Eisenhower, 34º Presidente de los Estados Unidos, acuñó la frase:
Lo que es importante rara vez es urgente, y lo que es urgente rara vez es importante.
Con esta filosofía por bandera, la matriz propone cuatro tipos de cuadrantes ordenados de 1 a 4 donde debemos ubicar nuestras historias:
- Historias de usuario importantes y urgentes: estas historias son las que debemos poner en primer orden, máxima prioridad, máximo foco. Son aquellas alineadas con los objetivos, que aportan máximo valor a negocio, que aportan máximo valor al cliente, y que además, están dentro de la zona de confort del equipo de desarrollo o llevan pocos puntos de historia.
- Historias de usuario importantes pero no urgentes: todas se aquellas alineadas con los objetivos a medio/largo plazo, aquellas sin imposiciones de fecha, pero que aportan valor a negocio y clientes.
- Historias de usuarios no importantes pero urgentes: al contrario que el punto anterior, vienen marcadas por una fecha, pero no van en línea de los objetivos, ni tienen un alto valor para negocio/cliente. Estas historias debemos abordarlas después de las que hemos tipificado como cuadrante 2.
- Historias de usuarios no importantes y no urgentes: aquí el señor Eisenhower es tajante con lo que debemos hacer con estas historias, las manda a la papelera o como me gusta decir: ¡A pastar!
MoSCoW
Lo primero que nos viene a la cabeza a los que conocemos esta herramienta es una hamburguesa.
¿Una hamburguesa? No es obsesión por este manjar, es el clásico ejemplo de cómo podemos usar MoSCoW: una hamburguesa DEBE llevar carne y pan, DEBERÍA llevar queso fundido y lechuga, PODRÍA llevar bacon y salsas, y NO TENDRÁ piña, por ejemplo.
Cuando usamos esta popular herramienta en nuestro backlog (y no para montar hamburguesas) debemos marcar cada una de nuestras historias de usuario con una de las siguientes letras en función de lo que nos pide nuestro producto:
- M - Debe tener (Must have): estos son los higiénicos, todas aquellas historias que deben estar para llamar producto a nuestro producto. Por ejemplo, algo que considero un must en un producto de e-commerce es una cesta de la compra.
- S - Debería tener (Should have): todas aquellas historias que nos gustaría tener pero que no son necesarias para el lanzamiento del producto. Siguiendo con el ejemplo del e-commerce un should sería un buscador de productos.
- C - Podría tener (Could have): estas historias suelen quedarse en el fondo del cajón del backlog, y son todas aquellas que podrían estar, que estaría bien incorporarlas pero que no van en línea con los objetivos o consideramos que son un extra prescindible. En un e-commerce un could sería por ejemplo la funcionalidad de favoritos.
- W - No tendrá (Won’t have): aquí pondremos todas aquellas historias que no queremos en nuestro producto, todo aquello que sabemos que no debe estar, o porque va en contra de los objetivos, o va en contra del producto, o no aporta valor, etc. Por ejemplo, en un ecommerce, un won’t sería una funcionalidad de conectar con amigos tipo redes sociales.
Después, podemos reordenar las historias agrupándolas por cada uno de los bloques de letras y tener una visión clara de cómo queda nuestro backlog.
La tarea de tipificar cada historia se lleva mejor a cabo por un grupo montado por varios miembros del equipo. Si hacemos partícipe a todo el equipo el resultado es exponencialmente mejor, pero la realidad es que no siempre podemos bloquear a todo el equipo para debatir sobre prioridades.
Diferencias entre Eisenhower y MoSCoW
Una gran ventaja compartida por ambas herramientas es la facilidad para implementarla en nuestros backlogs, la sencillez para explicarlas y la rapidez con que podemos usarla en nuestros equipos. Un gran punto débil es que son herramientas orientadas al medio y largo plazo.
Por otro lado, al poner la lupa sobre la Matriz de Eisenhower, vemos que es una herramienta con foco primero en lo importante y después en lo urgente. Lo cortés no quita lo valiente y muchas veces nos vemos obligados a tomar decisiones sometidos a la presión de una fecha de entrega por el bien estratégico de la compañía.
Esto descoloca la matriz. Podemos vernos en la situación de priorizar historias que han caído en el cuadrante 3 sobre otras que han caído en el 2 o incluso (¡pecado! ¡hereje!) por encima del 1.
En el caso de MoSCoW, esta trabaja sobre arenas movedizas. Todo es prioridad alta, máxima, asap, para ayer. Entran en juego las opiniones, lo que para unos es una S para otros es una C, por ejemplo.
Es un terreno subjetivo en el cual debemos ser cuidadosos, escuchar todas las opiniones, al mismo tiempo que no perdemos el foco, no olvidamos lo importante: nuestro producto, nuestros clientes.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Conclusiones
En mi opinión, si tuviera que elegir entre ambas herramientas considero que la que me ha dado mejores resultados es MoSCoW.
Los debates generados en torno a qué letra dar a cada historia han siempre enriquecedores. Algo esencial es no olvidar dónde debe estar el foco, teniendo siempre en mente el objetivo, el producto final que se espera conseguir, y el público al que esperas llegar. Sin duda, esta herramienta resulta sencilla de usar.
Preciosas definiciones, maravillosas herramientas, pero ¿cómo pueden ayudarme a ordenar diez historias del mismo tipo?
Hilar fino, poder ordenar a muy bajo nivel es la diferencia entre un buen backlog y una obra de arte. Por un lado, si tenemos dudas debemos volver a las variables iniciales y asegurar el máximo para las historias que pongamos por encima de otras, por otro lado debes apoyarte en tu instinto, el olfato que te da la experiencia.
Algo que me ayuda es pensar en probar. Prueba y error. Fallar pronto, fallar barato. Si algo no resulta como esperamos, en la siguiente iteración lo haremos mejor, y seremos un poco más sabios y poco a poco iremos quitándonos ese miedo.
La realidad del día a día (a.k.a. trincheras) nos obliga a coger estas herramientas, ponerlas sobre la mesa con el resto del equipo, llegar a acuerdos, modelarlas, iterarlas y acabar fabricando nuestras propias herramientas, porque son las que acaban funcionando en nuestro producto.
Cuando después de todo dudamos, me gusta hacer una pregunta: si ocurre una catástrofe, todos los miembros del equipo de desarrollo menos uno se ponen enfermos (recordad comer cosas diferentes), y sólo se puede desarrollar una única historia de usuario, ¿cuál sería? ¿Y si sólo pueden entrar dos? A medida que vas respondiendo a estas preguntas el backlog se va ordenando.
Para saber más: descarga nuestro libro Las Claves del Product Management
