Clase 9: Pila de producto – Historias de Usuario - Épicas

Disparador

Temas
Pila de Producto
Requerimientos con métodos ágiles. Historias de Usuarios.
Epica – Historia de Usuario – Tareas
Descripción de HU

Introducción
En esta clase continuaremos conociendo más sobre Scrum, precisamente de cómo se
escriben y gestionan los requerimientos del desarrollo del producto.
En la búsqueda por mejorar el proceso de gestión de requerimientos, analizaremos que
prácticas ágiles y artefactos suelen aplicarse. Para la gestión de requerimientos con Scrum,
vamos a modelar con una herramienta inicial: Product Backlog (Pila de Producto). ¿Qué es el
Product Backlog?

Pila del producto (Product Backlog)

Es una lista en cualquier formato que contiene todos los requerimientos que
necesitamos implementar. Es resultado del trabajo del Product Owner con los distintos

DES-ASI2
Instituto Superior Santo Domingo Página 1 de 6
Clase 9: Pila de producto – Historias de Usuario - Épicas
Stakeholders. Aquí está la fuente principal de información sobre el producto, en formato de
Historias de Usuarios. También la podemos encontrar con el nombre de Product Backlog,

Es el conjunto de requisitos funcionales y no funcionales que debe cumplir

el producto una vez entregado. No se requiere que esté completo al momento
de su creación, basta con definir aquellos requisitos que se conozcan en su
momento y alentar a su crecimiento continuo o su modificación.

El trabajo pendiente del producto es una lista emergente y ordenada de lo que se

necesita para mejorar el producto. Es la única fuente de trabajo emprendida por el equipo
Scrum.
Los elementos de la pila del producto son los trabajos que el equipo puede tomar para
trabajar dentro de un Sprint una vez que son refinados, es decir, que adquieren tal grado de
transparencia después de descomponer las actividades que implica ese requerimiento.
El refinamiento de Backlog del producto es el acto de descomponer y definir aún más los
elementos de trabajo pendiente del producto en artículos más pequeños y precisos. Esta es una
actividad en curso para agregar detalles, como una descripción, un pedido y un tamaño.
Los desarrolladores que realizarán el trabajo son responsables del tamaño. El Propietario
del producto (Product Owner) puede influir en los desarrolladores ayudándoles a entender y
seleccionar mejores alternativas.
Con las HUs refinadas y priorizadas, se compone lo que llamamos “la pila del Sprint
(Sprint Backlog o trabajo pendiente del sprint)”.
El Sprint Backlog es la pila de HU o requerimientos que el equipo de desarrollo se
compromete a finalizar durante un Sprint.

Historias de Usuario
Las Historias de Usuario (HU) son un enfoque de requerimientos ágil que se focaliza
en establecer conversaciones acerca de las necesidades de los clientes. Son descripciones
cortas y simples de las funcionalidades del sistema, narradas desde la perspectiva de la
persona que desea dicha funcionalidad, usualmente un usuario.
Las historias de usuarios (UH) poseen las siguientes características: una descripción
escrita que será utilizada para planificar y posteriormente disgregar los detalles con el dueño
del producto, las conversaciones propiamente dichas con el dueño del producto y las
pruebas que han de determinar si las historias están finalizadas o no.
Generalmente se las escribe en post-its (notas) y se las dispone en una pared o una
mesa para facilitar de este modo la planificación y discusiones que se llevan a cabo durante
la misma. Estas notas representan los requerimientos del cliente y típicamente se las escribe
de la siguiente manera:

DES-ASI2
Instituto Superior Santo Domingo Página 2 de 6
Clase 9: Pila de producto – Historias de Usuario - Épicas

Las historias de usuario se describen siguiendo la siguiente estructura:

Como <rol del usuario>

quiero <descripción de la funcionalidad>
para <motivo, razon o valor a obtener>

Es una manera simple de describir una funcionalidad o requerimiento contadas desde la

perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del
sistema.. Se compone de tres partes:

• Una descripción escrita en lenguaje coloquial, que sirve como recordatorio del
requerimiento y ayuda a la planificación.

• Una conversación, que se da entre el equipo y el Product Owner (quien comunica la

historia de usuario). En esta instancia se detallan todas las dudas y aclaraciones sobre la
funcionalidada realizar.

• Criterios de Aceptación, que se componen de las pruebas que debe de pasar el US para
ser considerada correcta y libre de errores.

DES-ASI2
Instituto Superior Santo Domingo Página 3 de 6
Clase 9: Pila de producto – Historias de Usuario - Épicas

Para una mejor clasificación y organización puede añadirse un código a cada

historia, para ayudar a su identificación unívoca dentro del proyecto. Así tendríamos:
 Identificador (ID) de la historia: código que identifica unívocamente a la HU
en el Proyecto que se esté desarrollando. El formato debe ser elegido por el
equipo.
 Rol: es el rol que está desempeñando el usuario cuando utiliza la funcionalidad
que se está describiendo. Debe ser lo más específico posible, describiendo el rol o
actor que se está desempeñando. El enunciado puede escribirse como se sigue: Yo
como un [Rol], Desempeñando el rol de [Rol], Como un [Rol], entre otros. Por
ejemplo: “Yo como cliente registrado”. “Desempeñando el rol de cliente
registrado”. “Como un cliente registrado”.
 Característica / Funcionalidad (Feature): representa la función que el rol
quiere o necesita hacer en el sistema que se está desarrollando. Puede
diferenciarse entre acciones obligatorias u opcionales, utilizando la palabra
puede o necesita para describir la acción. Por ejemplo: “Necesito realizar
búsquedas de productos por categorías.”
 Razón / Resultados: lo que el rol necesita lograr al ejecutar la acción. Este es el
resultado de ejecutar la acción desde el punto de vista del rol. Este punto puede
ser opcional, pues la historia puede documentarse sólo con la definición del rol y
la acción (sin definir la consecuencia).

Características de las HU
Las HU deben ser:
 Independientes unas de otras: de ser necesario, combinar las historias
dependientes o buscar otra forma de dividir las historias de manera que resulten
independientes.
 Negociables: la historia en si misma no es lo suficientemente explícita como para
considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su
alcance yéste debe dejarse explícito bajo la forma de pruebas de validación.
 Valoradas por los clientes o usuarios: los intereses de los clientes y de los usuarios
no siempre coinciden, pero en todo caso, cada historia debe ser importante para
alguno de ellos más que para el desarrollador.
 Estimables: un resultado de la discusión de una historia de usuario es la
estimación del tiempo que tomará completarla. Esto permite estimar el tiempo
total del proyecto.
 Pequeñas: las historias muy largas son difíciles de estimar e imponen
restricciones sobre la planificación de un desarrollo iterativo. Generalmente se
recomienda la consolidación de historias muy cortas en una sola historia.

DES-ASI2
Instituto Superior Santo Domingo Página 4 de 6
Clase 9: Pila de producto – Historias de Usuario - Épicas
 Verificables: las historias de usuario cubren requerimientos funcionales, por lo
que generalmente son verificables. Cuando sea posible, la verificación debe
automatizarse, de manera que pueda ser verificada en cada entrega del proyecto.
Historias de Usuario y Requerimientos No Funcionales

Los requerimientos funcionales (RF) que define el cliente como deseos, y no funcionales
(RNF), como requerimientos de calidad, confiabilidad, eficiencia, usabilidad, mantenibilidad,
portabilidad, entre otros, definen los criterios que tendrán nuestras Historias de Usuario.

Veamos algunos ejemplos de cómo expresar requerimientos en la sintaxis de la user story.

Los requerimientos no funcionales deben ser considerados como restricciones al

comportamiento del sistema.

Los RNF´s condicionan la funcionalidad, quitando algún grado de libertad en el diseño,

es por eso que se los plantea como restricciones. Algunos RNF´s condicionan trasversalmente a
todo el producto y otros son aplicables a alguna user story en particular. Por lo tanto y
considerando este último caso, existe la opción de expresar los RNF´s como parte de los
criterios de aceptación. Vemos un ejemplo

Épica
Es una historia de usuario de gran tamaño o alta granularidad2 , y que tiene por tanto un
mayor grado de incertidumbre. Marcar una historia como epic implica que no puede completarse de
una sola vez o en un único sprint. Lo normal es que el equipo de desarrollo lo descomponga cuando
se acerque el momento de su implementación. Las historias de usuario resultantes estarán
íntimamente relacionadas y su menor tamaño permitirá gestionarlas de forma ágil, estimando mejor
el tiempo requerido para completarlas y siguiendo su avance con detalle.

Tema
Es una colección de epics e historias de usuario relacionadas que describen un sistema o
subsistema. Se trata de un elemento que forma parte de la visión del producto, más que una
DES-ASI2
Instituto Superior Santo Domingo Página 5 de 6
Clase 9: Pila de producto – Historias de Usuario - Épicas
funcionalidad. Por ejemplo: en un sistema de software para gestión contable, el conjunto de epics
«altas, bajas y mantenimiento de clientes», «facturaciones puntuales y recurrentes», «consultas de
navegación y acciones de fidelización», «pedidos» y «devoluciones» se podrían denominar como el
tema de la «gestión de clientes».

Tareas

Las tareas están por debajo de las historias de usuario. Describen cómo construir en lugar de qué.
Resultan de la descomposición de las historias de usuario en unidades de trabajo adecuadas pare
gestionar y seguir el avance de su ejecución.

Al dividir en tareas una HU es posible realizar una estimación del tiempo o del esfuerzo
(según el tipo de estimación que se realice) para cumplir con la misma. Por ejemplo para el caso
anterior podríamos tener:

 Crear el modelo Usuario y correr el ORM para modificar las tablas Tag:
programación
o Esfuerzo: 2 h
 Diseñar un formulario HTML para insertar usuario y contraseña Tag:
diseño
o Esfuerzo: 4 h
 Desarrollar la lógica de la vista del formulario de logueo Tag:
programación
o Esfuerzo: 4 h
 Crear el controlador para el modeloTag: programación
o Esfuerzo: 6 h
 Correr los test e integrarTag: testing
o Esfuerzo: 1 h

DES-ASI2
Instituto Superior Santo Domingo Página 6 de 6
Clase 9: Pila de producto – Historias de Usuario - Épicas
Finalmente, dichas tareas se plasmarán en diferentes post-it (una tarea en cada uno).
Los miembrosdel equipo decidirán qué tareas se asignará cada uno y se colocarán los post-it
en el tablero:

Información necesaria en las HU

Para decidir qué información incluir en una historia de usuario es preferible no adoptar
formatos rígidos. Los resultados de scrum y agilidad no dependen de las formas, sino de la
institucionalización de sus principios y la implementación adecuada a las características de la
empresa y del proyecto. En el gráfico mostramos ejemplo de una tarjeta de historia de usuario:

DES-ASI2
Instituto Superior Santo Domingo Página 7 de 6
Clase 9: Pila de producto – Historias de Usuario - Épicas
Criterios de Aceptación

Los Criterios de Aceptación son las condiciones que un producto de software debe
satisfacer para ser aceptado por un usuario o cliente. Son los criterios mínimos para validar una
historia de usuario una vez que se ha terminado su desarrollo y se han cumplido esos criterios.
A veces se traducen en pruebas, son un excelente lenguaje para detallar requerimientos
funcionales, y es por ello que toman una gran importancia en las historias de usuario.
Los criterios se suelen expresar en forma de checklist.
Durante la revisión del sprint, el propietario de producto comprobará, a través de estos
criterios de aceptación si cada una de las historias de usuario se puede aceptar y dar por finalizada.
Los criterios de aceptación pueden escribirse en lenguaje natural, tal como el propietario del
producto se expresa, y pueden adoptar diferentes formatos. Por ejemplo:

Una opción excelente es escribirlos con la técnica del comportamiento por escenarios:

escenario: un identificador para el escenario asociado a la historia.

 Título del escenario: describe el escenario que define un comportamiento.
 Contexto: detalla las condiciones que desencadenan el escenario.
 Evento: representa la acción que el usuario ejecuta, en el contexto definido para el
escenario.
 Resultado / comportamiento esperado: el comportamiento del sistema en esa situación.

Ejemplo 1 – check list:

DES-ASI2
Instituto Superior Santo Domingo Página 8 de 6
Clase 9: Pila de producto – Historias de Usuario - Épicas

Ejemplo 2 – técnica del comportamiento por escenarios:

Desempeño
De la oportunidad que detectaste (preparación de un viaje, organizar un evento, ordenar
la casa,etc.), que ya identificaste algunos requerimientos, vamos a escribirla en formato de
HUs:
Como <rol del usuario>
quiero <descripción de la funcionalidad>
para <Objetivo o valor a obtener>
DES-ASI2
Instituto Superior Santo Domingo Página 9 de 6
Clase 9: Pila de producto – Historias de Usuario - Épicas

y comenzar a agregar las tareas a realizar, su estimación en horas.

Siguiendo con el ejemplo de la fiesta de cumpleaños, esta actividad seguiría así:

 HU1_Listar invitados
o Como organizador del evento, quiero tener la lista ordenada de invitados con
sus teléfonos y dirección, para poder enviar las invitaciones con un tiempo
mínimo de 15 días previos al evento.
o Actividades: listar a la familia, listar a los amigos, controlar con otro
organizador, ordenar la lista por tipo de entrega, armar logística de envío.
 HU2_Armar lista de música preferida
o Como organizador del evento, quiero tener la lista de música seleccionada, para
poderreproducir en cada momento del evento según lo planificado.
o Actividades: evaluar y elegir la plataforma de música, buscar los temas
solicitados, armar la lista con el orden definido para cada momento (recepción,
juegos, torta, piñata,despedida).
 HU3_ …

DES-ASI2
Instituto Superior Santo Domingo Página 10 de
6