Cómo priorizar el Product Backlog

Una de las principales obligaciones del Product Owner es la de priorizar el Product Backlog.

Esto es especialmente importante ya que, de no hacerlo, no podríamos generar valor de forma iterativa e incremental tal y como dicta Scrum. Solamente priorizando podrás ir poniendo en producción de lo más importante a lo más secundario.

Recuerda que en agilidad debe existir una entrega de valor continua al cliente. Y evidentemente ¿qué le entregarás antes, funcionalidades con verdadero valor de negocio, o aquellas de relleno?

En este post analizaremos esta importante y delicada tarea.

Lo prioritario es lo minoritario

En el software, como en tantas otras facetas de la vida, es importante recordar el principio de Pareto, también conocido como regla del 80-20.

Este principio recibe su nombre por el economista, sociólogo e ingeniero italiano Vilfredo Pareto, que vino a decir con esta regla que estadísticamente para cualquier población que contribuye a realizar algo en particular, es una proporción pequeña de dicha población la que realiza la mayor parte de ese algo.

Es decir, buscando números redondos se puede afirmar que sólo un 20% de dicha población contribuye al 80% de un resultado. Típico ejemplo que se pone es que el 20% de la población posee el 80% de la tierra (por lo menos, eso parecía ser en la época de Vilfredo…).

Este principio estadístico, aunque su proporción es arbitraria, puede generalizarse para muchos otros aspectos, incluido el software. Por tanto, podemos decir que el 80% del valor del software se logra sólo con un 20% de las funcionalidades.

Piénsalo, de las muchas funcionalidades de un procesador de texto, ¿qué porcentaje se lleva la mayoría del valor? ¿qué porcentaje termina utilizando la gente en su día a día?

Esto viene a ilustrar la idea de que, a la hora de crear un producto software, sólo un pequeño porcentaje de funcionalidades son las que verdaderamente otorgan valor al producto. El resto (la mayoría), son funciones que mejoran el producto pero que no son imprescindibles y por tanto no conforman el core del producto. Esto es lo mismo que decir que sólo un pequeño porcentaje de funcionalidades son prioritarias.

Dicho esto, veamos cómo el Product Owner debe priorizar el Product Backlog, discriminando qué es imprescindible y qué no.

Cómo prioriza el Product Owner

El Product Owner debe ser un experto en el negocio y en lo que demanda el mercado y por tanto en el producto que se quiere construir. Esto es lo mínimo que se le puede pedir. De modo que debería tener clarísimo qué es importante y qué lo es menos.

Clasificando los requisitos por importancia

A la hora de definir los requisitos de un producto que aporte verdadero valor a la empresa, el Product Owner no puede dudar a la hora de discernir qué es:

• Imprescindible para aportar verdadero valor de negocio (ese 20% de las funciones que diría Pareto y que aportan el 80% del valor, el core del producto).
• Una considerable mejora del producto, aunque no representa ese core de la solución.
• Mejoras secundarias que añaden lustre y esplendor pero que están lejos de ser necesarias.
• Mejoras nimias que apenas aportan valor. Por tanto, lo más probable es que no se aborden nunca (a no ser que andes sobrado de tiempo y presupuesto, cosa harto improbable).

Si un Product Owner no es capaz de clasificar las funcionalidades del producto entre estos cuatro grupos, empezamos con muy mal pie. Es más, yo diría que el proyecto comenzará sentenciado ya que, si no tenemos esto claro, podemos terminar entregando un bonito producto con poco o nulo valor para la empresa y para el cliente.

Priorizar el Product Backlog en Scrum

Los ítems más importantes estarán al principio del Product Backlog (recuerda, el Product Backlog es una pila). En lo más alto de la pila van los requisitos más prioritarios (con mayor valor de negocio) y hacia abajo irán repartiéndose los demás requisitos, siempre de más importantes a menos.

De la misma forma, a más importante sea el requisito más claro deberemos tenerlo y con menor ambigüedad. Por tanto, el primer ítem del Product Backlog será el más importante para el negocio y el que conoceremos mejor, y el del fondo de la pila será la chorrada más grande que se le ocurrió al Product Owner (o a algún otro stakeholder) y con menor detalle.

¿Cómo puede el pobre Product Owner, a partir de toda una pila de requisitos, separar lo importante de lo irrelevante? En definitiva, ¿cómo podemos priorizar el Product Backlog?

Debemos tener claras estas cuestiones:

• ¿Qué es valioso? ¿cuán valioso es? ¿valioso para quién?
• ¿Qué funcionalidades deberían incluirse dentro de una misma release de producto?
• ¿Cómo secuenciaríamos esas releases?
• ¿Cómo obtenemos la aceptación necesaria para seguir y llevar estas cosas al mercado?
• ¿Nuestras suposiciones son correctas? ¿estamos en el camino correcto? ¿estamos realmente entregando valor? ¿podríamos hacerlo mejor?

Ten en cuenta además a la hora de priorizar el Product Backlog que no sólo hay funcionalidades, representadas mediante historias de usuario. Tenemos también incidencias software o bugs, trabajo técnico, etc.

Por tanto, el Product Owner no siempre podrá priorizar sin la ayuda del DevTeam. Éste cuenta con un profundo conocimiento sobre aquellos requisitos técnicos que pueden resultar imprescindibles en la construcción del producto.

Además, el Scrum Master, en su rol de líder-servidor, deberá proporcionar al Product Owner toda la ayuda que necesite.

Sin priorizar no se puede planificar

Una vez priorizado el Product Backlog, tendremos más claro cuál será la Release Plan, es decir, que releases irán primero, cuál será el MVP o Producto Mínimo Viable, etc.

A su vez, podremos hacer una proyección de los Sprints. No es ni por asomo lo ideal si te decantaste por la filosofía agile, pero a veces desde la dirección nos imponen esta clase de planificaciones que son más waterfall que otra cosa.

Los Sprint irán abordando las funcionalidades de más importante a menos. Un Sprint N no debería abordar una funcionalidad más importante y valiosa que cualquier otra de las funcionalidades desarrolladas en los Sprint 1 y el Sprint N-1.

Existen muchas técnicas o métodos para priorizar el Product Backlog, unos más sencillos y otros más rebuscados. Te presento la Tabla Periódica de Métodos de Priorización de Producto:

El eje horizontal muestra si la información que necesitamos para priorizar viene de dentro o de fuera, es decir, en qué grado dependemos de la información proporcionada por gente ajena al Equipo de Desarrollo del producto.

Unas veces necesitarás la implicación de gente externa para poder priorizar (por ejemplo, clientes finales o stakeholders de dentro de la compañía). Pero en otros casos podrías abordar esta tarea con el Devteam o tú mismo.

El eje vertical muestra si la técnica de priorización en cuestión es más o menos cuantificable. Es decir, en qué grado están basadas en opiniones o por el contrario en alguna clase de métrica.

Vamos a ver algunas de estas técnicas de priorización del Product Backlog con más detalle.

Modelo MoSCoW

Este acrónimo corresponde a Must, Should, Could y Won´t. La idea para priorizar el Product Backlog es muy simple de entender, aunque no tan sencillo de llevar a la práctica.

Consiste en dividir los requerimientos en 4 categorías, de mayor a menor prioridad:

• Must (debe): representa los requisitos imprescindibles. Son aquellos sin los cuales el producto carece totalmente de valor. Deben realizarse correctamente para cubrir lo mínimo que se pide de ese producto. Por tanto, deberían estar incluidos en el MVP del producto.
• Should (debería): requisitos de alto valor que, sin ser imprescindibles, aportan gran calidad al producto y que sin los cuales dicho producto quedaría austero y más bien justito.
• Could (podría): requisitos deseables, pero no necesarios. Se realizarán si el tiempo y los recursos lo permiten.
• Won´t (no se harán a corto plazo): requisitos que, por su poco aporte de valor, no se abordarán por el momento, aunque podrían considerarse en el futuro.

Personalmente, MoSCow me resulta de los modelos de priorización más interesantes por su sencillez, junto con el modelo de Kano.

Veamos un ejemplo bastante conocido que ilustra cómo se puede aplicar MoSCow.

Ejemplo de MoSCoW: la hamburguesa

Si tuvieses que preparar una hamburguesa, ¿cómo priorizarías sus ingredientes?

• La carne (o sustitutivo, si eres vegetariano) es imprescindible, es el must. Sin ello, no hay hamburguesa que valga.
• El pan no es imprescindible, ya que te puedes comer la hamburguesa en un plato con cuchillo y tenedor. Pero estarás conmigo en que sin el pan de sésamo la cosa pierde muchísimo. Sería un should.
• Queso, tomate, lechuga… dan bastante gracia a la hamburguesa. La enriquecen, pero no ocupan el puesto de importancia de los dos ingredientes previos. Son un could.
• Los pepinillos, bueno… A no ser que seas muy fanático de ellos son un ingrediente más bien prescindible. Serían un won´t.

Modelo Valor vs Coste

En este modelo no sólo se tiene en cuenta el valor de negocio del requisito, también el coste de llevarlo a cabo (algo muy sensato por otra parte).

Ilustra una idea muy semejante al indicador financiero ROI, que representa la relación entre beneficio obtenido frente a la inversión realizada.

En función de ambos parámetros, valor y coste, clasificamos los requerimientos dentro de cuatro áreas, en la llamada Matriz de Valor vs Coste:

Las Historias de Usuario se puntúan según su valor y coste de implementación. En base a esta puntuación, la historia de usuario caerá en una de estas cuatro áreas de la matriz y determinará su grado de prioridad.

El coste no tiene que significar necesariamente dinero. Puede hacer referencia al esfuerzo o complejidad de desarrollo, por lo que este método también se denomina a menudo Valor vs Esfuerzo o Valor vs Complejidad o Bang for the buck, que referencia a una expresión coloquial que podríamos traducir como saca el mayor provecho por tu pasta, o algo así.

El objetivo principal de este método es que intentamos maximizar la entrega de valor a lo largo del tiempo. Es decir, si trabajamos con un plazo de lanzamiento determinado, trabajamos en los elementos más valiosos que podemos incluir en el período. De esta forma no centramos en lo más valioso con el menor esfuerzo posible.

Representación gráfica del Modelo Valor-Coste

Este modelo suele representarse mediante dos formas: Matriz de Valor vs Coste y Diagrama de Dispersión.

La Matriz de Valor vs Coste es el cuadrante que hemos visto antes. Mediante el uso de esta matriz podemos entender este modelo de forma bastante sencilla.

Comenzaríamos con las historias de usuario de alto valor y bajo costo (área roja, lo que hay que hacer ya!!) y luego pasaríamos a aquellas de alto valor y alto costo (área naranja, lo siguiente que debemos abordar).

Respecto a las historias de bajo valor y bajo costo (área azul), debemos evaluar a lo largo de los Sprints si nos merece la pena desarrollarlas o no, ya que pueden representar ciertas mejoras a nuestro producto. Debemos ser cuidadosos con las historias que caigan en esta área, ya quese suele tener tendencia a priorizar los requisitos de bajo costo y bajo valor (que tienen buenas relaciones valor-costo). No debemos caer en quitar tiempo (dentro de lo razonable) a los desarrollos de cuestiones más importantes (pero más complejas) frente a aquellas más fáciles de desarrollar pero menos útiles.

Las historias de bajo valor y costo alto (área gris) evidentemente ni las contemplamos.

Otra forma de visualizar esta técnica es a través de un diagrama de dispersión, que se crea en base al puntaje en cada dimensión.

La prioridad la determinará la pendiente de las líneas que van desde el origen a cada puntuación. A mayor pendiente, mayor prioridad.

Modelo de Kano

Esta técnica para priorizar el Product Backlog es muy popular y guarda semejanza con el método MoSCoW. Fue desarrollada en los 80s por el profesor Noriaki Kano.

Se utiliza para clasificar y priorizar requisitos en función del grado de satisfacción del usuario, dividiéndolos en cuatro categorías:

• Requisitos obligatorios (básicos o Must-be). No provocan satisfacción si están implementados, pero su falta provocaría insatisfacción absoluta ya que son lo mínimo que se espera.
• Necesidades (esperado, lineal o Performance). Estos requisitos aumentan la satisfacción del cliente. Si se los encuentra lo agradecerá y cuantos más se encuentre de este tipo mayor será su satisfacción.
• No esperados (inesperado, excitante o Attractive). Estos requisitos también aumentan la satisfacción del cliente, pero al contrario de los anteriores no se los espera a priori, de modo que su prioridad es menor que los anteriores. De todas formas, no se deben echar en saco roto ya que puede ser la diferencia entre un producto bueno y otro excelente.
• Indiferentes. El cliente no está interesado en ellos de modo que no aportan nada al producto, ni bueno ni malo.

Como se puede observar, el matiz es semejante al MoSCoW pero no es lo mismo: aquí el enfoque corresponde al grado de satisfacción del cliente. Que algo entusiasme al cliente no necesariamente implica que sea prioritario y viceversa. 

Ilustrando los grados de satisfacción del cliente: un bar

Imagina que entras en un bar. Te encontrarás con los siguientes requisitos:

• Obligatorios. Qué menos que el local cumpla con unos mínimos de higiene, que tenga las bebidas habituales, que el camarero no sea grosero… Estos requisitos no provocan satisfacción ya que son lo mínimo que se despacha, pero su falta provocaría que no volviésemos a pisar ese bar.
• Necesidades. Serían requisitos que aumentan la satisfacción del cliente: que no sea muy caro, que tenga una carta variada, que tenga televisión, etc.
• No esperados. Requisitos que también aumentan la satisfacción del cliente, pero al contrario de los anteriores los considera un extra: hay WiFi, ofrecen tapa gratis con la bebida, hay actuaciones en vivo, etc.
• Indiferentes. Requisitos que apenas interesan al cliente, por ejemplo, ciertas cuestiones de la decoración del lugar en los que apenas reparemos.

Cómo funciona el modelo de Kano: cuestionarios

Para la clasificación se suelen usar cuestionarios a los usuarios. Dicho cuestionario hará dos preguntas:

• Pregunta Funcional: ¿cómo te sientes si el producto presenta ese requisito?
• Pregunta Disfuncional: ¿cómo te sientes si el producto NO presenta ese requisito?

Y las posibles respuestas que pueden darte para ambas son cinco posibles:

• Me gusta.
• Es lo que esperaba (es lo mínimo que se despacha!!!).
• Me es indiferente.
• Podría tolerarlo (es decir, comienza a no gustarme, pero bueno…).
• Me disgusta.

Para cada par de respuestas (funcional y disfuncional) usamos esta tabla para determinar la categoría en la que caen los encuestados, según qué requisito le estemos preguntando. Esto nos permite saber el grado de satisfacción del cliente acerca de la funcionalidad en particular.

Puede entrar en dos niveles de análisis:

• Discreto: cada par de respuestas se clasifica utilizando la tabla anterior y la categoría de la característica será la más frecuente entre todos los encuestados;
• Continuo: cada respuesta funcional y disfuncional obtiene una puntuación numérica, que luego puede promediarse sobre todos los encuestados y trazarse en un gráfico:

Ni que decir tiene que, como regla general, los requisitos deben priorizarse en este orden:

Must-Be ⇒ Performance ⇒ Attractive ⇒ Indifferent

¿Para qué priorizamos en agile?

En los proyectos Waterfall no se pone tanto foco en este aspecto de la priorización. El motivo es porque se va a ir desarrollando en fases todo el producto y antes o después tendremos construidas todas las funcionalidades, tanto las más importantes como las menos.

En mi opinión (y en la del paradigma agile), este es un enfoque equivocado. Nadie te garantiza que el proyecto no se quede sin presupuesto, o que se alargue en demasía, o que la competencia te pise los talones… En resumen, nadie te asegura que no ocurrirá un imprevisto que obligue a ponerlo en Producción antes de tiempo.

Por tanto, asegúrate de que lo importante se construye primero y ya habrá tiempo de abordar las chorradas. Y es que la necesidad de priorizar procede de un hecho evidente: nuestros recursos (tiempo, dinero) son limitados.

La necesidad de priorizar procede de un hecho evidente: nuestros recursos (tiempo, dinero) son limitados.

Reflexión final

Priorizar el Product Backlog, como habrás observado, tiene su ciencia. En este post se han comentado los tres métodos más populares pero no son los únicos.

Recuerda que, para ser coherentes con la filosofía Scrum de entregar valor de forma iterativa e incremental, debemos entregar de lo más valioso a lo menos.

La primera release que pongamos en producción, el MVP,  contendrá los ítems del Backlog de máxima prioridad. Es decir, todos los must del método MoSCoW o del método Kano.

Y recuerda, Product Owner. Si tuvieses que hacer sólo una tarea sobre el producto del que eres responsable, ésta debería ser definir los requisitos de negocio y priorizarlos.