Desbloqueando el potencial de la priorización: frameworks más importantes.

Visión, estrategia, roadmap, backlog, historias de usuario… ¿Te gustaría enterarte bien de qué significa todo esto y cómo se relaciona? En este post te contamos la relación entre estos conceptos y te explicamos algunos de los frameworks de priorización más conocidos para ayudarte a gestionar tu proyecto o producto de la mejor forma posible y favorecer así la entrega de valor alineada con los objetivos y el roadmap.

Empecemos por el principio: visión y estrategia

Visión.

Todo producto tiene una, y es algo así como una “frase inspiracional” que intenta explicar a dónde queremos llegar con este producto. Digamos que es donde “nos vemos en el futuro”, es decir, lo que queremos que ese producto llegue a ser.

Por ejemplo, la visión de Linkedin es: _“To create economic opportunity for every member of the global workforce” _.

Estrategia.

Es tan simple como decir que es el camino que seguimos y los pasos que damos para alcanzar esa visión. En otras palabras, es el cómo. La estrategia del producto está vinculada a su visión de la misma forma que la estrategia y la visión de la empresa lo están.

Quizás te estés preguntando si esto puede cambiar con el tiempo, y lo cierto es que sí. De la misma forma que consideramos que la visión del producto es inspiracional, lo que buscamos es alcanzarla. Y eso, por supuesto, puede ocurrir (esa es la idea, ¿no?). Cuando esto pasa, se define una nueva visión y, por lo tanto, también una nueva estrategia para alcanzarla.

Pero, ¿y todo esto qué tiene que ver con el roadmap y el backlog?

El roadmap es la herramienta que tiene el Product Owner para plasmar esa estrategia de forma más palpable y que podamos, gracias a ese trabajo, traducirla en problemas o soluciones.

Es muy importante tratar de ser realista en este punto e intentar aterrizar todo esto de forma que se corresponda con mínimos viables. Y sí, hacerlo, además, alineándote con tus stakeholders. ¡Esto es importantísimo!

💡 Tip extra: ¡No te olvides de que es muy importante que tengas en cuenta los objetivos a la hora de plasmar tu roadmap!

Cuando ya tenemos nuestro roadmap, el siguiente paso es traducirlo en una especie de “lista ordenada” del trabajo que tenemos que hacer para llegar a crear esas soluciones que aporten el valor esperado a nuestros/as usuarios/as y, por lo tanto, nos acerquen un poco más a esa visión de la que hablábamos. Normalmente, esa lista suele terminar convirtiéndose en una serie de historias de usuario, que más tarde se dividirán en subtareas… Y es aquí donde lo tenemos: ¡Nuestro backlog!

¡Así de simple! Espera… ¿Simple? Quizás no tanto.

Hasta aquí podríamos decir que hemos llegado al punto donde, gracias a la visión y estrategia de nuestro producto, hemos desarrollado un roadmap que nos ha ayudado a dar vida a nuestro backlog con historias de usuario pero… ¿Y esto cómo se ordena?

Para ayudarnos con esta tarea, tenemos a nuestra disposición una grandísima cantidad de frameworks de priorización. Aquí os contamos algunos:

Impacto esfuerzo

Este framework nos ayuda a priorizar las features en base al impacto que tendrán en el negocio y el esfuerzo que lleva poder desarrollarlas. Es decir, a través de una matriz bastante sencilla, nos ayuda a decidir las prioridades de las diferentes funcionalidades.

Esta matriz tiene dos ejes (Impacto, Esfuerzo) y cuatro cuadrantes, y se representa de la siguiente forma:

• Q1: hablamos de tareas que provocan grandes recompensas con poco esfuerzo, de forma que son las que primero se deberían abordar. Son las que tienen la prioridad más alta.
• Q2: aquí caen las features que, al igual que las anteriores, también provocan un gran impacto en negocio y usuarios/as, pero requieren un gran esfuerzo para poder ser implementadas, de forma que serían las segundas en ser priorizadas.
• Q3: en este cuadrante tenemos funcionalidades que, aunque requieren poco esfuerzo para llevarse a cabo, nos proporcionan un impacto bajo. Estas tareas se llevarían a cabo en tercer lugar.
• Q4: estas features implican mucho trabajo y generan poca recompensa, de forma que deberíamos replantearnos si de verdad nos merece la pena incluirlas en nuestra priorización.

Una vez vista la parte más teórica, vamos a contarte cómo desarrollar el ejercicio de priorización con el framework impacto esfuerzo:

1. Crear una lista completa de las tareas que queremos priorizar.
2. Agruparlas en funcionalidades más completas
3. Utilizar la matriz anterior para empezar a colocar los grupos de tareas en el cuadrante que mejor encaje
4. Ordenar el backlog según las prioridades marcadas en la matriz

• Las más prioritarias son las que están en el cuadrante Q1 y las menos, las del cuadrante Q4.
• Dentro de cada cuadrante, definir la prioridad según la posición que se le haya dado dentro del mismo. Por ejemplo, para el cuadrante Q1, la que tiene mayor prioridad sería la que esté situada más arriba y más a la izquierda, y la que menos prioridad tendría sería la que estuviese más abajo y a la derecha.

7. ¡Y listo!

Como 💡 tip, os aconsejamos que para este tipo de priorización incluyáis a más miembros del equipo de forma que lleguéis a acuerdos para cada tarea. Así, además de para priorizar, podéis conseguir que este trabajo os sirva también para mejorar el alineamiento dentro del equipo.

Kano

Kano es un método de priorización que pone el foco en la satisfacción de los/as usuarios/as con las funcionalidades de un producto digital. Para esto, se clasifican en cuatro categorías representadas en dos ejes:

• Satisfacción. En este eje representamos la satisfacción de la persona usuaria con cada funcionalidad concreta, siguiendo una escala que va desde la frustración hasta la felicidad.
• Funcionalidad. Esta dimensión representa el nivel de funcionalidad que se le aporta al usuario/a, y el rango va desde “ninguna” hasta “la mejor”.

En la siguiente gráfica se muestran las cuatro categorías de este modelo:

• Obligatoria (Must be). Aunque su presencia no aumenta la satisfacción, provoca desagrado si no está. Por ejemplo, que un avión tenga asientos no hace más felices a las personas que viajan, pero provocaría mucha insatisfacción si no los tuvieran.
• Rendimiento (Performance). Aunque no son necesarias para un funcionamiento normal, aumentan mucho la satisfacción de las personas usuarias. Por ejemplo, que los asientos del avión sean cómodos y haya espacio suficiente para las piernas.
• Emocionante (Delighter). Funcionalidades que no se esperan y cuya presencia aumenta la alegría de los usuarios/as. Por ejemplo, si en un avión regalan una almohada y un antifaz para el viaje. Las personas que lo reciben se llevan una alegría pero es algo que no esperan, por lo que de no hacerlo no lo echarían de menos.
• Indiferente (Indifferent). Ni aumenta ni disminuye la satisfacción de los usuarios/as con el producto o servicio. Por ejemplo, que los asientos del avión sean azules o verdes.

Además de estas cuatro categorías, en ocasiones hablamos de una quinta, conocida como Reverse, que implica que la presencia de las funcionalidades dentro de la misma nos llevaría a una situación de desagrado o molestia por parte de nuestras personas usuarias.

A la hora de abordar la priorización de nuestro backlog siguiendo este modelo, podemos hacerlo de dos formas:

• A nivel interno. Listando todas las historias que queremos priorizar y empezando a colocarlas dentro de la gráfica anterior.
• A través de encuestas. Creando encuestas que se envíen a actuales o potenciales usuarios/as. Con los datos obtenidos, podemos analizar y priorizar en base a sus respuestas.

Por último, una vez tenemos nuestra gráfica completa, traducirla en forma de lista priorizada sería de la siguiente manera:

1. Obligatoria (Must be)
2. Rendimiento (Performance)
3. Emocionante (Delighter)
4. Indiferente (Indifferent)

MoSCoW

MoSCoW es un framework que nos ayuda a priorizar las funcionalidades en base a cuatro categorías diferentes según su importancia:

• Must: todas esas funcionalidades que deben estar presentes en el producto sí o sí; son las que forman parte del MVP. Para saber si esa feature que tenemos en la cabeza o esa iniciativa que estamos evaluando forma parte de este grupo, es útil preguntarnos: ¿Mi producto funcionará si no incluimos esto? Por ejemplo, en un e-commerce son indispensables funcionalidades como ver el listado de productos o pagar una compra.
• Should: funcionalidades importantes, pero sin ser imprescindibles para que el producto funcione. Es decir, son features que no forman parte del MVP pero que serían las siguientes en implementarse. Por ejemplo, en un e-commerce, la inclusión de filtros en el listado de productos aporta mucho valor, pero la tienda online podría funcionar incluyéndolos más adelante.
• Could: son funcionalidades que aportan valor, pero sin las cuales el producto podría funcionar igualmente. Es decir, son features que mejorarían el producto pero, sin ellas, es totalmente funcional. Por ejemplo, las listas de productos favoritos en un e-commerce o las notificaciones de ofertas.
• Won’t: en esta categoría caerían esas funcionalidades que, por diferentes cuestiones (ya sea tiempo, costes, falta de alineamiento con los objetivos…), se descartan.

Para poder llevar a la práctica este modelo, tenemos múltiples opciones y podemos quedarnos con la que más nos encaje e ir iterándola. Aquí te dejamos algunas posibilidades:

• Un tablero en Jira con las columnas Must, Should, Could y Won’t.
• Una pizarra en Miro con una template como esta que te dejamos aquí.
• Una hoja de Excel donde colocar las tareas en forma de lista por categorías
• … ¡O cualquier otra opción que se te ocurra!

Buy a Feature

Buy a Feature es un marco de priorización un poco diferente a los que acabamos de tratar. Se trata de una técnica totalmente colaborativa para que lleves a cabo con tus stakeholders, mediante la cual se simula una especie de juego de “compra de features” donde cada stakeholder tiene una cantidad de dinero para invertir en las funcionalidades que debéis priorizar.

Si te gusta como suena, sigue leyendo que te contamos los pasos a seguir:

1. Crea una lista de todas las funcionalidades que quieres que se prioricen durante la sesión.
2. Pon un precio a cada una de las features, basada en el coste de desarrollo que implicaría. Puedes hacer una traducción desde tu sistema de estimación a este “dinero” que vais a utilizar.
3. Selecciona la cantidad de dinero que va a tener cada stakeholder. La recomendación general es que esté entre un tercio y la mitad del total asignados a las features seleccionadas.
4. Presenta cada funcionalidad y pídeles que las compren. Es importante dejar claro que pueden invertir su dinero de la forma que crean más conveniente.
5. Cuando hayan gastado todo su presupuesto, ordena de mayor a menor prioridad y preséntalo a todos los participantes de la sesión.

💡 Tip: escucha con atención todos sus comentarios mientras toman las decisiones. ¡Seguro que en el futuro te serán muy útiles!

Use Story Mapping

Es una técnica de priorizar que se dibuja en dos dimensiones para ayudar a visualizar de forma muy clara las épicas e historias de usuario.

Como puedes ver en la imagen de ejemplo, tenemos tres conceptos clave:

• Actividades. Son nuestras épicas, es decir, esas “grandes funcionalidades” que vamos a implementar para cumplir con los objetivos de nuestro producto digital.
• Tareas. Son las historias de usuario que obtenemos como resultado de descomponer las épicas en tareas más pequeñas para poder priorizarlas.
• Releases. En esta línea horizontal indicamos en qué versión se van a incluir las historias de nuestro story map.

Una vez tenemos claros estos conceptos, veamos cuáles son los pasos clave:

1. Identificar las actividades a alto nivel y colocarlas en la parte superior.
2. Descomponer las actividades en tareas más pequeñas y colocarlas debajo en línea vertical.
3. Ordenar las tareas de cada vertical de más a menos importante, siempre teniendo el foco en el usuario/a. Podemos hacerlo, por ejemplo, basándonos en el ya mencionado MoSCoW.
4. Dividir las tareas en releases, teniendo en cuenta que cada una de ellas debe aportar valorar por sí misma.

Aunque, como habrás podido ver, este modelo necesita de algún otro framework de priorización, resulta de mucha utilidad para el alineamiento con otros equipos y para favorecer el que todos los miembros del equipo tengan una visión de alto nivel del producto en su conjunto.

Conclusión

Existen muchos frameworks que puedes utilizar para priorizar tu backlog y ninguno de ellos es mejor que otro. Nuestro consejo siempre será que vayas probando, iteres y encuentres el que mejor se adapte a tu producto y situación. ¡Incluso es posible que el que mejor te funciona ahora sea diferente del que vayas a necesitar en el futuro!

Por otro lado, aunque hayamos hablado en todo momento de estos frameworks por su utilidad a la hora de priorizar las historias de usuario del backlog, ten en cuenta que no se limitan solo a esto, sino que pueden ayudarte a priorizar todo tipo de iniciativas e incluso un roadmap. Por ejemplo, una configuración que nos ha funcionado es priorizar el roadmap con la ayuda de MoSCoW (siempre buscando que se alinee con los OKRs) y el backlog con Impacto Esfuerzo. ¡Pero hay miles de combinaciones y tú debes encontrar la tuya!

Así que, recuerda: prueba, experimenta e itera.