Indice de contenidos
Priorización vs ordenación
Hace tiempo se cambió la palabra priorización por ordenación en la guía scrum, pero ¿por qué? Pues el principal motivo es que un Product Backlog tiene que estar ordenado y la ordenación del Backlog por prioridad (utilizando un criterio) es una manera de hacerlo.
Cuando hablamos de priorización teniendo en cuenta un elemento clave para asignar dicha prioridad, lo más normal y generalmente nos referimos a que estamos comparando dos ITEMs del Backlog y nos quedamos con el menor o el mayor y al siguiente elemento para comparar la siguiente pareja. Es un proceso simple y lógico, en el caso que las solicitudes de las necesidades se realizan por la misma persona o un grupo de personas que entienden lo mismo con dicha prioridad, además de estar de acuerdo en la prioridad, no obstante esto se complica si hay varios peticionarios y cada uno tiene su propia prioridad, al final el reto se traslada al Product Owner para que ordene esa demanda.
En la gestión de producto, un Product Owner debe de tener una visión global y holística de todo el producto para ordenarlo, eso le va a llevar a tener en cuenta varios elementos, por ejemplo: ROI (a menudo a largo plazo), coste, criticidad, dependencias, etc.
Para el/la Product Owner se debe tener en cuenta todo el Product Backlog para la ordenación del mismo. Cuando hablamos de ordenación nos referimos al orden en el cual los PIBs serán entregados a los clientes o el mercado. Al tener un Product Backlog Ordenado, los Developers de Producto pueden tenerlo en cuenta a la hora de seleccionar los elementos para trabajar en ellos durante la Sprint Planning, teniendo en cuenta el Sprint Goal.
No está garantizado que el Product Backlog esté ordenado
–Scrum.org
Técnicas de priorización
Entender la importancia de la priorización va más allá de simplemente listar los elementos del Product Backlog. Implica tomar decisiones que estén alineadas con la visión del producto, los objetivos de la organización y, sobre todo, las necesidades de los clientes. Al elegir cuidadosamente qué características entregar primero, el Product Owner puede maximizar el valor que el producto ofrece, minimizando el riesgo de invertir recursos económicos en características que resuenen con la audiencia.
El método MoSCoW
MoSCoW es un enfoque sistemático para categorizar los PBIs o necesidades en cuatro categorías distintas, identificadas de la siguiente manera:
- Must (M): Estas características son fundamentales para cumplir con el propósito primario del producto.
- Should (S): Se refiere a características que, aunque son importantes, no son críticas para el lanzamiento inicial. El producto puede operar de manera efectiva sin ellas.
- Could (C): Esas funcionalidades o necesidades que proporcionan beneficios adicionales a segmentos específicos de usuarios. PBIs que podríamos tener en próximas versiones
- Won’t (W): Estas características podrían no estar alineadas con los objetivos actuales por temas de coste, inversión, etc. Asi que, de momento las dejamos de lado.
El método MoSCoW, es una herramienta para empezar y es fácil de usar, pero, sigue siendo una hipótesis estratégica. Solo sabremos lo que aporta y lo que no una vez entregamos y validamos con el mercado y los usuarios las funcionalidades o caracteristicas, mientras tanto, todo es hipotético.
El modelo Kano
Un PO puede utilizar el modelo de Kano para trabajar con los Stakeholders para categorizar y clasificar los PBIs en 5 categorías:
- Necesidades básicas: Esas necesidades fundamentales que nuestros clientes están esperando, no son cosas extraordinarias, pero sin ellas nuestros clientes pueden estar disgustados o frustrados.
- Necesidades de rendimiento o performance: Aquellas necesidades que hacen más feliz o satisfecho al cliente o usuario.
- Necesidades emocionantes: Estas necesidades hacen disfrutar al cliente además de aventajar nuestro producto de la competencia, son funcionalidades crucial pero generan un sentimiento o sensación muy positiva en el cliente o usuario
- Necesidades indiferentes: estas características no suelen tener un gran impacto en la satisfacción de los clientes o usuarios. Por lo tanto, es mejor reducirlas.
- Necesidades inversas u opuestas: estas funcionalidades o necesidades suelen generar dolor, frustración o insatisfacción de algunos usuarios o clientes. Y como es obvio es mejor evitarlas a toda costa.
Con esta información el Product Owner puede tener información relevante para tomar las mejores decisiones para ordenar su Product Backlog.
El método RICE
El método RICE tiene un enfoque basado en datos, este método puede ser utilizado por equipos de diferentes sectores (por ejemplo el de marketing) para priorizar características o proyectos, evaluando el Alcance, Impacto, Confianza y Esfuerzo de cada uno/una. Es útil para gestionar un gran número de solicitudes y ayudar al Product Owner a organizar de manera efectiva el Product Backlog, tomando decisiones sobre qué proyectos, features o PBIs en general priorizar:
- Alcance: Hay que evaluar el volumen y el número de usuarios que serán afectados por una funcionalidad o característica. Puede ser un porcentaje de usuarios o un segmento específico de clientes.
- Impacto: Se debe medir el posible impacto (o potencial impacto: es hipotético, no lo sabemos de antemano) de las características, funcionalidades o necesidades en la satisfacción del usuario, el engagement del usuario o cliente, ROI o cualquier otra métrica relevante para el producto y organización.
- Confianza: Evaluar el nivel de confianza en las estimaciones del alcance e impacto que se hicieron previamente. Las funcionalidades con más incertidumbre deberían tener puntuaciones de confianza más bajas.
- Esfuerzo o Coste: Estima los recursos (tiempo, dinero, esfuerzo, etc.) necesarios para desarrollar la funcionalidad.
Buy a Feature
El modelo de priorización Buy-a-Feature es uno de los muchos marcos de trabajo que los Product Managers o Product Owner pueden utilizar. Ayuda a las organizaciones a identificar las características que los clientes y los Stakeholders valoran más. Los Product Owners pueden aprovechar Buy-a-Feature para involucrar a los Stakeholders en la conformación de sus productos y priorizar las características según el retorno de valor esperado (que es hipotético).
Buy-a-Feature es un enfoque para priorizar el desarrollo de un producto. El equipo del producto trabaja directamente con un grupo de Stakeholders para aprender qué características o mejoras del producto valoran más los stakeholders.
Dejamos por aqui una plantilla de miro para poder facilitar una sesion de Buy A Feature: https://miro.com/miroverse/buy-a-feature-prioritization-technique/
Otros Modelos/Técnicas de priorización
Hablaremos de cada uno de estos en próximos artículos
- Cost of Delay:
- CD3 (Cost of Delay / Duración o esfuerzo)
- Business Value
Priorizar características de manera efectiva requiere entender profundamente el propósito del producto y las necesidades de los usuarios, a partir de ahi podemos empezar a utilizar métodos como MoSCoW, Kano, Buy a Feature, RICE o cualquier otro modelo o método. Combinar estos enfoques puede optimizar la toma de decisiones. Es crucial considerar el contexto del producto, como su etapa de desarrollo y las condiciones del mercado, para ajustar el roadmap del producto de forma que se mantenga relevante y efectivo. Dominar esta habilidad es clave para el éxito del producto y la consecución de los objetivos comerciales para un buen product owner.
