Al nivel del programa o portafolio, normalmente existe un número pequeño de requisitos/historias de usuarios comparado con el nivel del proyecto. El porcentaje de historias de usuarios con un nivel tangible de impacto en valor/negocio, necesidad/usuario es normalmente mucho más bajo que el nivel del proyecto. Eso significa que la selección de técnicas que serán útiles en el nivel del programa o portafolio será menor.
Por ejemplo, el análisis Kano tiene limitaciones porque no habrá “satisfiers” o “exciters” alguno. Sin un número significativo de interesados, especialmente usuarios, el método de 100 puntos tiene valor limitado. La técnica MoSCoW también tiene limitaciones porque no habrá alguna característica de “Nice to have” o “Won´t have” en los niveles de programa o portafolio.
A continuación, presentamos algunas técnicas utilizadas para priorizar las Historias de Usuarios o requisitos en el Backlog de Producto Priorizado, según la base del Valor para el negocio:
1.- Esquema de Priorización MoSCoW: Este esquema deriva su nombre de las primeras letras de las frases “Must Have”, “Should Have, “Could Have” y “Won´t Have”. Este método de priorización es generalmente más efectivo que los esquemas simples. Los niveles están en orden de prioridad decreciente, siendo las Historias de Usuarios “Must Have” aquellas sin las que el producto no tendría valor. Las Historias de Usuarios “Won´t Have” son aquellas que aunque seria bueno tenerlas, no es necesario incluirlas.
2.- Comparación en pares: En esta técnica, se prepara una lista con todas las Historias de Usuarios del Backlog de Producto Priorizado. Luego, se toma individualmente cada Historia de Usuario y se la compara con otra Historia de Usuario de la lista, una a la vez. Cada vez se comparan dos Historias de Usuarios para tomar la decisión sobre cuál de las dos es más importante. A través de este proceso, se puede generar una lista priorizada de Historias de Usuarios.
3.- Método de los 100 Puntos: Dean Leffinwell y Don Widrig (2003) desarrollaron este método. Se debe asignar 100 puntos al cliente para que vote con ellos por las Historias de Usuarios que son las más importantes. El objetivo es dar más peso a las Historias de Usuarios que son de mayor prioridad comparadas con las otras disponibles. Cada miembro del grupo asigna puntos a las distintas Historias de Usuarios, entregando más puntos a las que consideren que son más importantes. Al completar el proceso de votación, se determina la priorización calculando el total de puntos asignados a cada Historia de Usuarios.
4.- Análisis Kano: Fue desarrollado por Noriaki Kano (1984). Implica clasificar las características o requisitos en cuatro categorías que se basan en las preferencias de los clientes:
a) Exciters/Delighters: Características nuevas, o de gran valor para el cliente.
b) Satisfiers: Características que ofrecen valor al cliente.
c) Dissatisfiers: Características que, si no están presentes, pueden causar que al cliente no le guste el producto, pero no afectan el nivel de satisfacción si están presentes.
d) Indifferent: Características que no afectarán al cliente de ninguna manera y deben ser eliminadas.
Análisis Kano
Es interesante que, generalmente con el tiempo, las características se mueven hacia abajo en la lista de clasificación. Los clientes darán por hecho la existencia de características (Ejem. Cámaras en los celulares), y éstas se moverán de ser exciters/delighters a satisfiers y, eventualmente, dissatisfiers.
En resumen: Al nivel de programa o portafolio, normalmente existe un número menor de requisitos/historias de usuarios que al nivel del proyecto. El porcentaje de historias de usuarios con un impacto valor/negocio, negocio/usuario tangible es normalmente mucho más bajo que en el nivel del proyecto. Eso significa que la selección de técnicas que son útiles para el nivel de programa o portafolio, será menor.
Autor: SCRUMstudy
Traducción y adaptación: Enrique Ledesma M.Sc., PMP, TSPM, STC, SPOC, SMC, SDC
Director Ejecutivo de TenStep Ecuador
