Scrum trainer clase 7 y 8

4. FASES DE SCRUM
4.1. Fase de Inicio
4.2. Fase de Planificación y Estimación
4.3. Fase de Implementación
4.4. Fase de Revisión y Retrospectiva
4.5. Fase de Lanzamiento

Responsable del producto:
“Product Owner”
Responsables del
desarrollo: “Scrum Team”
Responsable del
funcionamiento de Scrum:
“ScrumMaster”
Roles
•Planificación del Sprint
•Seguimiento del Sprint
•Revisión del Sprint
•Scrum diario
Reuniones
•Product Backlog
•Sprint Backlog
•Incremento
•Graficos “Burndown”
Artefactos
ROLES, REUNIONES Y ARTEFACTOS

Cancel
Gift wrap
Return
Sprint
2-4 semanas
Objetivo del Sprint
Sprint
Backlog
Incremento del prod
potencialmente entr
Product
Backlog
Daily Scrum
24 horas
Responsable del producto:
“Product Owner”
Responsables del
desarrollo: “Scrum Team”
Responsable del
funcionamiento de Scrum:
“ScrumMaster”
Roles
•Planificación del Sprint
•Seguimiento del Sprint
•Revisión del Sprint
•Scrum diario
Reuniones
•Product Backlog
•Sprint Backlog
•Incremento
•Graficos “Burndown”
Artefactos
Incremento en
el Producto

Inicio del Proyecto o SPRINT 0
Primera reunión (Las primeras cuatro horas se dedican al Product
Owner):
En realidad se trata de un sprint en el que cabe todo. Cualquier idea
que quieras aplicar en tu proyecto se puede empezar a desarrollar en
este sprint previo. En cualquier caso, hay al menos 3 aspectos que
suelen quedar ya muy definidos. Son los siguientes:
• Características del producto: En este Sprint 0 tenemos que recabar
todo tipo de información acerca del producto y las características
que debe tener para su lanzamiento. ¿Cómo? Trabajando
activamente con el Product Owner.
• Estructura del Backlog: Fundamental durante esta fase. Definimos
cómo serán las historias de usuario y las dejamos preparadas para
fases posteriores.
• Equipo : En una reunión con el equipo se definen funciones y se
perfila el método de trabajo que vamos a seguir.

Marco de trabajo Scrum
Product
Owner

HISTORIAS DE USUARIO
-ESTIMACION
-PRIORIZACION
-VELOCIDAD

Qué son las historias de usuario
Las historias de usuario son descripciones, siempre
muy cortas y esquemáticas, que resumen la necesidad
concreta de un usuario al utilizar un producto o servicio, así
como la solución que la satisface.
Como muchas otras herramientas Ágiles, las historias de
usuario surgieron como una respuesta orientada al sector de
desarrollo de software, aunque con el tiempo se están
aplicando a otros tipos de negocio.
Su función principal es identificar problemas percibidos,
proponer soluciones y estimar el esfuerzo que requieren
implementar las ideas propuestas.

La utilidad de trabajar con historias de usuario
habitualmente
La implantación de este concepto permite añadir una visión más
amplia a nuestro proceso de desarrollo. Las siguientes son algunas de las
ventajas de trabajar con historias de usuario.
• Son deseos o necesidades muy concretas que se centran en partes
definidas del proyecto.
• Contienen información de una fuente externa que ve nuestro
producto sin prejuicios, el usuario potencial o real.
• Fomentan el trabajo en grupo en busca de soluciones.
• Permiten estimar el esfuerzo que va a requerir desarrollar una idea.
De lo que se trata es de invitar a la reflexión y fomentar
la conversación en torno a resolver una problemática concreta del
usuario o del proyecto, tanto de manera interna como incluyendo a
personas ajenas a la empresa.

Qué información incluyen
las historias de usuario
Para que sea verdaderamente útil, una historia de usuario debe incluir
cierta información precisa. A continuación repasamos los apartados básicos de
una historia de usuario:
• Título: Lo que resuelve la historia de usuario.
• Descripción: Se formula con la necesidad concreta del usuario y lo que le va a
aportar cuando esté finalizada.
• Prioridad: ¿Es fundamental?, ¿cómo es de importante?, simplemente se
expresa con un número del 0 al 100.
• Estimación: En esta parte se indica el esfuerzo que requerirá desarrollar e
implantar esta historia de usuario.
• Condiciones de aceptación: Lo que debe cumplirse para dar por finalizada la
historia de usuario.
A priori, no sería necesario incluir más información. Se trata es trabajar con ideas y
conceptos muy esquemáticos pero muy concisos, y estimar su esfuerzo e
importancia.

Estructura de User Story
Criteriosde
Aceptación
TítuloID
Descripción:
Quién Quiero Beneficio
Prioridad Estimación

Una historia de usuario debe estar
conformada por las 3C:
Card (tarjeta): Descripción escrita de lo
que necesita el usuario.
Convesación: El PO y el DT aclaran los
detalles.
Confirmación: Sirve para determinar lo
que se espera.
¿Cómo está conformada
una User Story?

Épicas e historias
• Ejemplo 1: Reportes de desempeño de ventas
Aquí la épica:
Como Vicepresidente de mercadeo y ventas, quiero revisar el desempeño histórico de las
ventas, para poder identificar las regiones geográficas y productos de mejor desempeño
Esta épica se puede subdividir en:
Como VP de Mercadeo, quiero seleccionar el período de tiempo en el cual realizaré la
revisión de las ventas.
Como VP de Mercadeo, puedo clasificar la información de ventas por región geográfica y
productos.
Ejemplo 2: Maximizar los ingresos de un hotel
Como un operador hotelero, quiero establecer las tarifas óptimas para las habitaciones de
mi hotel.
Esta historia se puede subdividir en:
Como un operador hotelero, quiero establecer la tarifa óptima para las habitaciones en base
a los precios del año anterior.
Como un operador hotelero, quiero establecer la tarifa óptima para las habitaciones en base
a las tarifas de otros hoteles comparables con el mío.

Ejemplos de historias de usuario
Autogestión de T.V. por suscripción
•
Ejemplo 3: Como Cliente, quiero suscribirme a un nuevo plan de T.V. por cable por medio del sitio web.
Ejemplo 4: Como Cliente, quiero pagar mi suscripción mensual vía sitio web por medio de transferencia
bancaria o tarjeta de crédito.
Ejemplo 5: Como Cliente, quiero suscribirme a un canal de T.V Premium por períodos flexibles de tiempo por
medio del sitio web.
Ejemplo 6: Como Cliente, consultar un listado de las suscripciones de Pay per View que se han realizado en mi
cuenta.
Sistema de ventas y distribución
•
Ejemplo 7: Como Vendedor, quiero registrar los productos y cantidades que me solicita un cliente para crear un
pedido de venta.
Ejemplo 8: Como Supervisor de ventas, quiero consultar un listado de los pedidos de venta que han sido
registrados y aún no han sido procesados.
Ejemplo 9: Como Gerente de ventas, quiero consultar los pedidos de venta procesados clasificándolos por
vendedor, región y líneas de producto.
Ejemplo 10: Como Analista de logística, quiero seleccionar un pedido de venta y enviarlo al almacén para que
procedan con su preparación.

Task
El trabajo técnico que realiza un equipo de
desarrollo para completar un ítem de retraso
acumulado del producto.
La mayoría de las tareas se definen como
pequeñas, lo que representa no más de unas
pocas horas a un día más o menos de trabajo.

Estimación
Por ahora sólo tenemos historias. Falta estimarlas y priorizarlas.
El proceso de estimación se puede hacer utilizando una técnica llamada planning
poker (póker de planificación).
El objetivo del planning poker es obtener una medida de tamaño relativo de todas las
historias respecto a sí mismas. La teoría es que resulta relativamente fácil decir “A es
más grande que B y que C”
Lo importante de efectuar planning poker sobre todo el backlog (a efectos de la
planificación) es que da como resultado que todas las historias han sido estimadas con
muy poco esfuerzo.
Pero no en días/hombre como se haría tradicionalmente. Planning poker produce
estimaciones en una medida arbitraria de tamaño llamada story points o “puntos de
historia”.
Los story points son específicos de cada equipo, no pueden compararse entre
diferentes equipos y a veces ni siquiera entre diferentes proyectos del mismo equipo.
Lo único que indican es el tamaño relativo que tiene cada funcionalidad del backlog
respecto a las demás. Lo importante es que ahora tenemos el tamaño total del
proyecto estimado en una unidad llamada story points, y esto nos va a servir de
mucho.

Estimación de póquer
• La estimación no la realiza el cliente / Product Owner, por que no es él quien se va
a “ensuciar las manos” y luchar por cumplir con fechas.
• Todo el equipo realiza la estimación para:
– Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente.
– Reforzar el compromiso de cada miembro del equipo respecto al resto.
– Hacer que todo el mundo se sienta oído.

• Procedimiento
– Cada participante de la reunión tiene un juego de cartas.
– Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que
se va a estimar) el cliente, moderador o propietario del producto expone la descripción
empleando un tiempo máximo.
– Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las
posibles preguntas del equipo.
– Cada participarte selecciona la carta, o cartas que representan su estimación, y las
separa del resto, boca abajo.
– Cuando todos han hecho su selección, se muestran boca arriba.
– Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea
debe dividirse en sub-tareas de menor tamaño.

Si las estimaciones resultan muy dispares, quien asume la responsabilidad de
gestionar la reunión, con su criterio de gestión, y basándose en las características
del proyecto, equipo, reunión, nº de elementos pendientes de evaluar, puede
optar por:
– Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es
necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo?
Tras escuchar las razones, repetir la estimación.
– Dejar a un lado la estimación de esa tarea y retomar al final o en otro
momento aquellas que hayan quedado pendientes.
– Pedir al cliente o propietario del producto que descomponga la funcionalidad y
valorar cada una de las funcionalidades resultantes.
– Tomar la estimación menor, mayor, o la media.
Este protocolo de moderación, evita en la reunión los atascos de análisis circulares
en ping-pong entre diversas opciones de implementación, hace participar a todos
los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación
de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin
discusiones, y además resulta divertido y dinamiza la reunión.

Priorización
La etapa de priorización es sencilla y depende exclusivamente del Product Owner.
Sabiendo ya el tamaño de las historias, debe priorizarlas por valor de negocio.
Notar que también es posible comenzar con la asignación de valor y después
aportar el tamaño, en todo caso, la priorización se realiza balanceando el valor
respecto al coste y respecto a los riesgos de cada objetivo.
Una manera rápida de empezar a asignar valor a las historias es dividirlas en 3
grupos, según sean imperativas, importantes o cosméticas/prescindibles (de
manera que si se llega a una fecha de entrega predeterminada y no se
han completado por lo menos hemos aportado el máximo de valor posible).
Dentro de cada grupo nos resultará más fácil realizar una ordenación relativa por
valor y después asignarlo.
La prioridad puede cambiar todo el tiempo; pero el tamaño en story points debe
mantenerse fijo con la estimación original (o sea: como regla general, no
reestimar). Si aparecen historias nuevas, deben estimarse utilizando el mismo
criterio que se utilizó originalmente.

VELOCIDAD
El último paso, por lo tanto, es calcular la velocidad del equipo completando objetivos a lo
largo de las iteraciones.
Así pues, la velocidad es la cantidad de story points que se completan por iteración.
Calcularla es sencilla: solo hay que sentarse y esperar. En dos -como máximo tres-
iteraciones, tendrás una idea bastante clara de cuál es la velocidad del equipo y por lo tanto
el tamaño y duración del proyecto.
Mientras tanto se puede ir construyendo el burndown chart.
El burndown chart nos muestra en el eje Y la cantidad total de story points del proyecto, y
sobre el eje X las iteraciones. Cada vez que se finaliza una iteración, se completa un punto
del gráfico, indicando la velocidad en ese ciclo.
Si teníamos una fecha prefijada en la que queremos terminar el proyecto, esto nos permite
calcular la velocidad teórica a la que tendremos que ir para alcanzar esa fecha. El burndown
chart permite rápidamente y en todo momento ver dos estadísticas vitales para la
planificación: la estimación actual de cuándo va a estar terminado el 100% del proyecto; y
la estimación del porcentaje de proyecto que va a estar terminado cuando lleguemos a
cierta fecha.

Definición de Done
(Criterios de Aceptacion)
Son los acuerdos del PO con los Stakeholders que
contiene todas las condiciones que deben de cumplir
los ítems del Product Backlog para considerar un Sprint
completado o finalizado.
59

Definición de READY
(RoD)
Análoga a la Definición de “Hecho”, la definición
de “Listo” es un acuerdo entre del equipo,
especialmente entre el Product Owner y el
equipo de Desarrollo donde se colocan los
criterios por las cuales una historia se encuentra
lista para ser implementada dentro de un sprint.
Básicamente, es un conjunto de condiciones -y
un checklist también- a la cual se somete una
historia para ser tomada en un Sprint Planning.

Time-Boxing
Time-boxing es una práctica crítica en Scrum y debe aplicarse con cuidado.
• Un Time-boxing arbitrario puede llevar a la desmotivación del equipo y puede tener
como consecuencia la creación de un entorno opresivo, por lo que Time-boxing debe
ser utilizado de manera apropiada.
Beneficios:
• Procesos de desarrollo eficiente.
• Menos gastos generales.
• Alta velocidad para los equipos.
• Ayuda a gestionar eficazmente la planificación y ejecución de proyectos.

¿Dónde se utilizan los Time-Boxing?

Eventos formales
Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la
inspección y adaptación:
• Planificación del Sprint (Sprint Planning) : DIAS/FECHAS/RESERVAS
• Scrum Diario (Daily Scrum) : LUGAR / HORA
• Revisión del Sprint (Sprint Review) : DIAS/FECJAS/RESERVAS
• Retrospectiva del Sprint (Sprint Retrospective) : DIAS /FECHAS /RESERVAS

Estructura del Product Backlog

Que es el Product BackLog
• Product BackLOG: Es lista de requisitos de
usuario que se origina con la visión inicial del
producto y va creciendo y evolucionando
durante el desarrollo.
• Todas las tareas deben listarse en el product
backlog, para que estén visibles ante todo el
equipo y se pueda tener una visión panorámica
de todo lo que se espera realizar.
36

¿Qué tan extenso puede ser?
• Si el proyecto o producto amerita una lista larga,
podemos tener cientos o miles de actividades
en el product backlog.
• Nosotros asignamos prioridades sobre el
product backlog, en base a las necesidades del
cliente y la complejidad de cada actividad.
• Así mismo, de forma sucesiva, cada sprint
produce detalles adicionales, en el diseño, en la
funcionalidad, y la verificación de actividades.

Product Backlog
• El product backlog es un documento de alto nivel para todo el proyecto.
Contiene descripciones genéricas de todos los requerimientos,
funcionalidades deseables, etc. priorizadas según su retorno sobre la
inversión.(ROI).
• Contiene estimaciones del valor para el negocio, como del esfuerzo de
desarrollo requerido.
• Esta estimación ayuda al product owner a ajustar la línea temporal y, de
manera limitada, la prioridad de las diferentes tareas.
• Por ejemplo, si dos características tienen el mismo valor de negocio la que
requiera menos tiempo de desarrollo tendrá probablemente más
prioridad, debido a que su ROI será más alto.

Ingresar
credenciales
Ingreso al Sitio
Sitio de Compra en Línea
Compra Pago y Entrega
Crearnueva
cuenta
Ver Detalle de
un Producto
Añadir al
carrito forma de pago
Establecer
Delivery
Ingresaral
Sitio
Estado del
Pedido
Búsqueda de Ver catálogo
REpro
Lduc
Etos
ASde P
Eroduct
1os
RELEASE 2
RELEASE 3

Ingresar
credenciales
Ingreso al Sitio Compra Pago y Entrega
Crearnueva
cuenta
Ver Detalle de
un Producto
Añadir al
carrito forma de pago
Establecer
Delivery
Ingresaral
Sitio
Estado del
Pedido
Búsqueda de Ver catálogo
REpro
Lduc
Etos
ASde P
Eroduct
1os
RELEASE 2
RELEASE 3

Ingreso al Sitio
Sitio de Compra enLínea
Compra Pago y Entrega
Crear nueva
cuenta
Ingresar
credenciales
Búsqueda de
productos
Ver catálogo
de Productos
Un Comprador
desea ingresaral
sitio para poder
Como un
Comprador desea
realizar una compra relizar el proceso
de login para
poder realizar una
compra
buscar productos
una compra
Un Comprador deseaUn Comprador desea
ver el detalle de un
para poder realizar producto parapoder
analizar su compra
Ver Perfil Ver Detalle de
un Producto
Añadir al
carrito
Seleccionar la
forma depago
Establecer
direcciónde
Delivery
Estado del
Pedido

PRODUCT BACKLOG
Product Backlog
Un Compradordesea
ingresar al sitio para
poder realizar una
compra
compra
Como un Comprador
desea relizar el
proceso de login para
poder realizar una
compra
Un Comprador
desea buscar
productos para
poder realizaruna
Un Comprador
desea ver el detalle
de un producto para
poder analizar su
compra
Prioridad
1pt
8pts
5pts
3pts

PRODUCT BACKLOG
compra
Product Backlog
Un Compradordesea
ingresar al sitio para
poder realizar una
compra
Como un Comprador
desea relizar el
proceso de login para
poder realizar una
compra
Un Comprador
desea buscar
productos para
poder realizaruna
Un Comprador
desea ver el detalle
de un producto para
poder analizar su
compra
Prioridad

SCRUM 10 Sprint Cero
Proyect
o
Paso1
DueñodeProducto
ElEquipo
#!/bin/sh

Proyect
o
Paso1
ElEquipo
#!/bin/sh
DueñodeProducto

Estimación
• La estimación no la realiza el cliente / Product Owner, por que no es él quien se va
a “ensuciar las manos” y luchar por cumplir con fechas.
• Todo el equipo realiza la estimación para:
– Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente.
– Reforzar el compromiso de cada miembro del equipo respecto al resto.
– Hacer que todo el mundo se sienta oído.

Proyect
o
S
X
S
S
M
M
M
Paso1
ElEquipo
#!/bin/sh
#!/bin/sh
#!/bin/sh

Proyect
o
S
X
S
S
M
M
M
Paso1
DueñodeProducto
Más prioritario
Menos prioritario

Backlog grooming
(o refinamiento del backlog)
Es la reunión en la que el dueño de producto y el
equipo se reunen para revisar la pila de producto y
añadir, retirar o reestimar historias de usuario
Se puede hacer 2 reuniones de este tipo en sprints de
3 semanas, aunque no es obligatorio que sean
reuniones programadas, pudiendo aparecer la
necesidad de organizar una en cualquier momento
durante el transcurso del Sprint.

PARA que Sirve?
• Para que el dueño de producto tenga las
conversaciones necesarias con el equipo antes de
introducir una historia de usuario en el backlog.
• Para que el dueño de producto pueda estimar las
historias con el feedback proporcionado por el
equipo.
• Para evitar que el equipo se quede sin historias
en las que trabajar.
• Para incorporar al backlog el feedback
proveniente de las demos y del producto en
producción.

DEFINICION FINAL
Contiene todo el trabajo que es necesario para el desarrollo o
construcción de nuestro sistema o producto y es responsabilidad
del Product Owner. De hecho, es el resultado del trabajo del Product
Owner con los diferentes interesados (cliente/s, usuario/s).
Se trata de un documento vivo que contiene todo el trabajo pendiente
que falta por ejecutar, hasta completar el alcance identificado y
deseado para el producto, al margen de su grado de refinamiento.
Por lo general, según se avanza en la ejecución de Sprints y haciendo
entregas iterativas de incrementos de valor, su tamaño irá
disminuyendo. Salvo por la aparición de más trabajo, sea en forma de
incidencias (Bugs) o en nuevas historias de usuario para añadir
requisitos y funcionalidades al producto, por ejemplo.

SCRUM 10 Backlog grooming
Sprint 2 Sprint 3Sprint 0 Sprint 1
Backlog grooming

Backlog grooming
Validar prioridades (nuevas
historias, ...)

Backlog grooming
historias, ...) Subdividir historias
muy grandes

Backlog grooming
historias, ...) Subdividir historias
muy grandes
Verificar historias están listas
(dependencias)

• 1. Elige un responsable de producto (Product Owner).
• Esta persona es la que tiene la visión clara de lo que se necesita, se
va a hacer, fabricar o conseguir. tendrá en cuenta riesgos y
compensaciones, qué es posible y qué es factible.
• 2. Elige un equipo.
• ¿Quién va a hacer el trabajo
real? Este equipo necesita tener las habilidades necesarias para
convertir en realidad la visión del responsable de producto. Los
equipos tienen que ser pequeños: entre 3 y 9 personas es lo
normal.
• 3. Elige un Scrum Master.
• Es la persona que conducirá a todos los demás por el sistema de
trabajo Scrum ayudando al equipo a eliminar todo aquello que les
frene. Quitar desperdicios.

Product owner
- Representante del cliente y stakeholders
- Tiene autoridad para cambiar y/o definir el producto
- Acepta o rechaza el resultado del sprint
- Solo uno por equipo
- Trabaja junto con el equipo
- Propietario de la lista de requerimientos
- Prioriza los requerimientos
- Responsable de la rentabilidad del producto

Scrum master
- Facilitador y líder del equipo
- Remueve impedimentos del equipo
- Promueve valores, principios y prácticas scrum
- Solo uno por equipo
- Trabaja junto con el equipo
- Responsable del producto

Equipo
- Pocos integrantes (6 +/- 3)
- Multifuncional e interdisciplinario
- Trabajan a tiempo completo en un sprint
- Auto-organizado y auto-disciplinado
- Definen y estiman tareas de cada requerimiento
- Propietario de la lista de tareas
- Comprometido y descentralizado

4.2 Planificación y
Estimación

Ball Point Game
Un juego para sentir Scrum

Reglas
• Todos son un gran equipo
• La bola debe tener tiempo aire
• El Punto de Inicio es el Punto Final
• Iteración de 2 minutos
• 1 minuto de Retrospectiva

SPRING PLANNING(4 horas)
– Se identifican y estiman las tareas para satisfacer
– Se crea un Sprint Backlog
– Las tareas son distribuidas por decisión de los miembros
del equipo
– Los miembros del equipo se comprometen a cumplir con la
meta del Sprint
• Entradas:
– Backlog del producto actualizado
– Retorno del ultimo Sprint
– Rendimiento del equipo en los Sprints anteriores
• Salida:
– Pila del sprint (Sprint Backlog)

Sprint BackLog
• Sprint Backlog: Lista de los trabajos que debe realizar el
equipo durante el sprint para generar el incremento previsto.
• Incremento: Resultado de cada sprint
72

SCRUM 10 Reunione
s
Planificación de Sprint (Sprint Planning)
Se planifica la iteración
Dura 4h para Sprints de 2
semanas 2 partes (2h cada
una)
Se planifica que se va a hacer (PO +
Equipo) El equipo discute cómo lo va
a hacer (Equipo)

SCRUM 10 Reunione
s
Planificación de Sprint (Sprint
Planning)
Se planifica la iteración
semanas 2 partes (2h cada
una)Se planifica que se va a hacer (PO +
Equipo) El equipo discute cómo lo va
a hacer (Equipo)
¡OJO!
Eselequipoelque
decidequéy cuanto
hace

Reunión de planificación de Sprint
El trabajo a realizar en el Sprint se prevé en la Reunión de Planificación del Sprint. Este plan
se crea con la colaboración de todo el Equipo Scrum.
La reunión de planificación de un Sprint es un evento de tiempo variable. Para un Sprint de
un mes tiene ocho horas de duración.
Para Sprints más cortos, el evento es proporcionalmente más corto. Por ejemplo, para un
Sprint de dos semanas, las reuniones de planificación de Sprint son de cuatro horas de
duración.
En esta reunión se define la funcionalidad en el incremento planeado y cómo el Equipo de
Desarrollo creará este incremento y la salida de este trabajo es definir el Objetivo del
Sprint.
La reunión de planificación de Sprint tradicionalmente consta de dos partes, cada una de la
mitad de tiempo de duración de la Reunión de Planificación respondiendo a las siguientes
dos preguntas:
• ¿Qué va a ser entregado en el incremento resultante del próximo Sprint?
• ¿Cómo se va a realizar el trabajo seleccionado?
A destacar que el objetivo del Sprint puede ser un hito en el objetivo más amplio de la hoja
de ruta (roadmap) del producto.

• Gestión del Sprint Backlog
– Los individuos eligen las tareas
– El trabajo nunca es asignado
– La estimación del trabajo restante es actualizada
diariamente
– Cualquier miembro del equipo puede añadir, borrar o
cambiar el Sprint Backlog
– El trabajo para el Sprint emerge
– Si el trabajo no está claro, definir un tema del Sprint
Backlog con una mayor cantidad de tiempo y subdividirla
luego.
– Actualizar el trabajo restante a medida de que más se
conoce

Sprint Planning meeting
Priorización
• Analizar y evaluar el Product
Backlog
• Seleccionar el objetivo del
Sprint
Planificación
• Decidir como alcanzar el
objetivo del Sprint (diseño)
• Crear el Sprint Backlog (tareas)
en base a los temas del
Product Backlog (user stories /
features)
Objetivo
del Sprint
Sprint
Backlog
Condiciones
del Negocio
Capacidad
del Equipo
Product
Backlog
Tecnología
Producto
Actual

Team
Product
Owner
Sprint Planning

SCRUM 10 Artefacto
s
Más prioritario
Proyecto
Menos prioritario
Selecciónpara Sprint
ElEquipo
#!/bin/sh
#!/bin/sh
#!/bin/sh

SCRUM 10 Artefacto
s
Pila del
Sprint
(Sprint
backlog)
Proyecto
Tareas
Más prioritario
Menos prioritario
ElEquipo
#!/bin/sh
#!/bin/sh
#!/bin/sh

SCRUM 10 Sprint
Proyecto
Tiempo predefinido (1-4
semanas) Compromiso de
terminar x historias

SCRUM 10 Sprint
Proyecto
Sprint 1
Revisióndel Sprint
Tiempo predefinido (1-4
semanas) Compromiso de
terminar x historias
ReunióndeSprint

SCRUM 10 Sprint
Proyecto
Sprint 1 Sprint 2
Don
e

SCRUM 10 Sprint
Proyecto
Sprint 1 Sprint 2
Don
e
Done Done

SCRUM 10 Sprint
Proyecto
Sprint 1 Sprint 3Sprint 2
Don
e
Done Done

SCRUM 10 Sprint
Proyecto
V1.
0
Sprint 1 Sprint 3Sprint 2
Don
e
Done Done DoneDone Done

Sprint
• Periodo fijo de tiempo durante el cual el equipo desarrolla
un incremento de funcionalidad (no mas de 30 dias)
• No se aceptan cambios a los requerimientos acordados.
• El producto es diseñado, codificado, probado durante el
Sprint.
• Solo el Product Owner puede cancelar el Sprint cuando:
– La tecnologia no funciona
– Las circunstancias del negocio cambiaron
– El equipo tuvo interferencias
• Las iteracciones cortas permiten reducir los riesgos

Recomendaciones de los Sprint
Cuando el sprint está en curso, debemos asegurar que:
• No se realizan cambios que afectan al objetivo del Sprint;
• No disminuyen los objetivos de calidad, y
• El Alcance podrá aclararse y re-negociarse entre el
propietario del producto y el Equipo de Desarrollo a
medida que se va aprendiendo.
Cuando un Sprint es demasiado largo, la definición de lo
que se está construyendo puede cambiar, puede aumentar
la complejidad y puede aumentar el riesgo. Los Sprints
permiten previsibilidad al garantizar la inspección y la
adaptación de los avances hacia una meta de por lo menos
cada mes de calendario.

Team
Daily Scrum
Scrum
Master

Debe hacerse a primera hora de la mañana.
El mejor momento del día para hacer la Daily Scrum lo determinará el Development
Team. La hora fijada debe mantenerse constante, al igual que el sitio donde se vaya a
realizar, así evitaremos perder tiempo cada día decidiendo dónde llevarla a cabo.
Otra premisa es que el evento se realizará a diario, algo que parece obvio al llamarse
“Daily”, pero que en muchos equipos no se cumple.
Tiene que hacerse de pie.
Otro mito es que la Daily Scrum tenga que hacerse de pie. Esta es una técnica que se
aplica para evitar que se alargue más de 15 minutos, el tiempo máximo recomendado.
Para ello, cada Development Team tiene que autoorganizarse y es el Scrum Master el
que debe enseñarles y ayudarles a conseguirlo. Buen signo de ello es que el día en el
que el Scrum Master se ausenta, el evento se desarrolla con éxito y funciona
La duración depende del número de personas implicadas.
Recordemos que el tiempo máximo que dura la Daily Scrum es de 15 minutos y no dependerá
ni del número de participantes ni del tamaño del Sprint.

SCRUM 10 Reunione
s
Scrum Diario (Daily Scrum)
Comienza a la misma hora
siempre Se realiza en el mismo
lugar siempre Dura 15 minutos
(Equipo + SM)
¿Qué has hecho ayer?
¿Qué vas a hacer hoy?
¿Qué impedimentos has
encontrado?

Daily Scrum (Comenzar / Parar /
Continuar)
• Breve reunión diaria para repasar cada una de las tareas y el trabajo
previsto de la jornada. Dura 15 minutos
• Sólo interviene el equipo de desarrollo
• No para la solución de problemas. No es dar un reporte de estado al
Scrum Master, se trata de compromisos delante de pares
– Todo el mundo está invitado
– Sólo los miembros del equipo participan, scrum master y producto
owner puede hablar si fuera necesario
– Ayuda a evitar otras reuniones innecesarias

SCRUM 10
Historias Pendiente
Mejoras al tablón
Desarrollo Testing Terminado

SCRUM 10
Historias Pendiente
Mejoras al tablón
Fuego

SCRUM 10
Historias Pendiente
Mejoras al tablón
Fuego
Evolutiv
o Bug

SCRUM 10
Historias Pendiente
Ejemplos
tablones

SCRUM 10
Historias Pendiente
Proyecto:
Equipo:
Burn Down:
Release Plan:
Impedimentos:
Demo:
Ejemplos
tablones
Desarrollo Terminado

SCRUM 10
Historias Pendiente
Artefacto
s
Proyecto:
Equipo:
Burn Down:
Release Plan:
Impedimentos:
Demo:
Tablón Scrum

SCRUM 10
Historias Pendiente
Artefacto
s
Proyecto:
Equipo:
Burn Down:
Release Plan:
Impedimentos:
Demo:
Tablón Scrum
Historias d
(Pila deP
eusuario
roducto)

SCRUM 10
Historias Pendiente
Artefacto
s
Proyecto:
Equipo:
Burn Down:
Release Plan:
Impedimentos:
Demo:
Tablón Scrum
Tareasdela historia
(Pila del Sprint)

SCRUM 10
Historias Pendiente
Artefacto
s
Proyecto:
Equipo:
Burn Down:
Release Plan:
Impedimentos:
Demo:
Tablón Scrum
Tareasen desarrollo

SCRUM 10
Historias Pendiente
Artefacto
s
Proyecto:
Equipo:
Burn Down:
Release Plan:
Impedimentos:
Demo:
Tablón Scrum
Tareaster minadas

SCRUM 10
Historias Pendiente
Artefacto
s
Proyecto:
Equipo:
Burn Down:
Release Plan:
Impedimentos:
Demo:
Tablón Scrum
Informacióndel proyecto

Team
Product
Owner
Sprint Review

SCRUM 10 Reunione
s
Revisión del Sprint (Sprint Review)
Se realiza al terminar el Sprint
semanas
Se explica que se ha hecho y que
no Se enseña lo que se ha
hecho (demo) PO valida o no lo
realizado
Se discute la pila de producto

• El Sprint Review es LA REUNION de negocio por excelencia.
Durante el mismo se pone de manifiesto la transparencia en torno
al incremento, se inspecciona y se adapta el Product Backlog.
• El Sprint Review es la oportunidad para que todos los
Stakeholders, incluido el propio equipo Scrum, inspeccionen el
incremento terminado durante el Sprint. Para ello es importante,
además de invitar a los Stakeholders para promover la
transparencia, tener claras cuales son las condiciones actuales de
negocio y el Product Backlog, para poder actualizarlo al terminar la
Review.
• La Sprint Review se organiza y coordina por el Product Owner, no
por el Scrum Master ni el Development Team.

COMPONENTES para el Sprint Review
• El equipo Scrum
• Un Incremento terminado (que cumpla la Definition of
Done)
• El Sprint Backlog
• El Product Backlog
• Las condiciones actualizadas del negocio.
• Stakeholders.
Y el resultado es:
• Un Product Backlog actualizado con el feedback de
Stakeholders

Incremento
• Demostración de los objetivos alcanzados en cada sprint
• Asistencia de todos los roles, “Product Owner” e incluso usuarios
• Sólo el Product Owner puede abortar un Sprint debido a una de las
siguientes razones:
– La tecnología seleccionada no funciona o es incompatible con los objetivos
definidos
– Han cambiado las circunstancias de negocio
– El Scrum Team ha tenido inferencias

SCRUM 10 Artefacto
s
Diagrama Burn
Down (Burn
Down chart)Pila del Sprint
ElEquipo
#!/bin/sh
#!/bin/sh
#!/bin/sh
00% 00%0% 0%45%
4
2
0
1
4
1
2
1
0
8
6
Trabaj
o
0 1 2 3 4 5 6 7 8 9
10
Tiempo

SCRUM 10 Artefacto
s
Diagrama Burn
Down (Burn
ElEquipo
#!/bin/sh
#!/bin/sh
#!/bin/sh
00% 00%0% 0%45%
Tareaspendientes
Progresoideal
4
2
0
1
4
1
2
1
0
8
6
Trabaj
o
0 1 2 3 4 5 6 7 8 9
10
Tiempo

4
2
0
1
4
1
2
1
0
8
6
Trabaj
o
0 1 2 3 4 5 6 7 8 9
10
Tiempo
SCRUM 10 Artefacto
s
Diagrama Burn
Down (Burn
ElEquipo
#!/bin/sh
#!/bin/sh
#!/bin/sh
00% 00%0% 0%45%
0 tareasterminadas
vs
2 tareasterminadas

SCRUM 10 Artefacto
s
0
4
2
6
1
4
1
2
1
0
8
0 1 2 3 4 6 7 8 9
1
0
Trabaj
o
5
Tiemp
o
Tendenciasi no
cambiamos

SCRUM 10 Artefacto
s
0
2
4
6
1
4
1
2
1
0
8
0 1 2 3 4 6 7 8 9
1
0
Trabaj
o
5
Tiemp
o
Tendenciasi no
cambiamos
+
1

SCRUM 10 Artefacto
s
0
1
4
1
2
1
0
8
6
4
2 0 1 2 3 4 6 7 8 9
1
0
Trabaj
o
5
Tiemp
o

Team
Scrum
Master
Retrospective

SCRUM 10 Reunione
s
Retrospectiva del Sprint (Sprint Retro.)
SM anima al Equipo a revisar el
proceso Se revisan:
Personas, relaciones,procesos y
herramientas
Retrospectiva:
¿Qué ha fallado?
¿Qué se puede mejorar?

Retrospectiva del Sprint
Es una oportunidad para el Equipo Scrum de
inspeccionarse a sí mismo y crear un plan de mejoras
para ejecutar durante el siguiente sprint. El propósito de
la retrospectiva de Sprint es:
• Revisar cómo fue el último Sprint en lo que respecta a
las personas, relaciones, procesos y herramientas;
• Identificar y ordenar los temas principales que salieron
bien y las potenciales mejoras, y
• Crear un plan para la implementación de mejoras con
respecto a cómo el Equipo Scrum hace su trabajo.
Espero que con estas cinco etapas, y las claves para cada
una de ellas, podéis aseguraros del éxito de cada Sprint

Retrospectiva
La base de la mejora continua

¿Qué es la retrospectiva del sprint?
La realidad
Herramientas
Beneficios
Conclusiones
1
3
3

¿Qué es la retrospectiva?
La retrospectiva, es el proceso donde el equipo analiza la forma en que trabajan buscando la mejora continua, uno de
los principales valores de la gestión ágil.
Su objetivo, es crear conciencia sobre su desempeño y sus consecuencias, para que defina hacia dónde quiere ir,
durante este proceso pasan por 5 etapas, aunque no sean formales, estas son:
¿Dónde estamos ahora?
1. Situación
1. Preparar el escenario.
2. Objetivos
¿Dónde
queremos estar?
3.Estrategias
¿Cómo lo
lograremos?
4. Tácticas
¿Qué medios vamos a usar?
5. Acciones
¿Qué actividades
haremos?
6. Control
1
3
4
¿Cómo vamos a
medir la mejora?
2. Revisar indicadores.
3. Reflexionar.
4. Decidir qué hacer, quien lo hará ycuando.
5. Cierre.

¿Qué obtienes de la retrospectiva?
Reunión de
Retrospectiva
Siguiente
Sprint
Circulo de Deming

La realidad
Herramientas
Beneficios
Conclusiones

¿Qué haces si ves una
oportunidad para mejorar?

Estrella de mar (Starfish
retrospective)La Starfish retrospective tiene ciertas ventajas frente a la forma “clásica” de llevar retrospectivas,
es decir la de
solo llevar las cosas como “lo malo” y “lo bueno”.
• ¿Qué debe contener cada parte?
- Seguir haciendo: Lo que venimos haciendo, lo que funciona y
• que nos brinda valor.
- Hacer más: Practicas que requieren mas
refinamiento y que nos gustan mucho por ello
hay que desarrollarlas mas.
- Empezar a hacer: Cosas innovadoras que desean
probar, o soluciones comprobadas que
deberíamos usar.
- Dejar de hacer: Cosas que no dan valor, no funciona o
• simplemente una practica que se puede optar por eliminarla.
- Hacer menos: Aquello que utilizamos pero no nos
dan tanto beneficio como se esperaba.

Speed Boat
El origen de esta técnica se remonta a Luke Hohmann, quien la presentó como uno de los juegos de innovación en
su libro "Innovation Games". Hay muchos templates para esta técnica del velero, pero la que más se suele usar es
la que contiene los siguientes elementos:
- El barco velero: Significa el equipo, los miembros del equipo
son su tripulación.
- Una isla paradisiaca: Es la tierra prometida, el escenario ideal,
representa la visión del proyecto.
- El viento: Indican las fortalezas del equipo, representa lo que
lo impulsa o lo que se necesita para llegar a la isla.
- Un ancla: Simboliza las debilidades internas del equipo,
aquello que los obstaculiza.
- Unas rocas: Son las amenazas o riesgos externos al equipo
que complican su viaje hacia la isla paradisiaca.
- Un sol brillando en el cielo (opcional): Indica aquellos
elementos externos al equipo que le ayudan a sentirse mejor
y focalizarse en su trabajo.

Beneficios
La retrospectiva buscar crear las condiciones para lograr una mayor flexibilidad, agilidad y una gran capacidad de
respuesta al cambio, para así lograr un alto desempeño en la productividad y la calidad.
Beneficios:
- No se toman decisiones “perfectas”, ¡se mejora continuamente!
- Se logran rendimientos esperados o superiores.
- Se mejoran los tiempos de entrega (Time to Market).
- Se elimina lo que no agrega valor o reduce la productividad.
- Se mejora la calidad del producto.
- Potencia el aprendizaje del equipo de manera sistemática.
- Aumenta la motivación del equipo.
- Refina el Product BackLog, añade detalles, mejora su estimación
y ayuda a ordenar mejor los elementos.}
- Mejora los procesos.
- Habilita la autogestión de un equipo.

La realidad
Herramientas
Beneficios
Conclusiones
Carlos R

Conclusiones
1. Todo el equipo debe tener el mismo peso a la hora de opinar. Tú
opinión es tan importante como la del cualquier otro presente
independientemente del título o experiencia que tenga.
2. Céntrate en los problemas y no pienses en el culpable. Pensar
con mentalidad de Equipo, aunque el problema lo haya causado
otro compañero o tú mismo, es lo importante para encontrar la
raíz por lo que pasó y sobretodo, para que no vuelva a ocurrir.
3. Figuras de Managers fuera, por favor. Suelen influir en la
dinámica, la retrospectiva suele ser mucho mejor y conducirse
sin problemas.
La retrospectiva debe ser un lugar seguro para expresarse:

Conclusiones
1. Mantener retrospectivas anteriores y repasar resultados.
Mejor si es en un documento compartido que todo el equipo
pueda ver.
2. Filtrar mejoras, quedarse con aquellos que el equipoconsidere
más importantes. En cada retrospectiva saldrán muchos
asuntos a tratar, siempre será más realista centrarse en
solucionar los más importantes que intentar resolverlos todos.
3. Poner objetivos/acciones y responsables para resolver los
problemas. Aunque todos estamos motivados para que se
mejore, es mejor que alguien en concreto asuma el trabajo para
asegurarnos que se sigue hasta completar el objetivo.
Debe ayudar a romper hábitos que no gustan al equipo y mejorar:

Buenas prácticas
- Tareas de 8 horas
- Ubicar a todo el equipo en el mismo lugar
- Tener el Sprint Backlog en un lugar visible
- Realizar testeos en todos los Sprints
- Facilitar la comunicación
- Utilizar herramientas de control

Caso práctico
Un cliente se pone en contacto con una empresa que fabrica robots.
El cliente les realiza el pedido.
Quiero un robot que me sirva de
escolta

Caso práctico
El Cliente se reune con el Dueño de producto, que toma nota de lo que tiene en su
cabeza.
Cliente Dueño de Producto

Caso práctico
El Duelo de Producto divide el proyecto en historias que son las que componen la pila de
producto.
Dueño de Producto
Pila de Producto

Caso práctico
El Scrum Master es un miembro del equipo que tiene el papel de comunicar y gestionar las
necesidades del Dueño de Producto y la pila de Sprint.
El Dueño de Producto le entrega la pila de producto para que estimen el coste de creación
del producto.
Dueño de Producto Scrum Manager

Caso práctico
El equipo se reune para estimar el coste de cada historia de la pila de producto.
En este caso utilizan Planning Poker.
Equipo

Caso práctico
El cliente, una vez aprobado el presupuesto, reordena la pila de producto para que el
equipo vaya trabajando según la prioridad del cliente.
Cliente
Menos imporantes
Urgentes

Caso práctico
El equipo comienza su trabajo desglosando la primera historia de la pila de producto, la
cual subdividen en tareas menores para crear la pila de sprint.

Caso práctico
La pila de sprint tiene como utilidad fraccionar el trabajo de un periodo de 15 días en
tareas mas pequeñas, que tarden como mucho dos días.

Caso práctico
Estas tareas se colocan en una pila, la cual prioriza el Dueño de Producto, que ha
consultado con el cliente, antes de comenzar el sprint.
Dueño de Producto
Menos imporantes
Urgentes

Caso práctico
El equipo comienza el sprint tomando las tareas priorizadas.
Una vez concluida una se toma la siguiente de la lista.
Se convoca todos los días una reunión del equipo donde se cuenta las tareas realizadas el
día anterior y cuales se van a realizar ese día.

Caso práctico
Una vez finalizado el sprint, el Dueño de Producto le muestra al cliente el resultado del
trabajo realizado.
El cliente ya tiene el primer contacto con su encargo y además puede volver a priorizar la
pila de producto antes de que comience otro sprint.
ClienteDueño de Producto
Buen trabajo

Caso práctico
El equipo de trabajo celebra su buen hacer con una reunión de retrospectiva, donde se
analiza lo ocurrido durante el sprint.

SCRUM 10 Reglas de
oro
“Orcos a las puertas”
ElEquipo
#!/bin/
#!/bin/
#!/bin/
PO

SCRUM 10 Reglas de
oro
IX.“Orcos a las
puertas”
ElEquipo
#!/bin/
#!/bin/
#!/bin/
PO
Stakeholders
aka
Orcos

SCRUM 10 Reglas de
oro
ElEquipo
#!/bin/
#!/bin/
#!/bin/
Eh,eh,colegui!

SCRUM 10 Reglas de
oro
ElEquipo
#!/bin/
#!/bin/
#!/bin/
ScrumMaster

LANZAMIENTO
La fase de lanzamiento con scrum significa que Team scrum hace entrega de un
incremento de producto aprobado por el Product Owner como resultado del sprint
ejecutado por lo cual, todos los integrantes del Team scrum en compañía
del scrum master deben realizar gestión para poner en producción el incremento
de producto en donde la gestión del scrum master es vital para articular las
diferentes áreas que participan en el proceso de puesta en producción. Siendo las
áreas que tienen mayor participación las siguientes:
1) Área de infreaestructura quien se encarga de ejecutar la lista de chequeo para
poner en producción el incremento de producto.
2) Área de soporte quien se encarga de configurar los dispositivos en donde se
podrá acceder al incremento de producto en producción.
3) Área de seguridad de la información quien se encarga de supervisar que el
incremento de producto cumpla las políticas de seguridad de la información para
evitar la fuga de datos.
4) Áreas de negocio quienes harán uso del incremento del producto por lo cual,
deberán validar de manera general que el incremento de producto puesto en
producción se encuentre estable para apoyar la operación del cliente.

LANZAMIENTO
Las actividades más relevantes durante la fase de lanzamiento con scrum son los
siguientes:
1) Articular las diferentes áreas involucradas en el incremento de producto para realizar
un proceso efectivo durante la puesta en producción.
2) Realizar gestión por parte del scrum master para garantizar que el incremento de
producto es puesto en producción con la aprobación de las diferentes áreas de la fábrica
de software y el cliente.
3) Gestionar por parte del scrum master que durante el proceso de puesta en
producción del incremento del producto se de cumplimiento a los lineamientos scrum,
procesos de la fábrica de software y procesos de la organización del cliente.
4) Realizar pruebas generales por parte de los usuarios para garantizar que el incremento
de producto se encuentra estable en producción.
La fase de lanzamiento con scrum busca poner en producción el incremento de producto
con la mayor calidad posible.

• Ventajas de la fase de lanzamiento con scrum
Las ventajas que nos ofrece la fase de lanzamiento
con scrum son las siguientes:
1) Entregar un incremento de producto con calidad al cliente.
2) Aumentar el nivel de satisfacción del cliente y los usuarios.
3) Aumentar el nivel de confianza del cliente y los usuarios.
4) Aumentar la pro-actividad y motivación del Product
Owner y los usuarios.

LANZAMIENTO
Procesos que hacen parte de lanzamiento del proceso con scrum
Lograr ejecutar la fase de lanzamiento con scrum de manera
satisfactoria requiere de la ejecución de los siguientes procesos:
1) Entregar el incremento del producto al cliente como resultado del
sprint ejecutado.
2) Realizar una retrospectiva del proyecto entre
el Team scrum, scrum master, Product Owner y otros interesados para
identificar, documentar e interiorizar las lecciones aprendidas.
3) Refinar el método de trabajo para aumentar la productividad en
próximos proyectos.

RETROSPECTIVA DEL PROYECTO
En este proceso, con el cual termina el proyecto, los interesados de
la organización y los miembros del Equipo Scrum Principal se
reúnen para hacer una Retrospectiva del Proyecto, e identificar,
documentar e internalizar las lecciones aprendidas.
Frecuentemente, estas lecciones conducen a la documentación de
las Mejoras Procesables Acordadas, que se implementarán en
proyectos futuros.
La responsabilidad principal de la Guía de Scrum es asegurar que
las lecciones aprendidas de cada proyecto no se pierdan, sino que
formen parte de la organización. Adicionalmente, la Guía de Scrum
puede proveer pericia en varias áreas, incluyendo Calidad,
Recursos Humanos y Scrum.

Scrum trainer clase 7 y 8

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Scrum trainer clase 7 y 8

Similar a Scrum trainer clase 7 y 8 (20)

Último

Último (20)

Scrum trainer clase 7 y 8