En el momento en que ya tienes una colección de historias de usuario en tu product backlog (además de las features, requerimientos, mejoras, cambios y correcciones, entre otros), necesitas asignarles prioridad.
Si trabajas con Scrum, en el momento en que ya tienes una colección de historias de usuario en tu product backlog, además de features, requerimientos, mejoras, cambios y correcciones, entre otros, necesitas asignarles orden, estimación y valor para que sean seleccionables para el siguiente Sprint.
Tu objetivo como Product Owner debería ser, en primer lugar, entregar las historias de mayor valor a tus usuarios o negocio. Como ya comentamos en el quinto mandamiento, cada historia incluye el valor para el usuario, pero puede ser difícil darle prioridad a una historia en base únicamente a esa idea, a veces poco clara y otras demasiado obvia.
Para priorizar correctamente, el Product Owner debe utilizar una gran cantidad de variables, métodos y herramientas. En las siguientes páginas, repasaremos algunos de los métodos de priorización más utilizados y respetados: MoSCoW, Kano y el mapa de historias.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
MoSCoW
MoSCoW es un método de priorización a medio plazo. Consiste en ordenar tus historias de usuario en diferentes categorías:
M - Debe tener (Must have): Lo que se describe en la historia de usuario hay que desarrollarlo obligatoriamente.
S - Debería tener (Should have): La historia de usuario deberá desarrollarse si es posible.
C - Podría tener (Could have): Podría desarrollarse, pero no es imprescindible para los usuarios o los equipos de negocio.
W - No tendrá (Won’t have): No se incluirá a medio plazo, pero podría ser útil en una versión posterior.
Organizar un grupo de trabajo MoSCoW con partes interesadas de diferentes ámbitos puede ser una gran forma de empezar a priorizar tu backlog, pero este método conlleva ciertas limitaciones.
Por ejemplo, los participantes suelen pensar que «todo es importante», así que todas las historias suelen acabar en los grupos «debe tener» o «debería tener». Esto pasa a menudo porque todo el mundo tiene un punto de vista diferente y cada historia es importante para alguien concreto.
También sucede en empresas en las cuales suelen darse expectativas poco realistas o cuando los Product Managers o Project Managers no saben decir NO. En estas culturas, los participantes están convencidos de que cualquier cosa que se coloque en «podría tener» o «no tendrá» puede acabar también en la papelera.
El Product Owner tiene la responsabilidad de promover una mentalidad positiva y enfocada a la creación de valor para el usuario y el negocio, y evitar la competitividad entre departamentos o personas respecto a lo que debería construirse.
Kano
Este método lo creó Noriaki Kano en 1984, inspirado por la asimetría de la satisfacción e insatisfacción de los usuarios con una feature. Algunas features pueden ofrecer poca satisfacción cuando están presentes, pero su ausencia puede provocar a su vez una gran insatisfacción.
Si tu product backlog es bastante maduro y completo, el método Kano te permitirá priorizar las features principales que quieres incluir en tu producto. Este método también es colaborativo y debería llevarse a cabo en un grupo de trabajo de cuatro pasos con varios participantes:
Paso 1:
Identifica las features que necesitas priorizar. Ten en cuenta que una feature no tiene por qué equivaler a una historia de usuario, sino a la suma de varias; esto se definirá según tu producto y lo específicas que sean tus historias de usuario.
Paso 2:
Plantea estas preguntas a cada miembro del grupo de trabajo:
- El producto incluye esta feature. ¿Qué opinas? (perspectiva funcional).
- El producto no incluye esta feature. ¿Qué opinas? (perspectiva disfuncional).
Los participantes escogerán entre las siguientes respuestas:
- Me gusta
- Esperable
- Neutral
- Puedo aceptarlo
- No me gusta
Paso 3:
Compara las discrepancias entre las perspectivas funcionales y disfuncionales y clasifica las features en estos tipos:
- Funcionalidades esenciales u obligatorias (O): esas son las features principales de tu producto que no se pueden excluir.
- Funcionalidades lineales (L): Llamadas así porque, añadiendo más funcionalidades lineales, se incrementará en valor de tu producto de forma proporcional.
- Funcionalidades excitantes (E): No son esenciales, pero pueden ser un gran añadido y complacer a los usuarios.
- Funcionalidades contradictorias (C): Para los casos en los que exista una gran diferencia de opiniones entre los participantes del grupo de trabajo. Podrían requerir más investigación.
- Cuestionables (Q): Tendrías que intentar averiguar por qué estas features gustan tanto o tan poco. Con suerte, esto no debería de pasar muy a menudo.
- Indiferentes (I): La gente suele ser indiferente a esas features y, lógicamente, no deberían ser una prioridad. Con suerte podrás iterar sobre ellas para meterlas en las categorías O, E o L.
Paso 4: Visualiza tus resultados en un diagrama
Este método nos parece particularmente interesante porque se basa en la percepción que los usuarios tienen del producto y suele revelar expectativas sorprendentes de algunas de las partes interesadas.
Mapa de historias
En el cuarto mandamiento ya hablamos en profundidad de los mapas de historias. El aspecto visual de este enfoque es muy bueno para ayudarte a construir tu product backlog, y también para ayudarte a priorizarlo.
Por ejemplo, os ofrece a ti y a tu equipo una forma muy buena de visualizar la prioridad de las features principales de alto nivel de tu producto (como ya comentamos en el cuarto mandamiento).
Otra cosa muy útil de los mapas de historias es la habilidad para observar interdependencias entre features de alto nivel y ver la priorización desde la perspectiva del recorrido del usuario, así como para ofrecerte una visión clara de qué features podrían ser menos prioritarias o puramente técnicas.
En conclusión, la clave para priorizar tu backlog adecuadamente es hacerlo colaborando con varias partes interesadas y entendiendo el valor de tu producto, así como sus fortalezas y debilidades, desde varias perspectivas y utilizando una serie de criterios diferentes.
Esto te permitirá entender el valor de una feature desde un punto de vista más global, permitiendo que decidas de forma efectiva qué features deberían desarrollarse primero y cuáles pueden esperar a más adelante en el ciclo de vida de tu producto.
Para saber más: descarga nuestro libro Las Claves del Product Management
