Metodologías Ágiles

Evaluación del equipo SCRUM

(Nivel Intermedio)

Tema 6: Detalle de Historia de Usuario

con Criterios de Aceptación.

Capacitación BN: Subgerencia de

Construcción de Aplicaciones
1
 Agenda 6
• ¿Qué es una Historia de Usuario?.
• Las 3 “CCC” de una Historia de Usuario.
• La tarjera (descripción como
recordatorio).
• La conversación con el Rol / Personaje.
• La confirmación (Criterios de
Aceptación).

• Videos (18:07) + un opcional (2:28:10).

2
1. ¿Qué es una Historia de Usuario?

3
1.1. Proceso de los requisitos agiles

4
 1.2. Historia de Usuario
• Las Historias de Usuario (HU) son representaciones de requisitos,
elaboradas en una o dos frases y recogidas en un lenguaje común y
entendible.
• También conocidas como “User Stories”, se han convertido en un estándar
a la hora de definir requisitos.
• Su popularidad viene de la mano con SCRUM, hay que recordar que NO
son un elemento estandarizado en la Guía Scrum.
• En muchas organizaciones se habla de HU como sinónimo de requisito,
olvidando sus fundamentos.
• Las HU aparecen con la XP (1999).
• Mike Cohn en su libro “User Stories Applied: For Agile
Software Development” (2004) fija un patrón para definirlas.
5
1.3. Evolución de los Requerimientos

6
 1.4. Detalle de las Historias de Usuario
• En la fase de Planificación y Estimación de SCRUM se crean las Historias de
Usuario con sus Criterios de Aceptación.
• Las Historias de Usuario generalmente las escribe el Product Owner.
• Están diseñadas para asegurar los requisitos del Cliente y que los
comprendan los Interesados.
• Se puede llevar a cabo un taller de redacción de HU con los miembros del
Equipo de Desarrollo (detalle a bajo nivel).
• El objetivo del ejercicio es elaborar Historias de Usuario y refinarlas para ser
estimadas y comprometidas por el Equipo de Desarrollo.
• Las HU deben cumplir con los seis (6) requisitos INVEST.
• Hay que identificar las Dependencias entre HU.

7
• El Product Owner interactúa con los Interesados, con su conocimiento
del negocio, la experiencia y las aportaciones del equipo para elaborar
las Historias de Usuario que formaran el Product Backlog Priorizado al
inicio del proyecto.
• El Product Backlog representa la suma total de Historias de Usuario que
deben completarse en el proyecto.
• En ocasiones, el Product Owner puede incluir a un analista empresarial
o de negocio para que ayude en la redacción de historias de usuario.
• Los Requerimientos NO Funcionales NO deben ir como HU. Se incluyen
en los Sprint Backlog como Tareas preliminares. Por ejemplo: diseñar
prototipos, diseñar la arquitectura, crear la Base de Datos, pruebas
unitarias, configuración de servidores, etc.

8
2. Las CCC de una Historia de Usuario

9
 2.1. Elementos de una Historia de Usuario

CARD
Tarjeta (es una breve descripción que sirve como recordatorio)
CONVERSATION
Es presencial (se realiza para asegurar que se ha entendido todo y concretar
el objetivo)
CONFIRMATION
Criterios de Aceptación (pruebas funcionales / detalles relevantes / límites).
Hay que declarar el escenario, comportamiento y respuestas.

10
Video 6.1.

¿Cómo crear Historias de Usuario en SCRUM? (6:53)

https://www.youtube.com/watch?v=ky6wFiF5vMk

11
3. Estructura de una Historia de Usuario
La descripción (Recordatorio)

12
 3.1. Plantilla de Historia de Usuario
CARD (Breve declaración)
• Yo como <<Rol/Personaje>> quiero <<funcionalidad>> para <<beneficio 1,
beneficio 2>>.
• Yo <<Rol/Personaje>> debo poder hacer <<funcionalidad>> con el
objetivo<<beneficio>>.
• Como <<Rol/Prototipo del cliente>>, Yo debería <<funcionalidad>> a fin de
<<beneficio>>.

CONFIRMATION (Criterios de Aceptación)

• Dado que <<escenarios>, cuando <<comportamiento>>
entonces<<resultados>>.

Ver Plantillas y ejemplos de H.U.

13
 3.2. La tarjeta de una Historia de Usuario

La regla INVEST son los criterios básicos para construir Historias de Usuario
de calidad:
• Independiente: Una HU con la mínima dependencia entre distintas HU.
Facilita poder llevarlas a cabo en cualquier orden ya que toda dependencia
es condicionante, y además tiende a convertirse en un riesgo.
• Negociable: Los detalles de la construcción emergen de una conversación
entre quien expresa la necesidad y quien la lleva a cabo.
• Valiosa: Es decir, que el resultado de la HU aporta
valor a sus Interesados. Hay que ser conscientes de
que el concepto de valor puede ser muy amplio.

14
• Estimable: Cuenta con información suficiente para estimar el esfuerzo para
llevar a cabo la HU.
• Pequeña (Small en inglés): Una HU no debe requerir más de una cantidad
determinada de tiempo para ser construida. Una HU debe poder ser
llevada a cabo en el transcurso de un Sprint. Si no, debe dividirse.
• Probable o Testable: La Historia contiene información que haga posible
validar que cumple su cometido a través de pruebas o test. Esto requiere
incorporar los Criterios de Aceptación, que acotan y aclaran el alcance de
lo que se quiere hacer.
Los criterios INVEST son los elementos decisivos a la hora de determinar la
calidad de los requisitos, no olvidemos que son los fundamentos sobre los
que se construye todo producto o servicio.

15
4. Conversación con el Rol / Personaje

16
 4.1. Conversación con el Rol / Personaje (Face to Face)
• Después de escribir la HU en la tarjeta, es necesario tener una
conversación de su contenido con el Rol/Personaje.
• Hay que saber responder a cuestiones sobre el valor y sobre el
resultado esperado de la implementación de la HU.
• Esta conversación puede suceder durante el refinamiento del
Product Backlog o del Sprint Planning.
• La conversación es lo que da las razones
inherentes en la HU de lo que hay que
hacer. La tarjeta en la HU es un
recordatorio para llevar a cabo la
conversación. 17
Video 6.2.

Historias de Usuario – Tips importantes (11:54)

https://www.youtube.com/watch?v=FJuq_lrM5Cc

18
5. Criterios de Aceptación (Confirmación)

19
 5.1. Los Criterios de Aceptación
• Cada Historia de Usuario contará con sus Criterios de Aceptación, que son
los componentes objetivos mediante los cuales se juzga la funcionalidad de
una HU en la fase IV de SCRUM.
• Los detalla el Product Owner según su experiencia en los requerimientos
del cliente.
• Los CA deben delinear explícitamente las condiciones que deben satisfacer
las HU. Máximo 5 CA por H.U.
• Los CA claramente definidos son importantes para la
entrega eficaz y oportuna de la funcionalidad
definida en las HU.
• Se definen bajo el método SMART: Especifico,
Medible, Alcanzable, Relevante y Temporalmente
limitado. 20
La regla SMART son los criterios básicos para describir los Criterios de Aceptación de
una Historia de Usuario con calidad:

21
• Al final de cada sprint, el Product Owner utiliza los CA para verificar los
entregables completados y puede aceptar o rechazar entregables
individuales, así como sus respectivas HU.
• Si los entregables son aceptados, la HU se considera como terminada.
• Es importante la “definición de terminado”, ya que ayuda a tener claro los
requerimientos y permite que el equipo cumpla con las normas de
calidad.
• Ayuda también a que el Equipo de Desarrollo piense desde la perspectiva
del Cliente al trabajar con la HU.
• Cuando evoluciona un Rol/Personaje en su comportamiento hay que
evaluar el impacto en los CA.

22
Video 6.3.

Taller de creación de Historias de Usuario - SCRUM(2:28:10)

https://www.youtube.com/watch?v=4-5hkK1LpOU

23
5.2. Historias de Usuario estimadas

24
 Conclusiones
• En la fase de planificación y estimación es importante el detalle de las
Historias de Usuario que se van a incluir en un Sprint.
• Cada Historias de Usuario debe tener como máximo 5 Criterios de
Aceptación para probar su funcionalidad durante la Demostración y
Validación del Sprint.
• Reglas básicas para escribir una HU es INVEST. De igual manera la los
Criterios de Aceptación SMART.
• Las estimaciones de las HU se pueden hacer por varias técnicas. Las más
recomendables: Planning Póker, Puntos de Historia, tallas de camisetas,
por Afinidad, etc.

25
Ronda de Preguntas

Gracias
26