TALLER DE HISTORIAS

DE USUARIO
SCRUM

Claudia F. del Toro V.

AGENDA

• Introducción a las metodologías ágiles

• Contexto en el proceso
• Sobre las Historias de Usuario
OBJETIVOS DEL TALLER

Aprender con la práctica, cómo se hacen las principales

actividades de la metodología Scrum
MANIFIESTO AGIL

• Los individuos y su interacción, por encima de los procesos y las

herramientas.
• El software que funciona, por encima de la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La respuesta al cambio, por encima del seguimiento de un plan

Aunque hay valor en los elementos de la derecha, valoramos más los de la

izquierda.
www.agilemanifesto.org

kent beck - mike beedle - arie van bennekum - alistair cockburn - ward cunningham - martin fowler
james grenning - jim highsmith - andrew hunt - ron jeffries - jon kern - brian marick - robert c.
martin
steve mellor - ken schwaber - jeff sutherland - dave thomas
METODOS AGILES

m ing
Scru a mm sdm Fdd l e an ta l
Pro
g r D c rys
m e
E xtre
CAMBIO DE PARADIGMA

CASCADA AGIL
Los requerimientos se dejan fijos El costo y el cronograma se dejan fijos
Se estima el Costo y el Cronograma Se estiman los requerimientos

Fix Features Cost Schedule

value / vision
driven
plan
driven

Estimate Cost Schedule Features

GLOSARIO

• Sprint
• Iteración
• Backlog
• Scrum
Roles del proceso

Dueño del
Producto (Product
Equipo Scrum
Owner)
Implementa
Conoce lo que se
funcionalidades
quiere entregar y las
elegidas
prioridades

Experto Scrum (Scrum Master)

Conoce metodología, guía al grupo.
Identifica y apoya solución de problemas.
Paraguas ante presiones externas

8
CONTEXTO

Las historias de
usuario se
levantan al inicio
del proyecto en
la etapa de
establecer
acuerdos y se
van
complementando
en el transcurso
del proyecto
HISTORIAS DE USUARIO

• Existen diversos métodos para definir los requerimientos

de usuario
• Casos de Uso
• Definiciones Funcionales
• Entrevistas
• Historias de Usuario
HISTORIAS DE USUARIO

• Son un método muy simple para levantar los

requerimientos de los clientes
• Tiene 3 elementos fundamentales:
• Rol que necesita la funcionalidad
• Funcionalidad
• Objetivo de la funcionalidad
• Se puede complementar con el conocimiento de los
miembros del equipo
HISTORIAS DE USUARIO

• Las historias de usuario deben cumplir con el principio INVEST:

• Independent (Independiente): la historia de usuario no debe depender de otra historia
ya que esto facilitará la priorización de las mismas. Si por alguna razón la historia de
usuario es dependiente se recomienda fusionarlas.

• Negotiable (Negociable): la historia de usuario puede cambiar y evolucionar a lo largo de

la ejecución del proyecto, incluso podría dejar de tenerse en cuenta si así el cliente lo
desea.

• Valuable (Valiosa): la historia de usuario debe brindar valor al proyecto y al usuario final.

• Estimable (Estimable): la historia de usuario debe tener el tiempo que ésta tomará en
implementarse.

• Small (Pequeña): la historia de usuario debe ser pequeña y concisa. Si una historia de
usuario es muy grande ésta se debe dividir en otras historias más pequeñas, esto con el
fin de poder tener un mejor control sobre ellas.

• Testeable: la historia de usuario debe poderse probar en un proceso de calidad.

HISTORIAS DE USUARIO

• Definir los criterios de aceptación de cada historia

• Son como casos de prueba.
• Pensar: ¿Cómo probaría esta funcionalidad?
DEFINIR LAS HISTORIAS DE USUARIO

• Como (Rol)
• Quiero (Acción)
• Para (Beneficio)

+ CRITERIOS
ESTIMAR CON
PUNTOS DE HISTORIA

16
CONTEXTO

En la etapa de Establecer
el Roadmap, se estiman
los puntos de historia y
se definen las versiones
en las que se van a
abordar
ESTIMACION CON PUNTOS DE HISTORIA

Método 1: estimación Método 2: estimar historia

por afinidad por historia
Definir RoadMap

20
CONTEXTO

Se define el Roadmap
del proyecto basado
en las Historias de
usuario y los objetivos
que se deben/pueden
abordar de cara al
cliente.
PRIORIZACIÓN

• Escala de 1 a 500
• más alto =más importante.
• Sirve para definir umbrales
de aceptación en entregas:
• Igual o Mayor de 100, debe
incluirse en la versión 1 del
proyecto.
• Entre 50 y 99, deben estar en la
versión 1, pero es factible que se
cambien a versiones posteriores.
• Entre 25 y 49, Pueden estar en la
versión 2
• Menor que 25, no son realmente
necesarios y es factible que no se
incluyan en el proyecto.

Estado de Avance Cliente - Proyecto

DEFINIR ROADMAP
 Oficina central
Rosario Norte 407
Las Condes, Santiago
Chile
Fono: (56-2) 2729 7000
Fax: (56-2) 2374 9177
deloittechile@deloitte.com
Regiones

Simón Bolívar 202

Oficina 203
Iquique
Chile
Fono: (56-57) 254 6591
Fax: (56-57) 254 6595
iquique@deloitte.com
Av. Grecia 860
Piso 3
Antofagasta
Chile
Fono: (56-55) 244 9660
Fax: (56-55) 244 9662
antofagasta@deloitte.com
Los Carrera 831
Oficina 501
Copiapó
Chile
Fono: (56-52) 252 4991
Fax: (56-52) 252 4995
copiapo@deloitte.com

Alvares 646
Oficina 906
Viña del Mar
Chile
Fono: (56-32) 288 2026
Fax: (56-32) 297 5625
vregionchile@deloitte.com
O’Higgins 940
Piso 6
www.deloitte.cl Concepción
Chile
Fono: (56-41) 291 4055
Fax: (56-41) 291 4066
concepcionchile@deloitte.com
Deloitte © se refiere a Deloitte Touche Tohmatsu Limited, una compañía privada limitada por garantía, de Quillota 175
Reino Unido, y a su red de firmas miembro, cada una de las cuales es una entidad legal separada e Oficina 1107
independiente. Por favor, vea en www.deloitte.cl/acercade la descripción detallada de la estructura legal Puerto Montt
de Deloitte Touche Tohmatsu Limited y sus firmas miembro. Chile
Deloitte Touche Tohmatsu Limited es una compañía privada limitada por garantía constituida en Inglaterra Fono: (56-65) 226 8600
& Gales bajo el número 07271800, y su domicilio registrado: Hill House, 1 Little New Street, London, Fax: (56-65) 228 8600
EC4A 3TR, Reino Unido. puertomontt@deloitte.com
25©
2012 Deloitte