No sólo en el mundo ágil, en general, a lo largo de la historia de los requisitos software, bien sean en su formato clásico, en las ideas más tradicionales de “cerrar requisitos”, en agilidad, en historias de usuario, etc., de siempre, el tema de la “priorización” de requisitos ha sido un clásico, de siempre.
Por “defecto” todos sabemos que así, simplificadamente, el product backlog se prioriza por valor, según el valor que cada ítem en el mismo aporta a negocio, siendo responsabilidad del product owner asignar (o averiguar) dicho valor y, por ello, de priorizar el product backlog.
Y sabemos que priorizar por valor y esfuerzo o complejidad de desarrollar ese ítem no es algo que esté muy bien visto, ya sabes, y lo hemos contado en los post de #noestimates (véase ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado), eso me llevaría a hacer software malo.
Pero dicho lo anterior, a la hora de la verdad, priorizar el product backlog genera bastantes dudas. Hay quien quiere poner muchas cosas a prioridad número 1 (que básicamente es como no priorizar nada), hay quien se pierde con tanta cosa en el product backlog que no sabe cómo priorizar, etc., hay de todo.
Y es por ello por lo que en los últimos años, en el mundo ágil, han ido apareciendo diferentes técnicas de priorización de requisitos, ítems, historias de usuario, etc., dicho sea de paso, muchas de ellas son adaptaciones de “clásicos” a la era ágil.
Bueno, con todo, en este post te voy a dejar una selección de las técnicas de priorización en product backlog, las que yo más uso, pero me encantaría conocer otras, para ello tienes a tu disposición la sección de comentarios. Vamos…
Filtro de priorización
En 2008, Corey Ladas (el autor de «Scrumban») difundió el «filtro de prioridad». Que lo que hacía, y puedes leer una explicación más detallada aquí, era dividir el product backlog en varias columnas, según prioridad.
En su filtro de priorización, las columnas se etiquetan de izquierda aderecha como prioridad 3, prioridad 2 y prioridad 1. A su vez, cada columna tiene un WIP (te dejo un post sobre el WIP, por si no conoces esto del WIP), es decir, un límite máximo de requisitos que puede haber en cada columna. Típicamente, la columna prioridad 1 tiene límite 1, sólo puede contener un requisito, ítem o historia de prioridad 1.
Imagen extríada de http://leansoftwareengineering.com/2008/08/19/priority-filter/
También aportaba una justificación de prioridad:
Prioridad 1: Un ítem en el que estamos trabajando actualmente o existe la intención de trabajar en él en forma inmediata.
Prioridad 2: Un elemento que debería estar listo en la mayor brevedad posible.
Prioridad 3: Un ítem que el que debemos trabajar en breve.
Pirámide de Priorización
Derivado del anterior, encontré otro método curioso, de un tal Tomas Rybing, el método de la pirámide de priorización. Utiliza las mismas ideas que el «filtro de prioridad» pero en vez de usar columnas dibuja un product backlog en forma de pirámide.
Imagen extriada de https://theagileist.wordpress.com/2014/12/08/priority-pyramid/
– Prioridad uno, parte superior de la pirámide, con la más alta prioridad, al ser la parte de la pirámide con menos área sólo debería entrar un ítem.
– Prioridad dos, en el centro de la pirámide. Esto es para las tareas se iniciarán tan pronto como se disponga de recursos
– Prioridad tres, en la parte inferior de la pirámide, donde, al ser más amplia, puede haber más ítems.
Por debajo de la base de la pirámide estarían el resto de ítems.
Esta técnica usa también el la técnica de los WIP. Puedes encontrar más detalle aquí.
MoSCoW y Kano
Ambos son bastante similares, por ello los agrupo.
Al modelo Kano ya le dedicamos un post en 2012, ¿Qué espera el usuario de tu producto? Modelo Kano o cómo priorizar requisitos en una metodología ágil, y junto con el MosSCoW, ambos están incluidos con más detalle en el libro “Gestión de Proyectos Ágiles …y las experiencias de más de 12 años de proyectos ágiles”
El modelo Kano, de los 80, se utiliza para clasificar y priorizar requisitos en función de lo que satisfarán al usuario. Y se basa en dividirlos en cuatro tipos:
– Requisitos obligatorios (básicos).
– Necesidades (esperado, lineal).
– No esperados (inesperado, excitante).
– Indiferentes. El cliente no está interesado en ellos.
MoSCoW hace algo similar, utilizando otros cuatro tipos, que forman el acrónimo: Must (obligatorios), Should (deberían estar), Could (podrían) y Won’t (por ahora los dejamos).
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
muchas gracias por la información, conoces algúna herramienta que pueda ayudarnos a generar proyectos agiles de forma libre tipo jira?