Introducción

Introducción
Introducción

Las historias son un poderoso Las historias de usuario permiten

medio para fomentar la crear un vínculo entre usuarios o
cooperación y la enseñanza de consumidores y desarrolladores
muchas cosas. de productos.

Son el primer movimiento de esa Nos ayudan a entender la

sinfonía que es el descubrimiento proposición de valor del producto
del producto y de sus desde sus inicios.
características.

Las historias de usuario permiten a los equipos virtuosos construir los productos correctos (Lean),
incluso antes de pensar en hacerlo de la manera correcta (Ágil).

11
 USER STORIES FOUNDATIONS CERTIFICATE USFC

12
 Historias de Usuario: Un Nuevo Orden en los Requisitos

Historias de Usuario:
Un Nuevo Orden en los
Requisitos

USER STORIES FOUNDATIONS CERTIFICATE USFC

13
Historias de Usuario: Un Nuevo Orden en los Requisitos
¡Las historias de usuario no son requisitos de software o de otro producto!

Definición de Producto

A lo largo de este curso usaremos la siguiente definición amplia de Producto:

“Un producto es un vehículo para entregar valor. Tiene un límite claro, personas interesadas conocidas,
usuarios o clientes bien definidos. Un producto puede ser un servicio, un producto físico o algo más
abstracto”.

Fuente: guía de Scrum 2020

Historias de Usuario: Un Nuevo Orden en los Requisitos

La historia de usuario es un sustituto más ligero para lo que han sido nuestros medios tradicionales de
especificar requisitos.

Las historias son:

Sin que tengan que escribirse todos los detalles.

Algunos Ejemplos de Historias de Usuario

Historia de usuario

Como Vendedor
Quiero Afiliar a una persona al banco
Para Ofrecerle productos y servicios de la entidad

Como Cliente potencial

Quiero Afiliarme al banco
Para Contar con alternativas de ahorro y crédito que potencien mi desarrollo personal y
profesional

14
Hola, soy Carmen, profesional joven recién graduada y acabo de conseguir mi primer empleo.
Quiero convertirme en cliente de una entidad financiera para tener oportunidades y alternativas de
ahorro y crédito que potencien mi desarrollo personal y profesional.

Historias de Usuario: Un Nuevo Orden en los Requisitos

Una Historia de Usuario es una breve declaración

de intención que describe algo que el sistema
necesita hacer para el usuario.

• Historia 1: Quiero publicar en el blog.

• Historia 2: Quiero buscar temas en el blog.
• Historia 3: Quiero ordenar las entradas al blog
por fecha.
• Historia 4: Quiero conocer qué actividad hay
en mi blog.

Una historia de usuario es una carta de intención.

15
Algunas Características de las Historias de Usuario

Son cortas y fáciles de leer, entendibles por los desarrolladores

1 (quienes hacen el trabajo), interesados y usuarios.

Representan incrementos pequeños de funcionalidad valorada que

2 puede ser desarrollada en pocos días.

Fáciles de estimar porque el esfuerzo de implementar la funcionalidad

3 puede determinarse rápidamente.

4 No se llevan en documentos grandes o pesados, sino en listas

organizadas que se reordenan fácilmente.

5 No se detallan al principio de la iniciativa, sino que se elaboran sobre

una base JIT (just-in-time).

6 Evitan especificidad demasiado pronto, retardos en el desarrollo e

inventario de requisitos.

7 Necesitan poco o ningún mantenimiento y se pueden desechar con

seguridad después de la implementación.

8 Sirven como insumo para la documentación, la cual también es

elaborada de manera incremental.

Por lo general, representan “funcionalidades o características de

* producto parciales” de valor, es decir, no indican funciones o
procedimientos complejos y grandes que el producto debe tener o
cumplir.

16
 La Magia de las Historias de Usuario

La Magia de las
Historias de Usuario

USER STORIES FOUNDATIONS CERTIFICATE USFC

17
La Magia de las Historias de Usuario

La simpleza de las Historias de Usuario obliga al equipo a estar en comunicación con el Dueño de
Producto. Durante el refinamiento y en la planificación, el equipo pregunta al Dueño de Producto el
detalle de lo que quiere y lo que espera.

1. En la planificación con base en lo conversado, el equipo estima lo que va a construir en presencia

del Dueño de Producto.
2. Durante el Sprint el equipo clarifica con el Dueño de Producto detalles menores faltantes u
olvidados.
3. Y se precisan los criterios de aceptación.

Una historia de usuario no estará finalizada hasta que cumpla todos sus escenarios y cumpla todos
los criterios de Aceptación.

Cumplir con los Fue probada y

01 criterios de
aceptación y de
pruebas (ya sean
03 certificada por el
equipo +
fue aceptada por
Funciones estas, manuales o
automatizadas).
Despliegue el Dueño de
Producto.

Cumplir los
aspectos
02 Desplegado y
funcionando en
un ambiente
04
funcionales.
Condiciones determinado. Aceptación

Ventajas de las Historias de Usuario

1 Estamos orientados al resultado y no a la especificación.

2 No quedan escenarios sin probar, pues estos se explican en los criterios de aceptación.

3 Lo que está por fuera de los criterios de aceptación se convierte en una nueva historia
y se le asigna prioridad.

4 Se puede olvidar: no nos tenemos que volver a preocupar por ella pues el desarrollo
orientado a casos de prueba garantizará que no quedaron escenarios por cubrir.

18
Historias de Usuario y Agilidad

Relación entre las Historias de Usuario con Scrum

y Agile.

• Sobre la documentación: La forma y la

herramienta que se use para documentarlas
pierden valor.
• Scrum y Agile: Sobre todo ante el conocido
principio de la conversación cara a cara y el
valor de la confianza en Scrum.

Las Historias de Usuario Tienen Dentro de sus Objetivos

Sincronizar las expectativas

del Dueño de Producto o Servir como elemento que
usuario con el equipo respecto dirigirá la elaboración del
a una funcionalidad. producto (de software).

Lo importante de la historia es la conversación que se genera o se debe producir alrededor de la misma.

19
 Cómo Luce una Historia de Usuario

Cómo Luce una Historia

de Usuario
USER STORIES FOUNDATIONS CERTIFICATE USFC

20
Representar en vez de escribir Historias de Usuario

• Las historias de usuario son un instrumento de comunicación social

• Como tal, pueden tomar muchas formas
• El texto escrito no es el único medio para representar historias de usuario y, cuando se trata de
escribirlas, no existe una forma única de hacerlo
• Por ello es que hablamos de “Representar Historias de Usuario” en vez de simplemente “Escribir
Historias de Usuario”

Forma “Clásica”

Empecemos con la forma “clásica” de representar una historia de usuario:

Yo como Rol (persona que va a usar la funcionalidad)

Deseo / Quiero / Necesito Funcionalidad requerida
Para Beneficio o valor que va a generar al negocio. Criterios o acuerdos por los
cuales se considerará aceptada la
Criterios de Aceptación: funcionalidad por parte de quien
1. Criterio de Aceptación o Acuerdo 1. la solicita.
2. Criterio de Aceptación o Acuerdo 2.
3. Criterio de Aceptación o Acuerdo 3.
4. Criterio de Aceptación o Acuerdo n.

HU: Solicitud de Información Laboral del Cliente

Yo como CLIENTE DEL BANCO

Deseo / Quiero / Necesito INGRESAR MI INFORMACIÓN LABORAL ACTUAL
Para QUE EL BANCO DETERMINE SI ME PUEDE PRESTAR O NO

Criterios de Aceptación:
1. Que pida los datos de la empresa.
2. Que pida el NIT (identificador único nacional para las empresas) y lo valide.
3. Que pida salario actual.
4. Que pida fecha de ingreso a la empresa.
5. Que pida tres comprobantes de pago.

21
La Conversación sobre la Historia de Usuario

Conversación

La conversación son aclaraciones realizadas por el PO durante el refinamiento o el planning, y muchas

de esas aclaraciones son solicitadas por los miembros del equipo al entender las historias de usuario y
comprender el negocio, ejemplo:

• Los datos de la empresa son nombre, teléfono y dirección.

• Que la validación del NIT sea contra el web service de la Dirección de Impuestos (DIAN).
• El mínimo valor de salario actual debe ser el salario mínimo, el que debe ser leído de la tabla de
parámetros.
• La fecha de ingreso a la empresa debe ser superior a 6 meses.
• Los comprobantes de pago deben ser en formato jpg, gif y máximo de 2 megas cada uno.

Como fruto de una conversación puede resultar que se actualicen los criterios de aceptación o solo que
se deje el registro aclaratorio.

La conversación es parte integral de la historia de usuario

Todo lo que quede registrado de esta conversación, se debe tener en cuenta al momento de
implementar o desarrollar la historia de usuario

HU: Dejar Comentarios en una Publicación de Facebook

22
Yo como usuario de Facebook 7. Las imágenes cargadas se bajarán a
Deseo / Quiero / Necesito poner comentarios a resolución de 300K.
las diferentes publicaciones 8. Dentro de los comentarios se podrá ingresar
Para interactuar con mis contactos, grupos y un sticker.
páginas. 9. Dentro de los comentarios se podrá ingresar
un GIF.
Criterios de Aceptación: 10. Cuando se ingrese el comentario y este
contenga palabras ofensivas se enviará una
1. Se podrán dejar comentarios de máximo notificación al robot de validación de acoso.
2048 caracteres. 11. Los comentarios serán en texto plano.
2. Dentro del comentario se podrán ingresar 12. Antes de que se escriba el comentario
todos los emoticones que se deseen hasta aparecerá según el boceto proporcionado.
un total de 2048. 13. Cuando se publique el comentario aparecerá
3. Dentro del comentario se podrán ingresar la foto de quien publica, el comentario, la
links a otras páginas de internet. imagen, los emoticones y sticker publicados.
4. De los links se pondrá previas de la página
web.
5. Solo se pondrá las previas del primer link.
6. Dentro del comentario se podrán insertar
una imagen.

Algunos ejemplos de Historias de Usuario

Historia de usuario

Soy Nancy. Ama de casa. Jubilada hace muchos años. Quiero hacer una transferencia de dinero a mi
nieta sin tener que ir al banco. No quiero exponerme a un contagio y ya no tengo fuerzas para esperar
de pie haciendo largas colas. Y quiero dedicar mi tiempo a otras labores de la casa.

Quiero hacer la transacción desde mi celular o en el PC de la casa.

Debe ser fácil de realizar porque no soy experta en el uso de estos dispositivos.

Quiero hacerlo de manera segura y rápida. Que no me roben mi platica.

23
 Historia de las Historias de Usuario

Historia de las Historias

de Usuario
USER STORIES FOUNDATIONS CERTIFICATE USFC

24
Las Historias de usuarios se originaron con Extreme Programming (XP).

Su primera descripción escrita en 1998 solo afirma que los clientes definen el alcance del proyecto "con
historias de usuarios, que son como casos de uso".

En lugar de ofrecerse como una práctica distinta, se describen como una de las "piezas del juego"
utilizadas en el "juego de planificación“ (Planning Game) de XP.

Extreme Programming (XP) fue desarrollada por Kent Beck en 1996 y a partir de allí la refinó hasta
publicarla en Extreme Programming Explained en 1999.

Fuente: Agile Alliance

En 2001, Ron Jeffries propone el modelo de Carta, Conversación, Confirmación, para distinguir his-
torias de usuarios "sociales" de prácticas de requisitos "documentales", como los casos de uso.

En 2001, Rachel Davies presentó una charla "Tuning XP" en el XPDay con Tim Mackinnon, donde
presentaron el formato de historia que usaban en Connextra:
"As a role I want feature so that benefit“.

Fuente: As a Coach I want a Story Template so that People Ask Questions.

https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

“Este formato puede llevar a las personas a

centrarse más en los intereses de los usuarios
finales que en la perspectiva de la persona que
presenta el caso de negocio. Además, cuando
se les da una plantilla, las personas pueden
comenzar a tratar las tarjetas de historias
escritas de esta manera como especificaciones
de requisitos mínimos que se centran en las
palabras escritas en lugar de usar historias como
herramientas para conducir una conversación.
Peor aún, las historias que no se ajustan a esta
forma serán maltratadas hasta que lo hagan”.

Raches Davies
ADVERTENCIA
Fuente: As a Coach I want a Story Template so that
People Ask Questions.

26
En 2003, Bill Wake creó el mnemotécnico INVEST
para iniciativas ágiles de desarrollo de software,
como un recordatorio de las características de un
elemento de Product Backlog de buena calidad.

• I – Independent
• N – Negotiable
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

Aquí puedes encontrar el artículo original de

Wake:
https://xp123.com/articles/invest-in-good-sto-
ries-and-smart-tasks/
Bill Wake

En 2004, Mike Cohn publica su libro: User Stories Applied: For Agile Software Development, donde
ayuda a popularizar el formato de Davies y su equipo en Connextra.

https://twitter.com/mikewcohn/status/1186758766462754817

En 2018, Jorge Abad y Lucho Salazar publican su libro: Historias de usuario: una visión pragmática,
que incluye el User Stories Conversation Canvas, un lienzo para que los usuarios, Dueños de Producto,
Gerentes de producto y otros interesados mantengan conversaciones efectivas con los miembros de
los equipos de desarrollo de productos y se construyan productos o servicios extraordinarios.

Más información sobre la historia de las historias de usuario en:

gazafatonarioit.com/2020/04/la-historia-de-las-historias-de-usuario.html

Fuente: ¡Conversaciones con Jorge y Lucho!

27
 Los Modos de Representación de las Historias de Usuario

Los Modos de
Representación de las
Historias de Usuario
USER STORIES FOUNDATIONS CERTIFICATE USFC

28
Representar en vez de Escribir Historias de Usuario

• Como dijimos antes, las historias de usuario pueden tomar muchas formas
• Se pueden usar muchos estilos y diseños para representar las historias de usuario
• Como siempre, lo más importante de estas es la conversación que se genera alrededor de ellas.
• Estas son algunas de las grafías que se pueden usar:

Los Modos de Representación de las Historias de Usuario

Modo 1: Solamente el título.
Nivel de madurez del equipo y del Dueño de Producto: Alto.
Ejemplo:

HU25: Registro de datos personales.

Modo 2: El título +la descripción de Mike Cohn.
Nivel de madurez del equipo y del Dueño de Producto: Alto.
Ejemplo:

HU25: Registro de datos personales.

• Como POSIBLE ARRENDATARIO.
• Deseo/Quiero/Necesito INGRESAR LOS DATOS PERSONALES.
• Para PODER SER UN CANDIDATO ELEGIBLE PARA EL

USER STORIES FOUNDATIONS CERTIFICATE USFC

ARRENDAMIENTO DE LA PROPIEDAD.
Modo 3: El título +el boceto.
Nivel de madurez del equipo y del Dueño de Producto: Intermedio.
Ejemplo:

HU25: Registro de datos personales.

29
 Modo 4: El título +la descripción de Mike Cohn +Los criterios de aceptación en prosa
[+boceto ( opcional)].
Nivel de madurez del equipo y del Dueño de Producto: Principiante.
Ejemplo:

Criterios de aceptación:
• Se requieren capturar los • Todos los campos son
campos de: obligatorios.
HU25: Registro de datos personales.
• Nombre • Países, estados/provincias
• Como POSIBLE ARRENDATARIO.
• Apellidos y ciudades se tomarán de
• Deseo/Quiero/Necesito INGRESAR
• DNI la base de datos.
LOS DATOS PERSONALES.
• Fecha de nacimiento • El DNI tendrá las
• Para PODER SER U N CANDIDATO
• Nacionalidad validaciones requeridas
ELEGIBLE PARA EL
• Ciudad por la ley.
ARRENDAMIENTO DE LA
• Dirección actual
PROPIEDAD.
USER STORIES FOUNDATIONS CERTIFICATE USFC

• País de residencia
• Estado/Provincia
• Ciudad

Modo 5: El título +la descripción de Mike Cohn +Los criterios de aceptación con BDD
[+boceto ( opcional)].
Nivel de madurez del equipo y del Dueño de Producto: Junior.
Ejemplo:

30
 HU25: Registro de datos personales.
• Como POSIBLE ARRENDATARIO.
• Deseo/Quiero/Necesito INGRESAR
LOS DATOS PERSONALES.
• Para PODER SER UN CANDIDATO
ELEGIBLE PARA EL
ARRENDAMIENTO DE LA
PROPIEDAD.

Se requieren capturar los

campos de:
Criterios de aceptación: • Nombres
• Apellidos
CA1: Ingreso de datos. • DNI
• Fecha de nacimiento
DADO que el usuario se encuentra en la página de registro • Nacionalidad
CUANDO seleccione la pestaña de datos personales • Ciudad de nacimiento
ENTONCES el sistema le pedirá los campos. • Dirección actual
• País de residencia
• Estado
• Ciudad

CA2: Validación de ingreso de datos. CA1: Validación del DNI.

DADO que el usuario ingresó los datos requeridos DADO que el usuario ingresó el DNI
Y existe al menos un campo sin diligenciar CUANDO el usuario cambie de campo
CUANDO seleccione enviar ENTONCES el sistema validará las restricciones
ENTONCES el sistema le presentará un mensaje asociadas al DNI (ver documento de REGLAS DE
informándole el/los campo(s) sin diligenciar VALIDACIÓN DE DNI.Docx en el repositorio)
Y el/los campo(s) sin diligenciar aparecerán Y presentará los errores asociados
remarcados en color rojo Y no permitirá avanzar a otro campo hasta que sean
Y no permitirá guardar los datos corregidos

31
Resumen

32
 Historias de Usuario Altamente Efectivas (INVEST) I

Historias de Usuario
Altamente Efectivas
(INVEST) I

USER STORIES FOUNDATIONS CERTIFICATE USFC

33
Historias de Usuario Altamente Efectivas (INVEST)

34
Historias de Usuario Dependientes

01 La historia 2 depende de que la primera esté ya implementada (en funcionamiento)

En el escenario o contexto, nada indica que la historia 2 llegue a ser usada por los
02 usuarios que corresponda y, mucho menos, que se cumpla el propósito de la misma

Este tipo de historias no permiten cumplir con aspectos de alta cohesión y bajo
03 acoplamiento necesarios para desarrollar un buen producto (de software)

En general, la dependencia se elimina mediante análisis y observación, pero también mediante

04 algunos métodos.

Historias de Usuario Independientes

INDEPENDIENTE 1 INDEPENDIENTE 2

35
 01 Ambas historias están escritas desde el punto de vista del Editor.

02 Cada historia puede valerse (y valorarse) por sí misma y puede desarrollarse, verificarse y
entregarse independientemente.

Una buena práctica es preguntarnos para cada Historia de Usuario si hemos hecho todo lo
03 posible para que esta sea independiente del resto.

04 La independencia permite además construir la historia, es decir, convertirla en software

funcionando, en iteraciones diferentes o aun en entregas distintas del mismo proyecto.

Clases de Dependencia entre Historias de Usuario

Dependencia por superposición de funciones.

USER STORIES FOUNDATIONS CERTIFICATE USFC

Dependencia por orden de funciones.

Dependencia por contención.

36
Dependencia por Superposición de Funciones

Cómo independizar historias de usuario dependientes.

No se trata de dependencia técnica, sino

funcional.

Se deben revisar atentamente las

conjunciones (Y) en la parte de la
Actividad de la historia de usuario.

Se trata además de funciones que se

sobreponen o intercalan entre dos o
más historias de usuario.

Historia Dependiente 1 Historia Dependiente 2

37
Historias Independientes

Historias independientes luego de remover la superposición de funciones.

Dependencia por Orden de Funciones

Historia Dependiente 1 Historia Dependiente 2

38
Dependencia por Contención

Historia Dependiente 1 Historia Dependiente 2

Historias de Usuario Altamente Efectivas (INVEST)

39
Historias de Usuario Negociables

De cómo lograr un balance entre el Negocio y el Equipo.

Una buena historia de usuario permite

que entre el negocio y el equipo haya
arreglos flexibles.

Una buena historia de usuario permite

un balance entre sus características y
las fechas de entrega.

Una historia de usuario se puede

convertir fácilmente en dos o más.

Priorización de las Historias de Usuario para Negociarlas

01 Requeridas o críticas: son aquellas sin las cuales la solución no puede vivir.

02 Importantes: son aquellas sin las cuales el sistema puede vivir durante algún tiempo.

Opcionales: son aquellas funcionalidades conocidas coloquialmente como las “buenas, bonitas y
03 baratas”.

No se construirán: no se implementarán debido quizás a restricciones de presupuesto o de tiempo o

04 simplemente porque no tienen ningún valor para el negocio.

40
Historias de Usuario Negociables

De cómo lograr un balance entre el Negocio y el Equipo.

Durante la negociación podemos llegar

a acuerdos con los usuarios.

Incluso podríamos llegar a la conclusión

de no implementar alguna(s)
característica(s).

Habrá una negociación fluida si el

usuario está realmente interesado en el
éxito del esfuerzo de desarrollo.

Historias de Usuario Altamente Efectivas (INVEST)

41
 Historias de Usuario Valiosas (y Valuadas)

Cómo tener una perspectiva más clara del valor real de una historia de usuario.

Al negociar las características de una

historia también tenemos en cuenta su
valor para el negocio o usuario.

Encontrar ese 20 % de las características

que se usan el 80 % de las veces.

En resumen, encontrar ese 20 % del

producto que tiene el 80 % del valor
para el negocio.

Sobre el Valor de las Historias de Usuario

USER STORIES FOUNDATIONS CERTIFICATE USFC

01 Con los usuarios buscamos lo que proporcione mayor valor para el negocio y lo que se
vaya a usar más.

02 Quien mejor conoce el valor de una historia de usuario es precisamente el usuario,

personificado en alguien como el Dueño del Producto.

03 El Valor es el atributo más importante en el modelo INVEST.

Cada historia de usuario debe proporcionar algún valor, el mayor posible, al usuario, al cliente o
04 a cualquier interesado en el producto.

42
Historias de Usuario sin Valor

Historias de Usuario Altamente Efectivas (INVEST)

43
Historias de Usuario Estimables

Cómo medir el esfuerzo requerido para implementar una historia de usuario.

Una historia de usuario se debe poder

construir en un período muy corto de
tiempo.

En tres días o menos, permitiendo al

equipo entregar varias historias con
valor en Sprints muy cortos.

La estimación de cada historia se puede

hacer usando procedimientos simples
que tomen solo segundos.

Estimación de las Historias de Usuario

El usuario debe proporcionar al equipo toda la información para que

* este realice una estimación del esfuerzo que les llevará construir la
historia, usando técnicas muy simples.

La estimación se puede hacer por número de horas totales o por

* puntos de historia o cualquier otro mecanismo en donde participe
todo el equipo y cuyo procedimiento tarde solo algunos pocos minutos
para cada historia.

44
Si No Puedes Estimar una Historia de Usuario

Mike Cohn identifica tres razones principales por las cuales una Historia de Usuario no podría estimarse:

1 La Historia es demasiado grande. En este caso la solución es dividir la

Historia de Usuario en historias más pequeñas que sean estimables.

2 Falta de conocimiento funcional. Falta más conversación con el

usuario o Dueño de Producto sobre los detalles de la historia.

Falta de conocimiento técnico. En estos casos el Equipo puede usar

3 un espacio de tiempo fijo, conocido como “spike”, para investigar más
sobre la historia de usuario.

Historias de Usuario Altamente Efectivas (INVEST)

45
 Sucinta |Pequeña

Sucinta |Pequeña
Se puede construir en una iteración junto a otras
historias. S
Historias de usuario tan pequeñas que las
puedas finalizar durante las primeras horas o Historias de usuario cuyo tamaño oscile entre
días del Sprint. 1/10 y 1/6 de la capacidad del equipo, en cada
iteración.
Historias de usuario con Valor para el negocio,
es decir, no caer en la descomposición funcional. Historias de usuario que inviten a una conversación,
ojalá cara a cara entre representantes del negocio
y el equipo de producto.

El Tamaño Sí Importa
USER STORIES FOUNDATIONS CERTIFICATE USFC

Ilustración adaptada con fines educativos. Kurtz, R. (Productor), Kershner, I. (Director). (1980). Star Wars:
Episodio V - El Imperio contraataca [Película]. Estados Unidos: The Walt Disney Company.

46
Esfuerzo Sugerido para las Historias de Usuario

*Basado en elartículo:https://agileforall.com/resources/how-to-split-a-user-story/en elque se propone que las

historias deben tener entre 1/10 a 1/6 de la velocidad del equipo por Sprint.

** Los números fueron aproximados al entero superior.

Basado en la sugerencia de Thomas Wallet (@WalletThomas), en el que mostraba que tener historias
gigantes no es buena práctica, se estableció la clasificación amarillo, naranja y rojo, mostrando que hay
tamaños grandes de historias de usuario que posiblemente se constituyan en unas épicas susceptibles
de ser divididas.

El esfuerzo invertido en esta historia es grande, se sugiere hacer partición de la historia de

usuario.

El esfuerzo invertido en esta historia de usuario versus la duración del Sprint lo pone en riesgo
que se logre en el tiempo comprometido, es un tamaño de historia riesgoso, se sugiere realizar
división de la historia.

Definitivamente no se recomiendan historias de usuario de este tamaño ya sea porque están

cerca, iguales o exceden el tamaño del Sprint, o porque su tamaño es lo suficientemente grande
y es altamente factible que puedan ser divididas en historias de usuario más pequeñas.

47
Cómo Dividir una Historia de Usuario

48
 Convirtiendo un Formulario o Épica en Historia de Usuario

De Épicas a Historias de
Usuario

USER STORIES FOUNDATIONS CERTIFICATE USFC

49
Ejemplo de una Épica

Épica

• Como Cliente del banco

• Quiero Realizar una transferencia bancaria
• Para Cumplir con mis obligaciones financieras y mantenerme al día en mis pagos
Conversación

• Las transferencias pueden ser a cuentas del mismo banco, del misma titular o de otros titulares
• Pueden ser a cuentas de ahorro o corrientes
• También se pueden hacer a fondos de inversión
• Las transferencias pueden ser al mismo banco o a otros bancos
• Incluso a bancos de otros países
• Se pueden programar para hacerse en una fecha y hora específica
• Hay transferencias ocasionales y transferencias frecuentes o regulares
• Para estas últimas se pueden registrar las cuentas destino para hacer más rápido las transferencias

Épica – Realizar una Transferencia Bancaria

Comencemos la división:

1. Prepara la historia: no cumple INVEST, pues no es pequeña (“small”).

2. Aplica los patrones de división:
a) ¿Describe esta historia un workflow completo? No.
b) ¿Esta historia incluye múltiples operaciones? Sí.
c) ¿Tiene la historia variedad en las reglas de negocio? Sí.
d) ¿Hace lo mismo la historia sobre diferentes tipos de datos? No.
e) ¿La historia tiene una interfaz complicada? Sí.
f) ¿Tiene la historia un núcleo simple que provee la mayoría del valor o aprendizaje? Sí.
g) ¿Debe la historia mucha de su complejidad a requisitos no funcionales, como el rendimiento o
la seguridad? Sí.
h) De la conversación inicial y de la respuesta a estas cuestiones, empiezan a surgir ideas que se
pueden convertir, cada una por sí mismas, en historias de usuario o, incluso, todavía en épicas:

• Hacer una transferencia a otra de mis cuentas del banco

• Programar una transferencia bancaria
• Registrar (Matricular) cuentas destino

50
 • Realizar una transferencia a otro banco

De esta última (épica), pueden surgir:

• Realizar una transferencia a otro banco nacional

• Realizar una transferencia a otro banco internacional

De Épica a Historias de Usuario

Historia de usuario

Como Cliente del banco

Quiero Realizar una transferencia bancaria a otra de mis cuentas en el banco
Para Cumplir con mis obligaciones financieras y mantenerme al día en mis pagos

• La transferencia es a una cuenta corriente

• El valor no debe superar los 3 millones de pesos
• Este valor puede cambiar más adelante
• Debo confirmar el valor a transferir antes de realizarla
• Debe ser una transferencia segura
• La transferencia debe ser en línea
• Quiero recibir un comprobante de la transacción en mi correo electrónico
• La cuenta debe estar registrada a mi nombre previamente y activa para realizar transferencias
• La transferencia puede ser a una cuenta corriente o de ahorros
• Debo confirmar el valor a transferir antes de realizarla
• Debe ser una transferencia segura
• La transferencia puede ser en línea o programarse para realizarse más adelante
• Quiero recibir un comprobante de la transacción en mi correo electrónico, tanto de envío como de
recepción de la transacción

Historia de usuario

Como Cliente del banco

Quiero Programar una transferencia bancaria
Para Cumplir con mis obligaciones financieras y mantenerme al día en mis pagos, sin tener que
ir al banco o ingresar a la sucursal virtual o App del banco

51
• La cuentas destino debe estar registrada y activa para realizar transferencias
• La transferencia puede ser a una cuenta corriente o de ahorros
• La cuenta puede ser propia o de otro titular
• Puede ser al mismo banco o a otro banco
• La programación se puede hacer para una sola transferencia, para un número específico de veces o
con una frecuencia, por ejemplo, mensual
• Quiero recibir un comprobante de la transacción en mi correo electrónico, tanto de envío como de
recepción de la transacción

Recomendación

Revisar el Anexo 1 para ver un ejemplo completo de cómo convertir un Formulario complejo o Épica
en Historias de Usuario

52
Historias de Usuario
Altamente Efectivas
(INVEST) II

USER STORIES FOUNDATIONS CERTIFICATE USFC

53
Advertencia

54
Otros Patrones de División

Más específicos, más prácticos o 04 Variaciones por plataforma

¿Tiene la historia el mismo comportamiento para
derivados de los anteriores. varias plataformas o infraestructuras tecnológicas, por
ejemplo, dispositivos móviles o servidores?

03 Variaciones por navegador

¿Tiene la historia el mismo comportamiento para varios
navegadores de Internet?

02 Variaciones por interesado

¿Tiene la historia comportamientos distintos para diferentes interesados o
usuarios?

01 Variaciones por tipo de usuario

¿Tiene la historia un comportamiento similar para distintos tipos de usuario?

09
Más específicos, más prácticos o El mayor valor
¿La historia incluye mucha funcionalidad, pero el 80 % del Valor
derivados de los anteriores. que proporciona proviene del 20 %de la misma?

08 Retrasa las condiciones de error

¿La historia incluye comportamiento asociado a las condiciones de error, es
decir, lo que ocurre con la historia en una situación con errores?

07 Retrasa los comportamientos opcionales

¿La historia incluye mucho comportamiento opcional (por ejemplo, distintas formas de
lograr la misma meta)?

06 Región geográfica
¿Tiene la historia el mismo comportamiento para usuarios o datos de diferentes regiones
geográficas?

05 Servicios externos
¿Consume la historia servicios externos que apenas se van a implementar o que ya están construidos?

55
HU: Publicar en el Periódico

Yo como PERIODISTA DEL PERIÓDICO

Quiero PUBLICAR UN ARTÍCULO O NOTICIA EN EL PERIÓDICO
Para MANTENER ACTUALIZADO ALOS LECTORES SOBRE LOS ACONTECIMIENTOS MUNDIALES,
CREAR INTERÉS SOBRE TEMAS ESPECÍFICOS EN LOS LECTORES DEL PERIÓDICO Y GENERAR
TRÁFICO HACIA LA PÁGINA DEL PERIÓDICO

Criterios de Aceptación:
1. El artículo no se publica de inmediato.
2. El artículo debe tener menos de mil (1000) palabras.
3. El artículo se debe clasificar por su categoría.
4. También hay distintos tipos de noticias.
5. El artículo puede contener hasta 2 imágenes en HD.
6. Para las noticias en vivo, se puede agregar señal de video.
7. …

Conversación

• La noticia debe tener un titular.

• Las noticias pueden ser Nacionales, Internacionales o Regionales. También de Deportes, Judiciales,
Financieras, Medio Ambiente, de Actualidad, Salud, Urgentes, de Última Hora.
• Los artículos y las noticias deben ser aprobados por Editores.
• Las imágenes de las noticias deben ser en alta resolución, mínimo 1920 x 1080.
• Las noticias y artículos pueden ser comentadas por los lectores.
• Hay distintos tipos de periodistas: de noticias nacionales, financieras, deportivos, internacionales,
regionales, judiciales, de noticias en vivo, editores, de artículos de opinión.

Variaciones por Tipo de Usuario

¿Tiene la historia un comportamiento distinto para distintos tipos de usuario?

Yo como PERIODISTA DEL PERIÓDICO

Quiero PUBLICAR UN ARTÍCULO O NOTICIA EN EL PERIÓDICO
Para MANTENER ACTUALIZADO A LOS LECTORES SOBRE LOS ACONTECIMIENTOS MUNDIALES,
CREAR INTERÉS SOBRE TEMAS ESPECÍFICOS EN LOS LECTORES DEL PERIÓDICO Y GENERAR
TRÁFICO HACIA LA PÁGINA DEL PERIÓDICO

56
Criterios de Aceptación:
1. El artículo no se publica de inmediato.
2. El artículo debe tener menos de mil (1000) palabras.
3. El artículo se debe clasificar por su categoría.
4. También hay distintos tipos de noticias.
5. El artículo puede contener hasta 2 imágenes en HD.
6. Para las noticias en vivo, se puede agregar señal de video.
7. …

Conversación

• La noticia debe tener un titular.

• Las noticias pueden ser Nacionales, Internacionales o Regionales. También de Deportes, Judiciales,
Financieras, Medio Ambiente, de Actualidad, Salud, Urgentes, de Última Hora.
• Los artículos y las noticias deben ser aprobados por Editores.
• Las imágenes de las noticias deben ser en alta resolución, mínimo 1920 x 1080.
• Las noticias y artículos pueden ser comentadas por los lectores.
• Hay distintos tipos de periodistas: de noticias nacionales, financieras, deportivos, internacionales,
regionales, judiciales, de noticias en vivo, editores, de artículos de opinión.

Yo como PERIODISTA DE OPINIÓN Yo como PERIODISTA DE DEPORTES

Quiero PUBLICAR UN ARTÍCULO DE OPINIÓN Quiero PUBLICAR UNA NOTICIA DE DEPORTES
EN EL PERIÓDICO EN EL PERIÓDICO
Para GENERAR INTERÉS SOBRE UN TEMA Para MANTENER ENTERADO A LOS LECTORES
ESPECÍFICO EN LOS LECTORES DEL SOBRE ELACONTECER DEPORTIVO MUNDIAL
PERIÓDICO
Criterios de Aceptación:
Criterios de Aceptación:
1. El artículo no se publica de inmediato.
1. El artículo no se publica de inmediato. 2. El artículo debe tener menos de 500
2. El artículo debe tener menos de mil (1000) palabras.
palabras. 3. …
3. …

57
Yo como EDITOR DEL PERIÓDICO ¿Tiene la historia comportamientos distintos
Quiero PUBLICAR UN ARTÍCULO O NOTICIA para diferentes interesados o usuarios?
DE OTRO PERIODISTA EN EL PERIÓDICO
Para MANTENER ENTERADO A LOS Yo como PERIODISTA DE NOTICIAS EN VIVO
LECTORES SOBRE LOS ACONTECIMIENTOS Quiero TRANSMITIR UNA NOTICIA EN VIVO
DEL MOMENTO EN EL MUNDO Y GENERAR EN EL PERIÓDICO
Para INFORMAR SOBRE LA ACTUALIDAD
MAYOR TRÁFICO HACIA LA PÁGINA DEL
NOTICIOSA Y GENERAR TRÁFICO HACIA LA
PERIÓDICO
PÁGINA DEL PERIÓDICO

Criterios de Aceptación: Criterios de Aceptación:

1. El artículo se publica de inmediato. 1. El artículo se publica de inmediato.

2. … 2. El artículo debe permitir agregar una señal
3. … de video a la noticia en vivo.
3. El periodista debe ser capaz de interactuar
con los “lectores” de la noticia.
4. …

Variaciones por Navegador

¿Tiene la historia el mismo comportamiento para varios navegadores de Internet?

En el ejemplo anterior…

Criterios de aceptación
La noticia debe poder adicionarse al periódico desde navegadores Web móviles y de escritorios.
…

58
Yo como PERIODISTA DE DEPORTES EDGE Yo como PERIODISTA DE DEPORTES CHROME
Quiero PUBLICAR UNA NOTICIA DE DEPORTES Quiero PUBLICAR UNA NOTICIA DE DEPORTES
EN EL PERIÓDICO EN EL PERIÓDICO
Para MANTENER ENTERADO A LOS LECTORES Para MANTENER ENTERADO A LOS LECTORES
SOBRE EL ACONTECER DEPORTIVO SOBRE EL ACONTECER DEPORTIVO
MUNDIAL. MUNDIAL.

Criterios de Aceptación: Criterios de Aceptación:

1. El artículo no se publica de inmediato. 1. El artículo no se publica de inmediato.

2. El artículo debe tener menos de 500 2. El artículo debe tener menos de 500
palabras. palabras.
3. El artículo se debe publicar desde navegador 3. El artículo se debe publicar desde navegador
Edge de Windows. Chrome de Windows.
4. … 4. …

Variaciones por Plataforma

Yo como PERIODISTA DE DEPORTES iOS ¿Tiene la historia el mismo comportamiento
Quiero PUBLICAR UNA NOTICIA DE DEPORTES para varias plataformas o infraestructuras
EN EL PERIÓDICO tecnológicas, por ejemplo, dispositivos móviles o
Para MANTENER ENTERADO A LOS LECTORES servidores?
SOBRE EL ACONTECER DEPORTIVO
MUNDIAL. Yo como PERIODISTA DE DEPORTES ANDROID
Quiero PUBLICAR UNA NOTICIA DE DEPORTES
Criterios de Aceptación: EN EL PERIÓDICO
Para MANTENER ENTERADO A LOS LECTORES
1. El artículo no se publica de inmediato. SOBRE EL ACONTECER DEPORTIVO MUNDIAL.
2. El artículo debe tener menos de 500
Criterios de Aceptación:
palabras.
3. El artículo se debe publicar desde plataforma
1. El artículo no se publica de inmediato.
iOS.
2. El artículo debe tener menos de 500
4. … palabras.
3. El artículo se debe publicar desde plataforma
Android.
4. …

59
Servicios Externos
Yo como EDITOR DE LA SECCIÓN FINANCIERA ¿Consume la historia servicios externos que
Quiero PUBLICAR EL VALOR DEL DÓLAR apenas se van a implementar o que ya están
MINUTO A MINUTO construidos?
Para INFORMAR A LOS LECTORES
INTERESADOS EN FINANZAS SOBRE LAS Conversación
NOTICIAS Y DATOS RELEVANTES PARA QUE
HAGAN MEJOR SU TRABAJO Y MANTENER • Se debe mostrar una gráfica del valor minuto
UN ENFOQUE A LA ITERACIÓN CONSTANTE a minuto.
Y LAS PRUEBAS EN TORNO A LA EXPERIENCIA • Se debe mostrar el valor oficial del día.
DIGITAL. • La fuente oficial es Re&%$rs.
• Se toma el valor de manera automática por vía
Criterios de Aceptación: de un servicio que proporciona la fuente.
1. El valor del dólar se mueve de 8 a. m. a 1:00 p. m. • Hay que comprar el servicio que incluya otros
2. Se debe tener un valor cada minuto en ese indicadores económicos.
rango. • Para la primera versión se puede digitar el
3. Cualquier lector debe poder acceder a esa valor minuto a minuto.
información.
4. El valor del dólar debe venir de la fuente
oficial.
5. …

Yo como EDITOR DE LA SECCIÓN FINANCIERA ¿Consume la historia servicios externos que

Quiero PUBLICAR EL VALOR DEL DÓLAR apenas se van a implementar o que ya están
MINUTO A MINUTO “DIGITADO” construidos?
Para INFORMAR A LOS LECTORES
INTERESADOS EN FINANZAS SOBRE LAS Conversación
NOTICIAS Y DATOS RELEVANTES PARA QUE
HAGAN MEJOR SU TRABAJO Y MANTENER • Se debe mostrar una gráfica del valor minuto
UN ENFOQUE A LA ITERACIÓN CONSTANTE a minuto.
Y LAS PRUEBAS EN TORNO A LA EXPERIENCIA • Se debe mostrar el valor oficial del día.
DIGITAL. • La fuente oficial es Re&%$rs.
• Se toma el valor de manera automática por vía
Criterios de Aceptación: de un servicio que proporciona la fuente.
• Hay que comprar el servicio que incluya otros
1. El valor del dólar se mueve de 8 a. m. a 1:00 p.m. indicadores económicos.
2. Se debe tener un valor cada minuto en ese • El valor minuto a minuto es un valor que solo
rango. se informa a los lectores, es referencial más no
3. Cualquier lector debe poder acceder a esa oficial.
información. • Para la primera versión se puede digitar el
4. El valor del dólar debe digitarse minuto a valor minuto a minuto.
minuto.
5. …

60
Yo como EDITOR DE LA SECCIÓN FINANCIERA ¿Consume la historia servicios externos que
Quiero PUBLICAR EL VALOR DEL DÓLAR apenas se van a implementar o que ya están
MINUTO A MINUTO “AUTOMÁTICO” construidos?
Para INFORMAR A LOS LECTORES
INTERESADOS EN FINANZAS SOBRE LAS Conversación
NOTICIAS Y DATOS RELEVANTES PARA QUE
HAGAN MEJOR SU TRABAJO Y MANTENER • Se debe mostrar una gráfica del valor minuto
UN ENFOQUE A LA ITERACIÓN CONSTANTE a minuto.
Y LAS PRUEBAS EN TORNO A LA EXPERIENCIA • Se debe mostrar el valor oficial del día.
DIGITAL. • La fuente oficial es Re&%$rs.
• Se toma el valor de manera automática por
Criterios de Aceptación: vía de un servicio que proporciona la fuente.
• Hay que comprar el servicio que incluya otros
1. El valor del dólar se mueve de 8 a. m. a 1:00 p. m. indicadores económicos.
2. Se debe tener un valor cada minuto en ese • El valor minuto a minuto es un valor que solo
rango. se informa a los lectores, es referencial más no
3. Cualquier lector debe poder acceder a esa oficial.
información.
4. El valor del dólar debe tomarse directamente
de la fuente.
5. …

Retrasa los Comportamientos Opcionales

Yo como PERIODISTA INFORMATIVO ¿La historia incluye mucho comportamiento

Quiero PUBLICAR NOTICIAS CON IMÁGENES opcional (por ejemplo, distintas formas de lograr
Para HACER MÁS VERÍDICA LA NOTICIA Y la misma meta)?
GENERAR CREDIBILIDAD EN LOS LECTORES.
Conversación
Criterios de Aceptación:
• La noticia puede no contener imágenes.
1. Las imágenes deben ser en alta resolución • Para noticias de menos de 500 palabras,
(mínimo 1920 x 1080). máximo una imagen.
2. Las imágenes deben ser aprobadas por un • Las imágenes no deben contribuir a dañar el
Editor de imágenes del periódico. buen nombre de las personas que aparecen
3. Máximo 2 imágenes por artículo. en la foto.
4. La noticia puede no contener imágenes. • Si son imágenes referenciales, deben ser de
5. … un banco de imágenes del periódico o de una
fuente con la que el periódico tenga convenio
y se debe referenciar al autor.

61
Yo como PERIODISTA INFORMATIVO ¿La historia incluye mucho comportamiento
Quiero PUBLICAR NOTICIAS HASTA CON UNA opcional (por ejemplo, distintas formas de lograr
IMAGEN la misma meta)?
Para HACER MÁS VERÍDICA LA NOTICIA Y
GENERAR CREDIBILIDAD EN LOS LECTORES. Conversación

Criterios de Aceptación: • La noticia puede no contener imágenes.

• Para noticias de menos de 500 palabras,
1. Las imágenes deben ser aprobadas por un máximo una imagen.
Editor de imágenes del periódico. • Las imágenes no deben contribuir a dañar el
2. Máximo 1 imagen por artículo. buen nombre de las personas que aparecen
3. La noticia puede no contener imágenes. en la foto.
4. … • Si son imágenes referenciales, deben ser de
un banco de imágenes del periódico o de una
fuente con la que el periódico tenga convenio
y se debe referenciar al autor.

Retrasa las Condiciones de Error

Yo como … ¿La historia incluye comportamiento asociado a

Quiero … las condiciones de error, es decir, lo que ocurre
Para … con la historia en una situación con errores?

Criterios de Aceptación: Conversación

1. … • ¿Qué ocurre si el artículo de opinión tiene

2. … más de mil palabras?
3. … • ¿Qué ocurre si son más de la 1 de la tarde en la
4. … publicación del valor del dólar?
• ¿Qué pasa si las imágenes tienen una resolución
menor a la requerida?
• ¿Qué pasa si son más de 2 imágenes?
• ¿Qué ocurre si el enlace al video de la noticia
en vivo no funciona?

62
El Mayor Valor

Yo como LECTOR DEL PERIÓDICO La historia incluye mucha funcionalidad, pero ¿el
Quiero ESCRIBIR COMENTARIOS A LAS 80 %del Valor que proporciona proviene del 20 %
NOTICIAS O ARTÍCULOS DE MI INTERÉS de la misma?
Para DAR A CONOCER MI OPINIÓN RESPECTO
DE UN TEMA Y DARME A CONOCER EN LOS Conversación
FOROS DEL PERIÓDICO.
• Las personas que hagan comentarios deben
Criterios de Aceptación: estar registradas como lectores del periódico.
• Se debe proporcionar una dirección de correo
1. El comentario debe ser de máximo 250 electrónico válida del lector comentarista.
palabras. • El lector debe cumplir con las políticas y
2. El comentario debe ser aprobado por un condiciones para realizar comentarios en el
Editor de comentarios. periódico.
3. El comentario debe cumplir con las políticas • …
de publicaciones del periódico.
4. El comentario puede contener enlaces Web.
5. El comentario no debe incluir datos
sensibles del lector o de otras personas.
6. …

Yo como LECTOR DEL PERIÓDICO La historia incluye mucha funcionalidad, pero ¿el
Quiero ESCRIBIR COMENTARIOS “TEXTO” A 80 %del Valor que proporciona proviene del 20 %
LAS NOTICIAS O ARTÍCULOS DE MI INTERÉS de la misma?
Para DAR A CONOCER MI OPINIÓN RESPECTO
DE UN TEMA Y DARME A CONOCER EN LOS Conversación
FOROS DEL PERIÓDICO.
• Las personas que hagan comentarios deben
Criterios de Aceptación: estar registradas como lectores del periódico.
• Se debe proporcionar una dirección de correo
1. El comentario debe ser de máximo 250 electrónico válida del lector comentarista.
palabras. • El lector debe cumplir con las políticas y
2. El comentario debe ser aprobado por un condiciones para realizar comentarios en el
Editor de comentarios. periódico.
3. El comentario debe cumplir con las políticas • …
de publicaciones del periódico.
4. …

63
Seis Disfunciones de un Equipo con las Historias de Usuario

El Método “Hasta Acá Llegamos” (Criterio de Equipo)

64
Historias de Usuario Altamente Efectivas (INVEST)

Historias de Usuario que se Pueden Probar

Cómo se pueden verificar y validar las historias de usuario.

El equipo entiende la historia a un nivel

suficiente como para ser capaces de
elaborar las pruebas para ello.

Saber qué y cómo probar una historia

desde el punto de vista de los usuarios
hace más productivo a los equipos.

Conocer anticipadamente las pruebas a

realizar es un gran paso hacia el
cumplimiento de las metas del Sprint.

65
Sobre las Pruebas de las Historias de Usuario

66
Algunas Ideas Sobre las Pruebas de las Historias de Usuario

Historias de Usuario que se Pueden Probar

¿Cómo se pueden verificar y validar las historias de usuario?

En las conversaciones sobre historias de usuario:

Debemos prestar especial atención a términos o expresiones como:

• Automáticamente.
• Procesar.
• Administrar.
• Gestionar.
Y sus sinónimos para así proceder a clarificarlas.

67
Creadores

Luis Antonio Salazar más conocido como Lucho

Salazar coautor del libro: “Historias de Usuario:
Una Visión Pragmática”. Es uno de los agilistas
más reconocidos a nivel de Latinoamérica y con
quien tuvimos la oportunidad de crear esta nueva
certificación, tomando como fundamento el libro
de su autoría.

Importantes reconocimientos: Traductor al

idioma español de la guía oficial de Scrum y de la
Guía oficial de Nexus, para escalar Scrum, de Ken
Schwaber.

Jorge Hernán Abad Londoño coautor del libro:

“Historias de Usuario: Una Visión Pragmática”.
Es Ingeniero Civil con amplio conocimiento
en metodologías ágiles, con más de 18 años
de trayectoria en la industria de software y 6
años de experiencia como Agile Coach y con
quien en compañía de Lucho Salazar tuvimos la
oportunidad de crear esta nueva certificación,
tomando como fundamento el libro de su autoría.

Importantes reconocimientos: Traductor al

idioma español de la guía oficial de Nexus, para
escalar Scrum, de Ken Schwaber. Miembro activo
y reconocido en la comunidad Ágiles Colombia y
Ágiles Latinoamérica.

68