Teora de Scrum

Scrum se basa en la teora de control de

procesos emprica.
El empirismo ensea que el conocimiento
procede de la experiencia y de tomar decisiones
basndose en lo que se conoce.
Scrum usa un enfoque iterativo para aumentar
la predictibilidad y tener un mayor control del
riesgo.

Pilares de Scrum
Transparencia
Los aspectos
significativos del
proceso deben ser
visibles para aquellos
que son responsables
del resultado.
Quienes desempean
el trabajo y los que
aceptan el producto
deben manejar un
lenguaje comn.

 Inspeccin
Los usuarios deben
frecuentemente
inspeccionar el
progreso para detectar
variaciones.
La inspeccin no debe
ser tan frecuente como
para
que interfiera en el
trabajo.

 Adaptacin
Cuando se detectan que
uno o ms procesos de
desvan de los lmites
aceptables, el proceso
debe ser ajustado.
El ajuste debe realizarse
cuanto antes para
minimizar desviaciones
mayores

El equipo Scrum
Autoorganizados
Multifuncionales.
Entregan productos de forma
iterativa e incremental
Aseguran que siempre estar
disponible una versin til y
funcional del producto

Product Owner
Es el responsable de maximizar
el valor del producto y del
trabajo del Development Team.
La nica persona responsable de
gestionar el Product Backlog.
El Product Owner es una sola
persona.
El Development Team no debe
actuar con base en lo que diga
cualquier otra persona.

Development Team
Profesionales que desempean el trabajo de
entregar un Incremento de producto Terminado
al final de cada Sprint
Autoorganizados.
Multifuncionales.
Scrum no reconoce ttulos.
Scrum no reconoce sub-equipos.
La responsabilidad recae en el Development Team
como un todo.

Scrum Master
Lder al servicio del Equipo Scrum.
Da servicio al Product Owner.
Da servicio al Development Team.
Da servicio a la organizacin.

Eventos de Scrum
El Sprint
Sprint Planning Meeting
Daily Stand-up Meeting
Sprint Review
Sprint Retrospective

Sprint
Es un bloque de tiempo (time-box) de un mes o menos
durante el cual se crea un incremento de producto
Terminado, utilizable y potencialmente desplegable.
Contienen y consisten del Sprint Planning Meeting, el
Daily Stand-up Meeting, el Sprint Review y el Sprint
Retrospective.
Cada nuevo Sprint comienza inmediatamente despus
de la finalizacin del Sprint previo.

Durante el Sprint:
No se realizan cambios que puedan
afectar al Sprint Goal.
Los objetivos de calidad no disminuyen.
El alcance puede ser clarificado y
renegociado entre el Product Owner y el
Development Team a medida que se va
aprendiendo ms.

Debido a su corta duracin:

Habilitan la predictibilidad al asegurar la
inspeccin y adaptacin del progreso, al
menos en cada mes calendario.
Los Sprints tambin limitan el riesgo al
costo de un mes calendario.

Cancelacin de un Sprint
Puede ser cancelado antes de que el bloque de tiempo
llegue a su fin.
Solamente el Product Owner tiene la autoridad para
cancelar un Sprint.
Un Sprint se cancelara si el Objetivo del Sprint llega a
quedar obsoleto.
Todos los Elementos del Product Backlog no
completados se vuelven a estimar y se vuelven a
introducir en el Product Backlog.

Sprint Planning Meeting

El trabajo a realizar durante el Sprint se planifica en el
Sprint Planning Meeting .
Este plan se crea mediante el trabajo colaborativo del
Equipo Scrum completo.

 Tiene un mximo de duracin de

ocho horas para un Sprint de un
mes.
El Scrum Master se asegura de que
el evento se lleve a cabo y que los
asistentes entiendan su propsito.
El Scrum Master ensea al Equipo
Scrum a mantenerse dentro del
bloque de tiempo.

Preguntas que se responden en el

Sprint Planning Meeting.
Qu puede ser terminado en este Sprint?
El Development Team trabaja para proyectar la
funcionalidad que se desarrollar durante el Sprint.
El Product Owner discute el objetivo que el Sprint
debera lograr y los Elementos del Product Backlog que
lograran el Sprint Goal.
El Development Team proyecta qu elementos de la
Lista de Producto entregar en el Sprint .

Cmo se conseguir completar el trabajo

seleccionado?
Una vez que se ha establecido el objetivo y
seleccionado los elementos del Product Backlog para el
Sprint, el Equipo de Desarrollo decide cmo construir
esta funcionalidad para formar un Incremento de
producto Terminado.
El Development Team comienza diseando el sistema y
el trabajo necesario para convertir el Product Backlog
en un Incremento de producto funcional.
El trabajo planificado por el Equipo de Desarrollo para
los primeros das del Sprint es descompuesto en
unidades de un da o menos.

Spring Goal
Es una meta establecida para el Sprint que puede ser
alcanzada mediante la implementacin del Product
Backlog.
A medida que el Develoment Team trabaja, se
mantiene el objetivo del Sprint en mente.

Daily Stand-up Meeting

Es una reunin con un bloque de tiempo de 15 minutos

para que el Development Team sincronice sus
actividades y cree un plan para las siguientes 24 horas.

Durante la reunin, cada miembro del Equipo de

Desarrollo explica:
Qu hice ayer que ayud al Equipo de Desarrollo a
lograr el Objetivo del Sprint?
Qu har hoy para ayudar al Equipo de Desarrollo a
lograr el Objetivo del Sprint?
Veo algn impedimento que evite que el Equipo de
Desarrollo o yo logremos el Objetivo del Sprint?