Saber identificar y priorizar (ordenar) los ítems de nuestro backlog maximizando su valor, es una responsabilidad que representa un reto para cualquier Product Owner, ya que si bien está claro que debe hacerse en base al valor que aporte al usuario y por ende a la organización, el gran desafío del PO es saber asignar dicho valor.
PRIORIZAR EL BACKLOG
Para priorizar correctamente los requerimientos de nuestro product backlog, el PO generalmente tiene en cuenta el objetivo de producto y de la compañía, pero además surgen las opiniones de los diferentes integrantes del equipo y stakeholders, por lo que esta es una tarea particularmente compleja.
Por este motivo, se suelen utilizar métodos y herramientas como MoSCoW, propuesta de valor (value proposition), la matriz de Eisenhower o el modelo Kano para ayudarnos a eliminar incertidumbre y respaldar nuestras decisiones en los resultados de un proceso.
¿QUÉ ES EL MÉTODO MOSCOW?
Es una técnica de priorización creada por Daig Clegg en 1994, que busca establecer las prioridades para llegar a un entendimiento común entre las partes interesadas
El método MoSCoW es uno de las más utilizados por su simplicidad, podemos comenzar a utilizar cuando nuestro Product Backlog se encuentra desorganizado y lleno de ítems.
El nombre de esta técnica es un acrónimo derivado de la primera letra de la clasificación de los diferentes requisitos que se distinguen en nuestro producto:
Must-have (debe-tener); Should-have (debería-tener), Could-have (podría-tener) y Won’t-have/Would-have (no-tendrá).
Must-have (Debe-tener)
Constituyen el subconjunto mínimo utilizable (MUST) de requisitos que un producto debe cumplir, es decir que necesita para considerarse completo. Estos son los requerimientos que desarrollar obligatoriamente.
Should-have (Debería-tener)
Son aquellas funcionalidades que resultan altamente deseables, pero que no son críticas para el MVP. Deberá desarrollarse si es posible.
Could-have (Podría-tener)
También conocidas como nice-to-have, estas funcionalidades podrían incluirse cuando se disponga de tiempo y recursos. Son un extra prescindible cuando se reducen los tiempos de entrega de nuestro MVP.
Una de las maneras de diferenciarlos de los MUST, es valorando el grado de dolor causado por el incumplimiento del requisito, ya sea medido en término de valor comercial o el número de personas afectadas.
Won’t have/ Would-have (no-tendrá)
Estos requisitos son los que el equipo de producto ha acordado no cumplir como parte de este plazo, son registrados en la lista de requisitos priorizados, para ayudar a determinar el alcance del proyecto y evitar que se introduzcan de una manera “informal”.
Estas funcionalidades puede que sean construidas en el futuro, pero definitivamente, no son parte del alcance del trabajo actual.
PROBLEMAS FRECUENTES
Suele suceder que todas nuestras historias han acabado en los grupos “debe tener” o “debería tener”, muchas veces por satisfacer las demandas de todos, se termina sobrecargando “debe tener” o “debería tener”.
El Product Owner, debe centrarse en desarrollar y obtener comentarios sobre un MPV, el cual tiene que ser lo más reducido posible, para que le permita pivotar con facilidad, así que tendrá que aprender a decir muchas veces que NO.
Algunas de las situaciones comunes por las que las historias acaban ahí suelen ser:
Todo es importante PARA MI.
Cada uno de los participantes tienen diferentes puntos de vista y razones ( KPI´s que cumplir) que pueden sesgarlos a la hora de decidir dónde ubicar las historias de usuario, en este caso el Product Owner debe mantener las decisiones enfocadas en el MPV.
Todo es importante AHORA.
Algunas de funcionalidades no tienen una prioridad tan alta en el momento, pero creemos que será necesaria en un periodo de tiempo relativamente corto, por eso la ubicamos como prioridad ahora para que no termine en la papelera.
EN CONCLUSIÓN,
DSM indica que niveles de esfuerzo obligatorio (Debería-tener) por encima del 60% presentan un riesgo de fracaso para el éxito y la previsibilidad del proyecto, a menos que se comprenda bien el entorno, las estimaciones sean precisas, el equipo esté establecido (según el modelo de Tuckman) y los riesgos externos sean mínimos.