ROLES:

ROLES • Scrum Master

• Product Owner
• Development team

CEREMONIAS:
• Sprint planning
• Daily scrum
• Sprint Review
• Sprint retrospective

SCRUM ARTEFACTOS:
• Product backlog
• Sprint backlog
• Inremento de producto

ARTEFACTOS CEREMONIAS
Elementos del Product Backlog:

• Items funcionales : Épicas, features, HU)

• Habilitadores(Arquitectónicos, de infraestructura de
cumplimiento)
• ITems de deuda técnica y deuda funcional
• Items de mejora continua
• Bugs identificados
BACKLOG: DEEP
Detailed appropriately
Hace referencia a que no todos los elementos del Backlog del Producto deben tener el mismo grado de detalle. Al respecto,
los elementos de la parte de arriba, aquellos con los que empezaremos a trabajar a más corto plazo deberán estar más
detallados, y ser más pequeños en tamaño (respecto a los puntos de historia).
De la misma manera, los elementos de la parte de media y baja del Backlog de Producto estarán menos “trabajados”;
tendrán menos detalle y su estimación en puntos de historia estará representada por valores más altos.
Emergent
El Backlog de Producto es un elemento vivo: nunca está completo, o dicho de otro modo está en constante evolución. El
feedback que recibimos del cliente es el elemento esencial que marcha dicha evolución.
Es por eso que una de las características esenciales del Backlog de Producto es que es emergente, en tanto que su
estructura surge a lo largo del tiempo y se mantiene en constante evolución. Elementos que forman parte hoy puede
desaparecer mañana, de la misma manera que mañana puede incorporarse otros nuevos.
Estimated
Todos los elementos del Backlog de Producto deben estar estimados (Estimated). Es decir, deben incluir una estimación del
esfuerzo necesario para llevarlo a cabo. Dado que los elementos de la parte alta del Backlog de Producto serán más
pequeños y detallados, su valor en puntos de historia será más pequeño que los de la parte media y baja.

Prioritized
La propia definición de Backlog de Producto establece que se trata de una lista priorizada de los elementos que forman
parte del alcance del proyecto. Sin embargo, al igual que ocurre con las estimaciones, es posible que no sea posible (no
conveniente) priorizar todos los elementos del Backlog de Producto.
¿Cómo priorizar los elementos del Backlog de Producto?

Es responsabilidad del Propietario del Producto priorizar el

Backlog del Producto. Los elementos que lo componen estarán
priorizados en función de su valor para el cliente, pero
corresponde al Propietario del Producto decidir como calcular
ese valor.

Un consejo: será útil priorizar los elementos de la parte de

arriba, aquellos que se desarrollaran próximamente. AL
contrario, no sería necesario invertir ningún esfuerzo en
aquellos de la parte más baja.
 Sprint Planning
Product Owner Historias de
Usuario

1 Sprint
Priorizar los
requerimientos Backlog

Entender los
2
requerimientos
Product

Refinamiento
Backlog
3

Agregar nuevos
antecedentes 5

Product Owner + Equipo Product Owner + Equipo

Product Owner Equipo desarrollo
desarrollo desarrollo
 Estimación Planning Poker 5
Historia de usuario 3
3
“Peinar los perros” 5
0 – 1 – 2 -3 – 5 – 8 – 12 – 20 – 40 – 100 - ? - ♾
Se muestran las
estimaciones
20
Se pregunta principalmente
1 a quienes tienen
puntuaciones lejanas
Empezamos Se hacen consultas

Antes de tomando como Se vuelve a estimar

pivote la historia 1
partir,
2 recuerda! Finalmente
Cuanto esfuerzo nos
tomará peinar el perro de la
Definir un historia 2 tomando como
referencia el perro de la 3
moderador historia 1

3 Definir Un conjunto de historias de

tiempos Usuario estimadas por el equipo
El equipo de de desarrollo, con un número
desarrollo estima de común acuerdo conocido
Explicar las anonimamente como “Puntos de Historia”
reglas
Historias de Tareas o Task
Usuario
• No es necesario en el primer sprint hacer todas las historias de
1 usuario.
• Solo es necesario hacer las historias que nos permitirán avanzar con
las primeras etapas del proyecto.
• El resto de Historias se construye en los siguientes sprint con el
2 backlog que va quedando.
• Toda historia de usuario se descompone en tareas.
• Las tareas pueden ser la cantidad que el equipo de desarrollo
3 estime necesario para dar vida a la historia de usuario.
• La tarea debe tener un responsable, un identificador, el trabajo
técnico a realizar y la cantidad de horas estimada por el equipo a
juicio experto.
4

5
 Daily Standup Meeting o Daily Scrum

Tablero kanban 15 minutos

Reunión técnica

Se realiza siempre en el
mismo lugar

Para cumplir con la ceremonia se debe

responder:

¿Qué
¿Qué hice haré hoy?
ayer?

¿Qué
problemas
tuve?
Equipo de desarrollo o development team, obligatoriamente.
 Sprint Review

Ex S cr
Stakeholders pueden u
el pl
i enc m M as
Equipo desarrollo lis e m c a ver de forma práctica, cer
a rg
a te r
explica que estuvo s e ta d n t q u e
e
como su producto les em de qu se
o n ia
ha e p os cor
r s
e la
bien, problemas y n d aporta valor y se a l e e c ta m e e c u m
té ro d e la q n p
soluciones rm u c desarrolla de acuerdo a e l é u ip o y te , a la
Equipo desarrollo in to x ito l i der p o
propuestas ad sus necesidades . a p ya
muestra el trabajo o a ra
términado

Stakeholder: Usuario,
Equipo Desarrollo Product Owner Cliente u otro Scrum Master
 Sprint Retrospectiva

Plan de acción
¿Qué estuvo
bien?
¿Qué podemos
mejorar?

Scrum Lidera la ceremonia el Scrum master

Master Participan obligatoriamente todo el scrum team
Product Es una ceremonia del equipo y no técnica del producto
Owner Asegurese de que todos hablén en la ceremonia
Obligatoriamente debe cerrar con un plan de acción
Equipo de desarrollo
Product Backlog Tareas o Task
Refinamiento

HU
1 Sprint
Backlog
HU
2
Refinamiento

HU
3

HU
4

HU
5
DONE Sprint
Goal