Este documento presenta conceptos clave de Scrum como historias de usuario, criterios de aceptación, product backlog y sprint backlog. Explica que el product owner es responsable de las historias de usuario y su estructura como "Como, Quiero, Para". También cubre conceptos como definición de hecho, criterios DOR y DOD y la importancia de los criterios de aceptación para definir cuando una historia de usuario está completada.

1. Historias de
Usuario
Zafiro E. Echezuria R.

2. Mis redes sociales
WEB
www.zafiroagil.com/
INSTAGRAM
https://www.instagram.
com/zafiroagil/
LINKEDIN
https://www.linkedin.c
om/in/zafiro-
echezuria-5161b370/

3. Agenda
Conceptos Claves
Historias de Usario
Tareas
DOR
DOD
Product Backlog

4. Conceptos claves
Product Backlog
Épica
Historias de Usuario
Criterios de Aceptación

5. Historias de Usuario
Encargado de las HDU
Estructura de las HDU
Modelo INVEST
Tipos de HDU
Importancia de los Criterios de aceptación

6. Encargado de las HDU
El Encargado de las Historias de Usuario es el Product Owner, ya
que él posee toda la visión del negocio, sabe cuales son las
funcionalidades que dan valor así como cuales funcionalidades
deben estar en cada uno de los release.

7. Estructura de las HDU
Como: Es el usuario
Quiero: lo que desea el usario que se haga
Para: la justificación de la realización de esta historia
Las historias de usuario tienen la tarjeta o identificación
Se debe agrear los criterios de aceptación

8. Ejemplo de HDU
Como: Usuario de la aplicación móvil
Quiero: Iniciar sesión en la app
Para: Revisar mis estados
El usuario debe de ingresar el ID y contraseña para iniciar sesión
Si el ID o contraseña son incorrectos se debe mostrar el mensaje "ID y
Contraseña no coinciden intente de nuevo"
El usuario tiene un máximo de 3 intentos, luego de estos 3 intentos su ID
es bloqueado
Inicio de sesión de la aplicación
Criterios de aceptación:

9. Modelo INVEST

10. Tipos de HDU
Historias de Usuario
Historias Técnicas
Spike

11. Importancia de los Criterios de
Aceptación
• Ayuda al equipo Scrum a no tener incertidumbres en las historias
• El QA se guía de los criterios de aceptación para poder realizar los
casos de prueba
• Es necesario que estén bien especificados los criterios de aceptación
ya que se deben cumplir todas las condiciones de los criterios de
aceptación para que la historia de usuario se considere terminada.
• Permite acotar el alcance, eliminando funcionalidades no necesarias y
sin valor para el usuario

12. Consecuencia de malos Criterios de
Aceptación
El software construido no se corresponda con la realidad esperada.
Una historia de Usuario poco entendible

13. Tareas
Definición
Criterio SMART

14. Definición
Es el trabajo técnico que realiza el Development Team para
terminar una Historia de Usuario
La mayoría de las tareas se definen como pequeñas, lo que
representa no más de unas pocas horas de un día.

15. Criterio SMART

16. DOR
Definición
Quien lo define
Importancia

17. La HDU debe cumplir el criterio INVEST
Deben estar los servicios necesario para el desarrollo de la HDU
Debe estar el diseño aprobado por los stakeholder
Es el conjunto de características que una Historia de Usuario debe
cumplir para que el Equipo de Desarrollo pueda incluirla en un
Sprint Backlog. Si las tareas que hay en el backlog no cumplen con
los requisitos definidos en el DoR, no deben incluirse dentro del
Sprint Backlog.
Ejemplo:
Definición

18. ¿Quien lo define?
El DOR lo define el equipo de desarrollo ya que ellos son los
responsables de realizar las Historias de usario, por tanto saben
cuales son las características que deben tener las historias de
usuario para poder ser aceptadas

19. Importancia DOR
Incluir historias en el Sprint que el equipo no pueda realizar
Desorientación en el equipo a la hora de abordar algnas tareas
de las Historias de Usuario
El retrabajo del equipo
Al tener un DoR bien definido evita:

20. DOD
Definición
Quien lo define
Importancia

21. Definición
La HDU de tiene el ok de QA
La HDU cumple con todos los criterios de aceptación
El conjunto de características que una Historia de Usuario debe
cumplir para que el equipo de desarrollo pueda determinar si ha
terminado de trabajar en ella. Un típico criterio de “Terminado”
Cada equipo Scrum tiene su propio DoD
Ejemplo:

22. ¿Quien lo define?
El Equipo Scrum trabaja en conjunto para crearlo, es decir Scrum
Master, Product Owner y team development

23. Importancia DOD
El DoD impulsa la calidad del trabajo
Ayuda a evaluar cuándo se ha completado una historia de
usuario.
Es importante defenir el DoD ya que:

24. Product Backlog
Product Backlog priorizado
Refinamiento del Producto Backlog
Sprint Backlog

25. Product Backlog Priorizado
Es cuando ordenamos el listado de requerimientos pensando en el
valor que la funcionalidad le puede optorgar al negocio.
Esta prioridad es responsabilidad exclusiva del Product Owner y,
aunque el equipo de desarrollo pueda hacer sugerencias o
recomendaciones, es el Product Owner quien tiene la última palabra
sobre la prioridad final de los ítems del Product Backlog, teniendo
en cuenta el contexto de negocio, el producto mismo y el mercado
en el que está inserto.

26. Refinamiento del Producto Backlog
El refinamiento del Product Backlog es el acto de añadir detalle,
estimaciones y orden a los elementos del Product Backlog.
Durante el refinamiento del Product Backlog, se examinan y revisan
sus elementos.
El Scrum Team decide cómo y cuándo se hace el refinamiento.
Un objetivo importante que se debe perseguir es la detección de
riesgos implícitos en los PBIs que se estén analizando, y en función
de ellos revisar y ajustar las prioridades del Product Backlog.

27. Es el conjunto de HDU que fueron seleccionadas para trabajar durante
un determinado Sprint, conjuntamente con el plan para lograr la
entrega del Incremento de Producto al finalizar el Sprint y alcanzar el
objetivo del Sprint.
El Sprint Backlog hace visible y transparente todo el trabajo que el
Equipo de Desarrollo identifica como necesario para alcanzar el
objetivo del Sprint
Sprint Backlog