Historias de usuario

ANDRES OBANDO
Historias de Usuario - Definición
Es la representación de los requisitos empleando lenguaje común del usuario,
el cual tiende a ser escrito de manera libre. En general, son redactadas en una
pequeña hoja o incluso se usan formatos especializados para su redacción.

Al redactar una historia de usuario se debe responder a tres preguntas

principales:
1) ¿Quién es la persona/entidad que se beneficia?
2) ¿Qué se quiere?
3) ¿Cuál es el beneficio?
Historias de Usuario - Definición
Acorde a las preguntas anteriores, se obtiene la respuestas antes las necesidades
funcionales del usuario. El orden de cómo se deben acomodar estas historias suele ser:

COMO (Rol) QUIERO (Necesidad) PARA PODER (beneficio).[1]

Los elementos mencionados previamente entre paréntesis corresponden a las respuestas

formuladas en la diapositiva anterior.
Historias de Usuario - Ejemplos

Tomado de (Fatto consultoria y sistemas, 2016)

[2]
Invertir en una Historia de Usuario
Para que una historia de usuario sea considerada óptima, se debe invertir. En realidad, la
inversión (INVEST) fue un término inventado por Billy Waken [3] en el año 2003, donde
cada letra refleja un atributo que debe tener toda historia de usuario.
❖ I – Independent (Independiente)
❖ N – Negotiable (Negociable)
❖ V – Valuable (Valiosa)
❖ E – Estimable (Estimable)
❖ S – Small (Pequeña)
❖ T –Testeable (Comprobable)
HISTORIAS DE USUARIO - INVEST
❖ Independiente: Cada historia de usuario debe ser
redacta independiente de las demas. Si se detectan
dependencias entre las mismas, lo mejor es redactar las
historias de usuario relacionadas en una sola

❖ Negociable: Las historias de usuario no deben contener

muchos detalles. Los mismos serán discutidos en la
etapa de conversación y podrán ser anotados en la parte
de atrás de la ficha (Historia de usuario)

❖ Valiosa: La historia de usuario debe ser valiosa para el

cliente o usuario.
HISTORIAS DE USUARIO - INVEST
❖ Estimable: La historia de usuario debe poder ser estimable con suficiente precisión
para ayudar en la priorización de las mismas. La estimación se realiza dependiendo
del tamaño de la historia de usuario y la realiza el equipo de la necesidad expresada

❖ Pequeña: La historia de usuario debe ser pequeña y así de esta forma estimar mejor
su gestión. Una historia de usuario muy grande se conoce como épica (epic) y tiende
a ser dividida en otras mas pequeñas.

❖ Comprobable: La historia de usuario debe poderse probar. Si el usuario o cliente no

puede probar la historia de usuario implica que no es muy clara y si el equipo no
sabe como probarla nunca se determinara cuando termina la historia de usuario.
 Priorización de
historias de usuario
JULIÁN SILVA
Priorización de historias de usuario
Aunque todas las historias de usuario puedan ser importantes, para poder
focalizarnos en el trabajo de forma eficiente, es necesario destacar aquellas que
den mayor valor al sistema, por tanto, las historias de usuario deben de estar
priorizadas
Criterios de priorización
Las HU deben de tener asignadas un valor que intervenga en el sistema de
priorización, un valor que se basará en los siguientes criterios:

● Beneficios de implementar una funcionalidad.

● Pérdida o coste que demande posponer la implementación de una
funcionalidad.
● Riesgos de implementarla.
● Coherencia con los intereses del negocio.
● Valor diferencial con respecto a productos de la competencia.
Técnica MoSCow
En esta técnica el usuario responsable de asignar la prioridad es consciente del
efecto real que producirá su elección.Su finalidad es obtener un entendimiento
común entre cliente y el equipo del proyecto, en concreto sobre la importancia de
cada historia de usuario.
Clasificación técnica MoSCoW
● M-MUST HAVE (es necesario): Se debe tener la funcionalidad implementada en la solución, sino
esta fallará o la solución no puede ser considerada un éxito.
● S-SHOULD HAVE (es recomendable): Se debería tener la funcionalidad implementada en la
solución ya que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si no
existe pero debería de haber causas justificadas para no implementarla.
● C-COULD HAVE (podría implementarse): Es deseable, por tanto sería conveniente tener esta
funcionalidad implementada en la solución, dependerá de las posibilidades de los tiempos y el
presupuesto del proyecto.
● W-WON'T HAVE (no lo queremos... quizá en un futuro): Se trata de una funcionalidad de muy
baja prioridad o descartada en ese momento, pero que en futuro pueda ser
relevante.Posteriormente, cuando cobra importancia, puede pasar a alguno de los estados
anteriores.
Ejemplo
Realizar una aplicación de compras online, para ello se debe realizar una
planeación adecuada las funcionalidades que se hacen para cada iteración.
Ejemplo
Un prototipo de las historias de usuario pueden ser:

A: Como usuario quiero poder iniciar sesion en mi cuenta

B: Como usuario quiero poder comprar una cantidad ilimitada de productos

C: Como usuario quiero poder describir detalladamente cada producto que

adquiera por medio de la aplicación

D: Como usuario quiero cargar fotos y videos de los productos a la aplicación

Ejemplo
E: Como usuario quiero que la aplicación calcule todos los costos de los productos que
venda por este medio

F: Como usuario quiero que la aplicación se integre con diferentes plataformas de pago
online

G: Como usuario deseo que se confirme la compra de artículos por medio de correo
electrónico

H: Como usuario quiero tener reportes básicos de ventas y ganacias mensuales .

Ejemplo
Después de implementar la técnica MoSCoW la prioridad asignada a cada historia
de usuario es:

● M-MUST HAVE (es necesario): A, F

● S-SHOULD HAVE (es recomendable): B, E
● C-COULD HAVE (podría implementarse): C, D
● W-WON'T HAVE (no lo queremos... quizá en un futuro):G,H

se dividen las historias de usuario según su importancia.

Otras tecnicas de priorizacion
● Theme Scoring:Consiste en reunir
diferentes criterios para la priorización.
Donde cada criterio se le asigna un
porcentaje.Luego estos criterios son
evaluados de 1 a 5 de acuerdo a cada
historia de usuario, donde 1 significa
que no se cumple el criterio y 5 que
satisface el criterio.
 Relative Estimation
Using Planning Poker
JEFFERSON AMADO PEÑA TORRES
The goal of planning poker is not to derive an exact
and accurate estimate that would stand all future
scrutiny, but rather, to obtain a group estimate in a
fast, cost effective and collaborative way!

El objetivo de la planificación con planning poker

no es obtener una estimación exacta y precisa que
pueda soportar todo escrutinio futuro.
¡obtener una estimación grupal de una manera
rápida, rentable y colaborativa!
How it works:
¿Cómo funciona?:
Each player has a set of cards with numbers
representing a set of valid estimates.

Cada miembro del equipo posee un mazo

de cartas, con números que posee
estimaciones
Story points are not units of time. The are used to
represent size of work only, not the duration and
are consistent and relative.

- Los puntos para las historias no son

unidades de tiempo.

- Se usan para representar el tamaño

del trabajo solamente, no la
duración

- Consistentes y relativos.
Commonly the Fibonacci sequence is used to
represent the low range of possible estimates
(including zero): 0, 1, 2, 3, 5, 8, 13, 20, 40, 100?

- Comúnmente la secuencia de
Fibonacci

- Representar el bajo rango de

posibles estimaciones (incluido el
cero)
The reason for using this range is to reflect that as
the size of task increases so does the inherent
uncertainty. It should also convey the message that
this is not an exact science. The bigger the values,
the larger the gaps and uncertainty.
- La razón para usar este rango es
reflejar que a medida que aumenta
el tamaño de la tarea también lo
hace la incertidumbre inherente.

- También debería transmitir el

mensaje de que esta no es una
ciencia exacta. Mientras más
grandes sean los valores, mayores
serán las brechas e incertidumbre.
The facilitator or moderator reads out the first
story. (Ideally, this would be the product owner but
anyone can play this role).

El facilitador o moderador lee la

historia.

(Idealmente, este sería el propietario

del producto, pero cualquiera puede
desempeñar esta función).
The product owner answers any questions relating
to the story.

El propietario del producto responde

cualquier pregunta relacionada con
la historia.
Each estimator privately selects a card
representing the relative size of the story in
relation to the rest of the stories.

Cada estimador selecciona de forma

privada una tarjeta que representa el
tamaño relativo de la historia en
relación con el resto de las historias.
Once all of the estimators have made a selection, all
cards are simultaneously turned over on the table.

Una vez que todos los estimadores

han hecho una selección, todas las
cartas se vuelcan simultáneamente
sobre la mesa.
The outliers (highest and lowest estimators) each
take turns explaining the reasoning for why they
each thought the estimate is either high or low

Los valores atípicos (estimadores

más altos y más bajos) se turnan
para explicar el razonamiento de por
qué cada uno pensó que la
estimación es alta o baja
After a discussion the team re-estimates and the
facilitator notes down any assumptions that have
been agreed upon.

Después de una discusión, el equipo

vuelve a estimar y el facilitador
anota cualquier suposición que se
haya acordado.
After a couple of rounds the estimates will either
converge or the team will reach an agreement
based on the majority or estimate average, and the
estimate will be written down on the story card.

Después de un par de rondas, las

estimaciones convergerán o el
equipo llegará a un acuerdo basado
en la mayoría o el promedio
estimado, y el cálculo se anotará en
la tarjeta de historia.
Why it works:
¿Porque funciona?:
Planning Poker brings together multiple expert
opinions

Planning Poker reúne múltiples

opiniones de expertos
Being asked to justify estimates result in estimates
that better compensate for missing information.

Al pedir que justifique las

estimaciones, se obtienen
estimaciones que compensan mejor
la información faltante.

(Esto es especialmente importante

para las historias de usuarios que a
menudo se dejan intencionalmente
vagas / negociables).
Averaging individual estimates leads to better
results as do group discussion of estimates.

Promediar las estimaciones

individuales conduce a mejores
resultados al igual que la discusión
grupal de las estimaciones.
Relative
Estimation
Using
Planning
Poker
Product Backlog
FABIO MEJÍA
Product Backlog

Product = Lista de Objetivos

Backlog = / Requisitos Priorizada
Product Backlog

- Lista de objetivos / requisitos priorizada

- Lista Maestra de todas las funcionalidades
deseadas en el producto
- Priorizada por el propietario del producto
- Factores de priorización:
- Valor en el Negocio
- Tiempo de Desarrollo
- Cambia a lo largo del desarrollo
- Descripciones
- Lista de deseos
Product Backlog
Product Backlog
Características
Product Backlog Listo
Sprint planning
LUISA BEDOYA
Sprint planning
Etapa 1: REFINAMIENTO DEL
PRODUCT BACKLOG

Participantes:

Product owner, scrum master y

equipo de desarrollo
Sprint planning
Etapa 2: PLANIFICACIÓN DE
LA ITERACIÓN
Duración del
sprint?

2, 3, 4 semanas?

Definición de terminado?
Sprint planning
Etapa 2: PLANIFICACIÓN DE
LA ITERACIÓN
Sprint planning
Etapa 2: PLANIFICACIÓN DE
LA ITERACIÓN
Ejecución del Sprint...
Referencias
HISTORIAS DE USUARIO

[1] Mike Cohn, “User Stories Applied”, 204, Addison Wesley, ISBN 0-321-20568-5

[2] Fatto Consultoria y sistemas (2016). Historias de usuario. [video] Available at:
https://www.youtube.com/watch?v=Zi9E1aUO_1U [Accessed 19 Aug. 2018].

[3] Universidad Miguel Hernández de Elche. Historias de Usuario [archivo PDF]. Recuperado de:
http://umh2818.edu.umh.es/wp-content/uploads/sites/884/2016/02/Historias-de-usuario.pdf

[4] Wake B. (2003). INVEST in Good Stories, and SMART Tasks. Recuperado de:
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Referencias
PRODUCT BACKLOG

Kenneth S. Rubin 2012, “Essential Scrum Practical Guide to the Most Popular Agile Process”, 2012,
Recuperado de: https://es.slideshare.net/UpekhaVandebona/scrum-product-backlog-49209630

Ron Jeffries, “Agile Modeling”, 2006

Mike Cohn, “User Stories Applied”, 2004, Addison Wesley, ISBN 0-321-20568-5

Russel Pannone, “Creating A Product Backlog” 2008 Recuperado de:

https://es.slideshare.net/rpannone/creating-a-product-backlog
Referencias
PRIORIZACIÓN

Menzinsky Alexander, Lopez Gert, “Scrum manager”,2016

SPRINT PLANNING

Join Academia. [Join Academia]. (2018, Ago 20). Scrum Ejemplo Practico de la Planeación del Sprint
[Archivo de video]. Recuperado de http://https://www.youtube.com/watch?v=BNCDcGqYNwk

Arnedo L., Gama J., Masramon J. P.. (2018, Ago 20). Planificación de la iteración (Sprint Planning).
Recuperado de http://proyectosagiles.org/planificacion-iteracion-sprint-planning/
Referencias
Planning poker

- http://renaissancesoftware.net/papers/44-planing-poker.html
- http://en.wikipedia.org/wiki/Planning_poker
- http://www.planningpoker.com