La priorización de historias de usuario (versión ampliada)

PRIORIZACIÓN DE

HISTORIAS DE USUARIO

Madrid Agile – 29 Enero 2014

intentando hacerlo bien!

Quién soy

Desarrollador desde hace unos años

He hecho mis pinitos como Scrum Máster:

Me certifiqué con los mejores (Ariel Ber y Xavier Quesada)

Jose Manuel Beas me ayudó con las historias de usuario

Intento enseñar lo poco que sé a mis alumnos de la Universidad Rey Juan Carlos y el IEBS

También monté una startup, pero salió mal ;)

@micael_gallego [email protected] http://micaelgallego.github.io

¿Qué vengo a contar?

¿Qué vengo a contar?

¿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?

Y las técnicas “clásicas”, se usan en agile?

Y hasta aquí puedo leer...




priorizar?




Antes de preguntar…

Antes de preguntar…

He intentado aprender de los mejores

Y he buscado

información por la red

He intentado aprender de los mejores

Y he buscado

información por la red




priorizar?




Lo que yo he entendido de la

priorización…


Historias de usuario

Las historias de usuario describen las funcionalidades de un sistema software que se pretende desarrollar

Kent Beck introdujo el término historias de usuario como parte de Extreme Programming para fomentar una manera informal de toma de requisitos

Bill Wake inventó el acrónimo INVEST para describir las características que debe tener una buena historia de usuario

Independiente

Negociable

Valiosa

Estimable

Pequeña

Testeable


Historias de usuario

Bill Wake Kent Beck Mike Cohn


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?



planificación




fecha concreta?



planificación




fecha concreta?


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…

El equipo 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…

Al cliente se le enseña un producto funcional (y

potencialmente entregable) al final de cada iteración

La priorización en el manifiesto ágil

La importancia del orden de

implementación de las funcionalidades


Valor “Colaboración con el cliente sobre

negociación contractual”

La mejor forma de involucrar al cliente es ofreciéndole

software funcionando que le aporte valor lo antes

posible

Así lo podrá probar y podrá dar una realimentación lo

antes posible (reduciendo riesgo…)


Valor “Respuesta ante el cambio sobre seguir un plan”

Para poder responder ante el cambio es necesario centrarse primero en lo más importante

De esa forma, hay tiempo de reacción y se pueden reorientar los objetivos del proyecto si el entorno cambia, la estimación no era adecuada, el cliente cambia…


Principio “Nuestra mayor prioridad es satisfacer

al cliente mediante la entrega temprana y

continua de software con valor”

Cuanto más grande sea el valor que se entrega al

principio, mucho más satisfecho estará el cliente

Y se reducirán los riesgos lo antes posible…


Principio “Aceptamos que los requisitos cambien,

incluso en etapas tardías del desarrollo”

Si el equipo se centra en implementar las

funcionalidades más importantes al principio, el cliente

podrá cambiar de opinión sobre las menos prioritarias

(que todavía no se han implementado)

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

Y también priorizamos porque el desarrollo

software es un proceso con mucha

incertidumbre

tiempo

Cono de incertidumbre




priorizar?




Ya tenemos claro que hay que

priorizar…

¿Cómo se hace?

Ya tenemos claro que hay que

priorizar…

¿Cómo se hace?

¿Cómo se prioriza?

Priorizar es ordenar las historias de usuario en base

a su…

valor coste riesgo

Es una cuestión de equilibrio


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


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


Riesgo que se mitiga al

implementar (la HU)

El riesgo 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:

no cumplir el plazo previsto inicialmente

que la tecnología que se ha seleccionado cumpla con las

expectativas

que el producto que finalmente se ha desarrollado no es el

que los clientes/usuarios quieren, etc



implementar (la HU)

El riesgo de cada historia de usuario es determinado

normalmente también por el equipo

En base a su experiencia y conocimiento (o

desconocimiento) de la tecnología y del dominio,

pueden identificar el riesgo de cada HU



implementar (la HU)


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:

Las HU 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)




priorizar?




El product owner y el cliente deciden el valor que aporta cada historia de usuario

El equipo de desarrollo estima el coste de implementarlas

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.

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.

1

2

3

4

Una metodología para priorizar

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



El cliente quiere una tienda online

El equipo de desarrollo tiene mucha experiencia

en el dominio de las tiendas on-line

Ha realizado varios proyectos en el pasado

Tiene bastante experiencia con la tecnología con la

que se va a implementar

El equipo es estable y tiene contacto directo con el

cliente

¿Cómo priorizar en este caso?



Se puede considerar que los

riesgos del proyecto son bastante bajos

El riesgo no será un factor a tener en cuenta al

priorizar las historias de usuario

Los factores a tener en cuenta son únicamente el coste y

el valor

Las funcionalidades que aporten más valor y

tengan menor coste de implementación serán las

más prioritarias



Proyectos en los que se

está probando una nueva

tecnología y el uso de dicha tecnología es el valor

diferencial del producto

Por ejemplo, un proyecto con Oculus Rift o Google

Glass




Lo más prioritario es mitigar

los riesgos de implementar

aplicaciones para esa nueva tecnología

Posiblemente el tiempo de desarrollo también sea un

factor determinante porque lo prioritario es terminar el

producto cuanto antes (para obtener una ventaja

competitiva)

En este contexto, quizás se decida reducir el

número/completitud de las funcionalidades


Sector desconocido

En los proyectos con tecnologías maduras la incertidumbre tecnológica es menor

No obstante, es posible que el sector del proyecto sea totalmente desconocido para el equipo

Por ejemplo, si un equipo nunca ha trabajado en el sector de la banca y quiere realizar un proyecto en ese sector, habrá mucho más riesgo que si el equipo tiene una amplia experiencia



Sector desconocido

Cuando el sector se desconoce, es importante mitigar cuanto antes el riesgo sobre el conocimiento del producto

En estos proyectos suelen ser más prioritarias aquellas funcionalidades que permitan una retroalimentación rápida de los usuarios

Estas historias suelen ser las relacionadas con el interfaz de usuario porque los usuarios pueden validar la funcionalidad antes de que esté implementada

Priorizando el riesgo

Cuando el riesgo y el valor son

los factores determinantes, se suele

usar la siguiente gráfica para priorizar

Riesgo

Valor

Alto valor

Alto riesgo

Bajo valor

Alto riesgo

Bajo valor

Bajo riesgo

Bajo valor

Alto riesgo 1º

2º 3º

X




priorizar?




Las técnicas clásicas…

MoSCoW

Theme Scoring

Matriz de Priorización

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

Matriz de priorización

Es parecida al theme

scoring pero más

elaborada

El peso relativo de cada característica se obtiene

comparando cada característica con todas las

demás

Eso permite obtener unos coeficientes con los que

obtener la priorización total

Matriz de priorización

Es parecida al theme

scoring pero más

elaborada

El peso relativo de cada característica se obtiene

comparando cada característica con todas las

demás

Eso permite obtener unos coeficientes con los que

obtener la priorización total

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

Insatisfacción del usuario

Satisfacción del usuario

Muy elaborada No implementada

Esenciales

Lineales

Asombrosas

Indiferencia

Análisis de Kano

Insatisfacción del usuario

Satisfacción del usuario

Muy elaborada No implementada

Esenciales

Lineales

Asombrosas

Indiferencia

• Por mi elaboradas que estén, no

aumentan la satisfacción del usuario.

• Si no están, el usuario estará insatisfecho

• El usuario no espera esta

funcionalidad pero le gusta si está

• La satisfacción aumenta mucho

aunque la funcionalidad no esté muy

elaborada

• La satisfacción aumenta cuanto más

elaborada está la funcionalidad

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




priorizar?



Y hasta aquí puedo leer…


Yo no tengo mucho más que decir…

¿Hay algo importante que haya

pasado por alto?


Todavía me quedan algunas dudas…

Se usan las técnicas “clásicas” para priorizar? O la

combinación de los criterios se hace “a ojo”?

Realmente el coste se usa para priorizar? o únicamente

para medir la velocidad del equipo y estimar fechas

de entrega / alcance del producto?



Cómo debe afectar el riesgo a la priorización? Justifica cambiar la priorización del cliente (basada principalmente en valor) por el riesgo de implementar ciertas funcionalidades?

No incumple eso el principio del manifiesto ágil “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor” ?



La tecnología a veces dificulta que las historias de

usuario sean independientes y se crean priorizaciones

forzadas. Conviene ser fiel a la priorización basada en

valor pese a que eso aumente el coste global del

proyecto?

¿Hacemos un fishbowl para hablar sobre el tema?

Technology

La priorización de historias de usuario (versión ampliada)