PRIORIZACIÓN DE

HISTORIAS DE USUARIO
¿Cómo hacer un buen plan?

 Un buen plan debe estar soportado

por decisiones y acciones confiables

 Deberíamos ir a un esquema de :

Estará terminado en el tercer trimestre

Estará terminado en agosto
Estará terminado el 15 de agosto
 Release 1 Release 2 Release 3

Release Plan

Iteration 1 Iteration 2 Iteration 3 Iteration 4–7

Por cada user

story se detallan
tareas
 Product Backlog As a frequent
Iteration Backlog
flyer, I

3
want to…

As a frequent flyer, I want to…

5

As a frequent flyer, I want to…

5

As a frequent flyer, I want to…

8
En el Sprint Backlog normalmente
detallo las tareas de las users
As a frequent flyer, I want to… stories y las horas que me
5 demandará cada tarea

Estos son los Story points

¿Cómo priorizar las historias de usuario?

 Por qué priorizamos si todo es importante?

 Qué factores hay que tener en cuenta para
priorizar?
 Cómo combinamos esos factores?
Por qué priorizamos si todo es
importante?
 Priorizamos para poder tener una mínima
planificación
 Cuánto tiempo tardaremos en tener listo un producto
con aproximadamente las siguientes funcionalidades?
 Cuánto costará este producto si lo queremos para esta
fecha concreta?
Por qué priorizamos si todo es
importante?

 En las metodologías ágiles la planificación se

realiza constantemente a lo largo del proyecto

 De esta forma se reacciona y se adapta al cambio,

en vez se seguir un plan predefinido
Cómo se planifica en agile?

La planificación consiste en

Priozar la historias de usuario

(Ordenar las tareas por orden de prioridad)

Cómo se planifica en agile?
 No se asignan tareas a los miembros del equipo…
 Elequipo se auto-organiza y cada miembro elegirá
aquella tarea que más prioritaria o ayudará a otros
miembros a completar sus tareas

 No se fijan fechas de entrega al cliente…

 Alcliente se le enseña un producto funcional (y
potencialmente entregable) al final de cada iteración
No sólo hay que priorizar al principio del
proyecto, hay que priorizar en cada
iteración

El contexto cambia, la tecnología cambia,

el equipo cambia, el cliente cambia…
Y también priorizamos porque el desarrollo
software es un proceso con mucha
incertidumbre
Cono de incertidumbre

tiempo
¿Cómo priorizar las historias de usuario?

 Por qué priorizamos si todo es importante?

 Qué factores hay que tener en cuenta para
priorizar?
 Cómo combinamos esos factores?
¿Cómo se prioriza?
 Priorizar es ordenar las historias de usuario en base
a su…

valor coste riesgo

Es una cuestión de equilibrio

¿Cómo se prioriza?
 Valor para el usuario (de la HU)

 El objetivo del equipo es maximizar el valor y la

satisfacción percibida por el usuario en cada iteración,
por eso es muy importante conocer cuánto valor le
aporta cada historia al usuario
 El Product Owner se encarga de valorar cada historia
de usuario
 El equipo lo puede intuir (por su experiencia), pero el
PO tomará la decisión sobre el valor de cada historia
¿Cómo se prioriza?
 Coste de implementación (de la HU)

 Como el coste es muy difícil de saber con precisión,

siempre se habla de estimación del coste

 El coste se estima por el equipo usando técnicas como

el planning poker
It’s quick and fun
¿Cómo se prioriza?
 Riesgo que se mitiga al
implementar (la HU)
 Elriesgo es algo que todavía no ha ocurrido pero que
puede poner en peligro la realización del proyecto
 Hay muchos tipos de riesgos que amenazan a los
proyectos software (revisar Guia)
¿Cómo se prioriza?
 Riesgo que se mitiga al
implementar (la HU)

 Elriesgo de cada historia de usuario es determinado

normalmente también por el equipo

 Enbase a su experiencia y conocimiento (o

desconocimiento) de la tecnología y del dominio,
pueden identificar el riesgo de cada HU
¿Cómo se prioriza?
 Si sólo tenemos en cuenta un criterio, todo es muy
fácil:
 Valor:
 Las HU que más valor aporten, las primeras.
 Coste:
 Las HU que menos cuesten, las primeras, así se podrá
ofrecer el mayor valor posible lo antes posible
 Riesgo:
 LasHU que mitiguen más riesgo, las primeras. Así habrá
margen de maniobra si algún riesgo se manifiesta (o al
menos se podrá fallar lo más barato posible)
¿Cómo priorizar las historias de usuario?

 Por qué priorizamos si todo es importante?

 Qué factores hay que tener en cuenta para
priorizar?
 Cómo combinamos esos factores?
Una metodología para priorizar

1 El product owner y el cliente deciden el valor que aporta

cada historia de usuario
2 El equipo de desarrollo estima el coste de
implementarlas
3 Se ordenan las historias de usuario en base al ratio entre
el coste y el valor de cada una de ellas
 Una historia con valor bajo y alto coste sería poco
prioritaria
 Una historia con alto valor y poco coste sería muy
prioritaria.
4 Partiendo de esa priorización inicial se incorpora el
riesgo
 Si hay una historia con una prioridad media, pero que
mitiga muchos riesgos al implementarse, se debería hacer
más prioritaria.
 Eso hace que las historias que mitigan menos el riesgo bajen
de prioridad.
Priorizar en situaciones típicas…
 Podemos identificar algunas situaciones típicas, en
las que será fácil determinar cómo priorizar
 Valor y coste (sin riesgo)
 Mucho riesgo tecnológico

 Sector desconocido
Priorizando el riesgo

 Cuando el riesgo y el valor son

los factores determinantes, se suele
usar la siguiente gráfica para priorizar
Valor

Alto
X Bajo valor
Alto riesgo
1º Alto valor
Alto riesgo
2
Bajo

Riesgo

3º Bajo valor
Bajo riesgo
2º Bajo valor
Alto riesgo
Técnicas específicas de priorización
Las técnicas específicas…
 MoSCoW
 Theme Scoring
 Análisis de Kano
MoSCoW
 MoSCoW es un
pseudo-acrónimo formado
por las cuatro categorías en las que se tienen que
dividir todas las funcionalidades:
M - Must have: Tiene que estar
 S - Should have: Debería estar si es posible
 C - Could have: Podría estar si no afecta a nada más
 W - Won’t have: No estará esta vez, pero estará en un
futuro
MoSCoW
 MoSCoW es un
pseudo-acrónimo formado
por las cuatro categorías en las que se tienen que
dividir todas las funcionalidades:
M - Must have: Tiene que estar
 S - Should have: Debería estar si es posible
 C - Could have: Podría estar si no afecta a nada más
 W - Won’t have: No estará esta vez, pero estará en un
futuro
Theme Scoring
 Técnica para combinar
criterios de las diferentes
HU de forma analítica (media ponderada)
 Se definen una serie de criterios para cada HU
 Por ejemplo
 Aporta valor al cliente (40%)
 Afecta a la arquitectura del sistema (20%)

 Requiere integración con terceros (30%)

 Lo tiene la competencia (10%)

Theme Scoring
 A cada HU se le asigna
un valor entre 1 y 5 para
cada una de estas características (por comparación
con una HU con esa característica con valor medio)
 Se pondera la importancia de cada característica
 Se calcula la media ponderada de las
características
 Se obtiene una ordenación de todas las HU
Análisis de Kano
 Técnica desarrollada por
Noriaki Kano
 Su objetivo es determinar el valor
ofrecido por cada funcionalidad con
encuestas a los potenciales usuarios
 Mide las espectativas de los usuarios
 Divide las funcionalidades en:
 Esenciales
 Lineales
 Asombrosas
Análisis de Kano
 Esenciales
 Tienen que estar en el producto
obligatoriamente
 Lineales
 Funcionalidades complementarias
 El valor al cliente aumenta en el grado que está
implementada la funcionalidad (por eso se llaman lineales)
 Asombrosas
 Mejoran la satisfacción del cliente en gran medida, aunque
dicha estén poco elaboradas o no sea muy completas
Análisis de Kano
Satisfacción del usuario

Asombrosas
Indiferencia

No implementada Muy elaborada

Esenciales

Lineales

Insatisfacción del usuario

 Análisis de Kano
Satisfacción del usuario

• El usuario no espera esta

funcionalidad pero le gusta si está
• La satisfacción aumenta mucho
aunque la funcionalidad no esté muy
elaborada
Asombrosas
Indiferencia

No implementada Muy elaborada

Esenciales
• Por muy elaboradas que estén, no
aumentan la satisfacción del usuario.
Lineales • Si no están, el usuario estará insatisfecho
• La satisfacción aumenta cuanto más
elaborada está la funcionalidad

Insatisfacción del usuario

Análisis de Kano
 Cuando tenemos dividas las historias de
usuario en estos 3 tipos tenemos que priorizar
 Lo más prioritario es incluir las características
esenciales, porque la falta de alguna de ellas no
sería aceptada por los usuarios
 Posteriormente, se incluirían:
 Funcionalidades asombrosas, que el usuario no espera
y que aportan un alto grado de satisfacción
 Funcionalidades lineales, que también proporcionan
satisfacción al usuario en función de su desarrollo
Caso Práctico - Técnicas de Priorización

1
 Definición del Producto

• Aplicación móvil para aprender y practicar diferentes idiomas.

• Inicialmente sólo se incluirá el Inglés, mientras que las plataformas

soportadas serán iOS y Android. Posteriormente se podrá ampliar la
base de usuarios potenciales añadiendo más idiomas y plataformas (si
el producto tuviera éxito en su fase inicial).

• La aplicación permitirá preparar distintos tipos de certificaciones

oficiales (TOFL, FCE, CEFR, etc).

• Se guardará el progreso del usuario, permitiendo llevar a cabo un

proceso de aprendizaje más personalizado que otras apps similares.

2
 Funcionalidades del Producto (Historias)

A. Como usuario, quiero seleccionar un idioma

B. Como usuario, quiero evaluar mi nivel inicial en el idioma seleccionado

C. Como usuario, quiero interactuar con otros usuarios

D. Como usuario, quiero practicar el Speaking

E. Como usuario, quiero practicar el Reading y Writing

F. Como usuario, quiero practicar el Listening

G. Como usuario, quiero evaluar mi progreso

H. Como usuario, quiero compartir mis resultados en las redes sociales

3
 Técnica 1

Método MoSCoW

• M - Must have (Imprescindibles): A, D

• S - Should have (Importantes): E, F
• C - Could have (Buenas): B, G
• W - Won’t have (Excluidas): C, H

**Como resultado de la aplicación de este método se descartarán

las historias de usuario C y H, y no se incluirán en el producto**

4
 Método MoSCoW

Estimación del Coste

A. Como usuario, quiero seleccionar un idioma => 1

B. Como usuario, quiero evaluar mi nivel inicial en el idioma seleccionado => 2

C. Como usuario, quiero interactuar con otros usuarios

D. Como usuario, quiero practicar el Speaking => 5

E. Como usuario, quiero practicar el Reading y Writing => 3

F. Como usuario, quiero practicar el Listening => 3

G. Como usuario, quiero evaluar mi progreso => 2

H. Como usuario, quiero compartir mis resultados en las redes sociales

5
 Técnica 2

Método de Theme Scoring

Características

• Valor: 50%
• Coste: 35%
• Riesgo: 15%

7
 Método de Theme Scoring II

Valor (0.5) Coste (0.35) Riesgo (0.15) Valoración Prioridad

Historia A 4 5 1 3.9 1

Historia B 1 4 3 2.35 5

Historia D 5 1 5 3.6 2

Historia E 3 3 2 2.85 4

Historia F 3 3 3 3.0 3

Historia G 1 4 2 2.2 6

8
 Lista de Funcionalidades Priorizadas

1. Historia A - Como usuario, quiero seleccionar un idioma

2. Historia D - Como usuario, quiero practicar el Speaking

3. Historia F - Como usuario, quiero practicar el Listening

4. Historia E - Como usuario, quiero practicar el Reading y Writing

5. Historia B - Como usuario, quiero evaluar mi nivel inicial en el

idioma seleccionado

6. Historia G - Como usuario, quiero evaluar mi progreso

9
 Referencias
Agile Estimating and Planning. Mike Cohn. Prentice Hall, 2005

Agile Software Development with Scrum. Ken Schwaber.

Prentice Hall, 2001

The art of Agile Development. James Shore and Shane

Warden. Prentice Hall, 2007

User Stories Applied: For Agile Software Development. Mike

Cohn. Addison-Wesley Professional, 2004