Priorizar Historias de Usuario

La calidad de un sistema se mide por el grado de satisfacción que le proporciona al usuario, es por ello que resulta de gran importancia saber identificar y priorizar las funcionalidades que deberá incluir el sistema a desarrollar. Dentro de las metodologías ágiles se considera la priorización de Historias de Usuario en función del valor que le aportan al cliente y es responsabilidad del Product Owner desempeñar esta tarea, así como mantener actualizado su valor durante toda la vida del proyecto.

Para llevar a cabo la priorización de Historias de Usuario, existen diferentes técnicas que pueden ser empleadas, las cuales se basan en los objetivos del negocio, aceptación en el mercado y/o recursos disponibles. A continuación hablaremos de algunas de ellas.

Técnicas de priorización de Historias de Usuario

Test de Asunción. Se basa en construir primero la funcionalidad más importante pero de la que se tiene mayor inseguridad, con la finalidad de tener control sobre los riesgos y saber la aceptación que tendrán los usuarios sobre una idea de negocio. Está técnica puede ser empleada al desarrollar un software nuevo.

1. Como primer paso se requiere agregar un valor de asunción a cada Historia de Usuario, cuando exista mayor inseguridad sobre la funcionalidad, se deberá agregar un valor más alto.

2. En segundo paso se debe asignar un valor de importancia para el usuario a cada Historia de Usuario, entre mayor importancia tenga, mayor deberá ser el valor asignado.

3. Como tercer y último paso se debe sumar los valores de asunción e importancia, los resultados deberán ordenarse de mayor a menor para lograr tener priorizado nuestro Backlog.

Ejemplo:

Asignación de valores

Backlog Priorizado

Método MoSCoW. Es un acrónimo del inglés para definir los cuatro niveles de prioridad que las Historias de Usuario deben tener de acuerdo a lo siguiente:

M -Must have -Debe Tener para considerar el producto exitoso. Se identifica al contestar ¿Qué pasaría si no incluimos esta funcionalidad? Si la respuesta afecta el éxito del proyecto, debe incluirse en esta categoría.

o

S -Should have -Debería Tener. Funcionalidad importante pero no necesaria o que puede ser satisfecha de otra forma.

C -Could have -Podría Tener (si el tiempo y recursos lo permiten)

o

W -Won’t have -No se incluirán en la versión, pero podrían estarlo en un futuro

Ejemplo: