A continuaci\u00f3n, presentamos algunas t\u00e9cnicas utilizadas para priorizar las Historias de Usuarios o requisitos en el Backlog de Producto Priorizado, seg\u00fan la base del Valor para el negocio:<\/p>\n
1.- Esquema de Priorizaci\u00f3n MoSCoW:<\/strong>\u00a0Este esquema deriva su nombre de las primeras letras de las frases \u201cMust Have\u201d, \u201cShould Have, \u201cCould Have\u201d y \u201cWon\u00b4t Have\u201d. Este m\u00e9todo de priorizaci\u00f3n es generalmente m\u00e1s efectivo que los esquemas simples. Los niveles est\u00e1n en orden de prioridad decreciente, siendo las Historias de Usuarios \u201cMust Have\u201d aquellas sin las que el producto no tendr\u00eda valor. Las Historias de Usuarios \u201cWon\u00b4t Have\u201d son aquellas que aunque seria bueno tenerlas, no es necesario incluirlas.<\/p>\n 2.- Comparaci\u00f3n en pares:<\/strong>\u00a0En esta t\u00e9cnica, se prepara una lista con todas las Historias de Usuarios del Backlog de Producto Priorizado<\/strong>. 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\u00f3n sobre cu\u00e1l de las dos es m\u00e1s importante. A trav\u00e9s de este proceso, se puede generar una lista priorizada de Historias de Usuarios.<\/p>\n 3.- M\u00e9todo de los 100 Puntos:<\/strong>\u00a0Dean Leffinwell y Don Widrig (2003) desarrollaron este m\u00e9todo. Se debe asignar 100 puntos al cliente para que vote con ellos por las Historias de Usuarios<\/strong> que son las m\u00e1s importantes. El objetivo es dar m\u00e1s 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\u00e1s puntos a las que consideren que son m\u00e1s importantes. Al completar el proceso de votaci\u00f3n, se determina la priorizaci\u00f3n calculando el total de puntos asignados a cada Historia de Usuarios.<\/p>\n 4.- An\u00e1lisis Kano:<\/strong>\u00a0Fue desarrollado por Noriaki Kano (1984). Implica clasificar las caracter\u00edsticas o requisitos en cuatro categor\u00edas que se basan en las preferencias de los clientes:<\/p>\n a) Exciters\/Delighters: Caracter\u00edsticas nuevas, o de gran valor para el cliente. <\/p>\n An\u00e1lisis Kano<\/strong><\/p>\n Es interesante que, generalmente con el tiempo, las caracter\u00edsticas se mueven hacia abajo en la lista de clasificaci\u00f3n. Los clientes dar\u00e1n por hecho la existencia de caracter\u00edsticas (Ejem. C\u00e1maras en los celulares), y \u00e9stas se mover\u00e1n de ser exciters\/delighters a satisfiers y, eventualmente, dissatisfiers.<\/p>\n En resumen:<\/strong>\u00a0Al nivel de programa o portafolio, normalmente existe un n\u00famero 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\u00e1s bajo que en el nivel del proyecto. Eso significa que la selecci\u00f3n de t\u00e9cnicas que son \u00fatiles para el nivel de programa o portafolio, ser\u00e1 menor.<\/p>\n Autor: SCRUMstudy<\/p>\n Traducci\u00f3n y adaptaci\u00f3n: Enrique Ledesma M.Sc., PMP, CDAI\/DALSM, STC, SPOC, SMC, SDC<\/p>\n","protected":false},"excerpt":{"rendered":" Al nivel del programa o portafolio, normalmente existe un n\u00famero peque\u00f1o 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\u00e1s bajo que el nivel del proyecto. Eso significa que la selecci\u00f3n de t\u00e9cnicas que ser\u00e1n […]<\/p>\n","protected":false},"author":26,"featured_media":8873,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[329,254,917],"tags":[1562,1563,232,1564,1565,1566,1567,227,1509,1568,1511,287,1569,1570,1571],"class_list":["post-8871","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agil","category-comunicacion","category-scrum","tag-analisis-kano","tag-comparacion-en-pares","tag-direccion-de-proyectos-2","tag-esquema-de-priorizacion-moscow","tag-historias-de-usuarios-del-backlog-de-producto-priorizado","tag-metodo-de-100-puntos","tag-metodo-de-los-100-puntos","tag-pmbok","tag-pmp","tag-priorizacion-de-las-historias-de-usuarios","tag-sbok","tag-scrum","tag-seleccion-de-tecnicas-priorizacion","tag-tecnica-moscow","tag-todo-sobre-la-priorizacion-de-las-historias-de-usuarios"],"acf":[],"yoast_head":"\n
\nb) Satisfiers: Caracter\u00edsticas que ofrecen valor al cliente.
\nc) Dissatisfiers: Caracter\u00edsticas que, si no est\u00e1n presentes, pueden causar que al cliente no le guste el producto, pero no afectan el nivel de satisfacci\u00f3n si est\u00e1n presentes.
\nd) Indifferent: Caracter\u00edsticas que no afectar\u00e1n al cliente de ninguna manera y deben ser eliminadas.<\/p>\n![\"Analisis](\"https:\/\/proyectum.com\/pe\/wp-content\/uploads\/2020\/09\/Analisis-KANO.png\")
<\/p>\n