Orígenes de Scrum

20
 NO
Scrum

La idea detrás de Scrum

“The New New Product Development Game“ - Harvard Business Review 1986

Ikujirō Nonaka Hirotaka Takeuchi

21
 NO
Scrum

La palabra Scrum
Analogía del Rugby:
El equipo se auto organiza. La estrategia
es definida fuera del equipo, pero este
define la táctica

22
 NO
Scrum

Los fundadores de Scrum

Ken Schwaber Jeff Sutherland

23
 NO
Scrum

Diagramas de Gantt

15
 NO
Scrum

Aterrizar el proyecto

Un diagrama de Gantt no
sirve para aterrizar un avión.

Para aterrizar en la pista

debemos inspeccionar y
adaptarnos
continuamente.
 Scrum

Burndown Chart del Sprint

Puntos

Propósito: Mostrar el trabajo restante

1 sobre el tiempo (usado por el equipo
para su propia gestión).

Responsabilidad: Equipo de desarrollo

2 (incentivado por el Scrum Master).

El Burndown Chart es actualizado

3 normalmente después de cada reunión
diaria. Días

Junto con los tableros Scrum, los Burndown Charts son

herramientas muy útiles para identificar modelos17
 Scrum

Burndown Chart de lanzamiento (Release)

Puntos

Propósito: Para que el PO gestione el

1 plan de lanzamiento.

2 Responsabilidad: Product Owner.

Frecuencia actualizada: Al final de cada

3 Sprint.
Sprints

18
 Scrum

Burnup Chart de lanzamiento (Release)

Puntos

Sprints

19
 NO
Scrum

Lean, Ágil y Scrum

Lean

La idea de maximizar valor para el

cliente mientras se reduce
Ágil desperdicio.

Mentalidad con valores y principios

Scrum

Marco para manejar tareas

complejas

30
 NO
Scrum

3Ms de lean

Muda Mura Muri

Cualquier actividad que no Desigual, Mura crea Muda Sobrecarga, usualmente
agrega valor causado por Mura

31
 NO
Scrum
El manifiesto ágil 2001
Estamos descubriendo mejores maneras para el desarrollo de software,
haciéndolo y ayudando a otros a que lo hagan. Mediante este trabajo hemos llegado a
valorar:

• Las personas y las interacciones sobre los procesos y herramientas.

• Un software funcional sobre documentación comprensible.
• La colaboración del cliente sobre negociaciones en el contrato.
• Responder al cambio sobre seguir un plan.

Esto es, mientras hay valor en las variables de la derecha, valoramos aún más las de la
izquierda.

32
 NO
Scrum

Los 12 principios ágiles

1. Nuestra mayor prioridad es satisfacer al cliente 6. El método más eficiente y efectivo de comunicar información
mediante la entrega temprana y continua de al equipo de desarrollo y entre sus miembros es la
software con valor. conversación cara a cara.
2. Aceptamos que los requisitos cambien, incluso en 7. El software funcionando es la medida principal de progreso.
etapas tardías del desarrollo. Los procesos Ágiles 8. Los procesos Ágiles promueven el desarrollo sostenible. Los
aprovechan el cambio para proporcionar ventaja promotores, desarrolladores y usuarios debemos ser
competitiva al cliente. capaces de mantener un ritmo constante de forma
3. Entregamos software funcional frecuentemente, indefinida.
entre dos semanas y dos meses, con preferencia al 9. La atención continua a la excelencia técnica y al buen diseño
periodo de tiempo más corto posible. mejora la Agilidad.
4. Los responsables de negocio y los desarrolladores 10.La simplicidad, o el arte de maximizar la cantidad de trabajo
trabajamos juntos de forma cotidiana durante no realizado, es esencial.
todo el proyecto. 11.Las mejores arquitecturas, requisitos y diseños emergen de
5. Los proyectos se desarrollan en torno a individuos equipos auto-organizados.
motivados. Hay que darles el entorno y el apoyo 12.A intervalos regulares el equipo reflexiona sobre cómo ser
que necesitan, y confiarles la ejecución del trabajo. más efectivo para a continuación ajustar y perfeccionar su
comportamiento en consecuencia.

33
 NO
Scrum
El concepto Shu Ha Ri para agil

Shu Ha Ri
Aprende la regla (sin Iniciar a ”romper la regla”, a Ser la regla, ser un maestro y
modificación) ver que funciona define la regla

36
 NO
Scrum

Standish Group – Chaos Report

Exitosos: En tiempo,
costo y alcance
Falla: Proyectos
cancelados

18%
39%

Parcialmente exitosos:
• Sobrecostos y/ o
• Sobretiempo y / o
• Alcance no alcanzado
completamente
43%
Fuente: Standish Group – Chaos Report 2012 10
 NO
Scrum

2/3 de la funcionalidad no son utilizados

frecuentemente
Solamente 1/5 es
utilizado
Siempre frecuentemente
7%

Frecuentemente
13%
Nunca
45%
Algunas veces
16%

2/3 de la
funcionalidad no
son usados nunca Casi Nunca
o casi nunca 19%

Fuente: Standish Group – Chaos Report 2002 11

 NO
Scrum

Los requerimientos cambian en un año

36%
Fuente: Schwaber and Sutherland 2012 12
 NO
Scrum

Cambiar la perspectiva
Tradicional Ágil

Fijo Alcance Costo Tiempo

Valor en
marcha

Plan en

Opelt A. et al; Agile Contracts 2013

marcha
Estimado
Costo Tiempo Alcance

13
 NO
Scrum
El proyecto debe entregar productos con
valor económico agregado

14
Es un proceso empírico y
definido

38
 NO
Scrum

Modelo de control de proceso definido (complicado)

39
 NO
Scrum

El marco Cynefin

Actuar, Percibir, Probar, Percibir,

Responder Responder

Caótico Complejo

Disorder

Percibir, Categorizar, Percibir, Analizar,

Responder Responder

Sencillo Complicado

Fuente: Snowden & Boone, 2007 40

 Scrum

Scrum es basado en control de proceso empírico

Inspección
Adaptación de Proceso
Inspección y
Retroalimentación
Adaptación

Input Output
Input Scrum Output
Inicial Final

Adaptación Inspección y
Retroalimentación
Adaptación Inspección
de
Producto

Fuente: The Essential Scrum 2013 41

El Sprint es iterativo e
incremental

44
 Scrum

Iterativo vs Incremental

Iterativo Incremental

Fuente: http://scrumandkanban.co.uk/incremental-or-iterative/ 45
 Scrum

Scrum es ambos: iterativo e incremental

1.Programar la página web. Esto
incluye: Métodos de pago,
búsqueda, crear cuentas y carrito de
compras
Iterativo 1.Varios métodos de pago, búsqueda
por filtros, un perfil más completo,
un carrito de compras más funcional.

2.[…]

Proyecto: Programar Scrum y cada

una tienda en línea Sprint

1.Programar un catálogo
completamente funcional
Incrementa
1.Crear una búsqueda filtrada
l completamente funcional

2.[…]

46
El Sprint está protegido

47
 Scrum

El Sprint está protegido

• Durante la administración del Sprint, el equipo planea y se compromete a un objetivo para
el Sprint.
• Para que el equipo pueda cumplir con su compromiso el Sprint necesita ser “bloqueado” o
protegido:

• No se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint Goal);
• Los objetivos de calidad no disminuyen; y,
• El alcance puede ser clarificado y renegociado entre el Product Owner y el Equipo de
Desarrollo a medida que se va aprendiendo más.

• ¿Qué pasa si el Sprint no está protegido y el equipo no logra enfocarse?

• ¿Quién puede dar por terminado el Sprint?

48
Timeboxing

49
 Scrum

El Sprint es Timeboxed

Actividad #
Plan del Sprint 1 Actividad # 2 Actividad # 3 Buffer
1

Sprint real I Actividad # 1 Actividad # 2 Actividad # 3

Activid Actividad #
Plan del Sprint 2 ad # 3 Actividad # 5 Buffer
4

50
 NO
Scrum
Duración del Sprint
Duración promedio del Sprint de acuerdo con el reporte Sate de Scrum de 2015: 2.4
semanas

60%

2 semanas

5%
7%
1 semana 29%

Otros 3-4 semanas

51
Definición de “Termiando”

52
 Scrum

Sólo lo que está completamente terminado

agrega valor
¿Le gustaría comprar este auto?

•Depósito •Entregar algo que el cliente no

puede usar es como no haber
•Trabajo en progreso entregado nada.
•Es mejor hacer algo más pequeño
•Terminado pero no entregado pero terminarlo.

53
 Scrum

Sólo lo que está completamente terminado

agrega valor

¿Terminado? ¿Terminado? ¿Terminado? ¿Terminado ¿Terminado? ¿Terminado?

No! No! No! No! No!
Tarea
Si!
Planeación Redacción Aclarar Ejecución Pruebas Ajustar
Historia

Incremento
potencialmente
entregable

Definición
mínima de
“Termiando”
54
Valores de Scrum

55
 Scrum

Los 5 valores de Scrum

C R
§ Todos los equipos deben que encontrar
los 5 valores escondidos en el salón A
F
Time Box: 5 min
C
56
Visión general

65
 Scrum

El equipo Scrum

Product Scrum
Equipo
Owner Master

• Estructurado
• Definir y priorizar los • Facilita el proceso de Scrum y la horizontalmente y multi
elementos del Product Backlog. organización del equipo. funcional
• Tomar decisiones acerca de los • Elimina amenaza y facilita el • Auto organizado, auto
contenidos y fecha de intercambio de información gestionado. Autonomía
lanzamiento del producto. • Responsable de la efectividad completa para alcanzar
• Responsable de la rentabilidad del equipo. metas.
de los productos (ROI) • Normalmente entre 3 a 9
miembros
66
Product Owner

67
 NO
Scrum

The Product Owner

Autoridad
Autoridad para decidir sobre lo QUE
hay que hacer.

Conocimiento Disponibilidad
Conocimiento del producto y de las
Debe que estar disponible para
necesidades del cliente,
clarificar cualquier duda al equipo y
para entender las necesidades del
cliente.

68
 Scrum

Responsabilidades del Product Owner

1 Encamina el éxito del producto 4 Colabora con el equipo

2 Crea la visión del producto 5 Colabora con los Stakeholders

3 Crea y mantiene el Product Backlog 6 Participa en las reuniones del Sprint

69
 Scrum

El Product Owner es dueño de QUÉ

Tener una visión atractiva

del producto que se pueda
ejecutar.

Pasar la otra mitad Construir un mapa para

trabajando de cerca desarrollar su visión.
con el equipo

Pasar la mitad de su Construir el Product Backlog

tiempo con el cliente

70
 NO
Scrum
La autoridad del PO sobre el Backlog

Claramente Valor Visible y

Ordenada Entendida
expresada optimizado transpoarente

Expresar claramente los Ordenar los puntos del Optimizar el valor del Asegurarse de que el Asegurar que el equipo de
puntos del Backlog Product Backlog para trabajo que desempeña Product Backlog sea desarrollo entienda los
alcanzar las metas y las el equipo de desarrollo visible, transparente y puntos del Product
misiones de una mejor del producto. claro para todos, y Backlog al nivel necesario.
manera. mostrar el siguiente
trabajo del equipo Scrum.

71
Scrum Master

73
 Scrum

Responsabilidades del Scrum Master

1 Actuar como un agente de cambio 4 Entrena al P.O y al equipo

2 Sirve al Product Owner y al equipo 5 Protege al equipo

3 Remueve los impedimentos 6 Guía al equipo

74
 Scrum

El Scrum Master es dueño del proceso

Facilita el Scrum diario

Remueve los Facilita la planeación

impedimentos del Sprint

Protege el equipo Facilita la retrospectiva

 NO
Scrum

Liderazgo sin autoridad (credibilidad)

Ser confiable
Ejemplo
… hacer lo que dice, Sea un ejemplo para el
para que las personas comportamiento de los

Competencias
puedan confiar en usted demás
Confianza

Valorar a las Conocimien

personas to
…Muestre respeto Amplio
y apreciación por conocimiento
los demás del proceso
Scrum

Valorar el trabajo del

equipo Experiencia
Muestre respeto y …Regirse por los valores
apreciación por el trabajo y prácticas de Scrum da
realizado credibilidad
Fuente: Linda Hill and Kent Lineback: Being the Boss : Harvard Business Review Press, 2011;
Stephen Covey and Rebecca Merrill:The Speed of Trust : Simon & Schuster, 2006
El equipo

79
 Scrum

Responsabilidades del equipo

Participa en las reuniones del Sprint

Auto organizarse y responsabilizarse
1 como equipo 4 (Planeación, Revisión, Diaria y
Retrospectiva)

2 Entregar un incremento del producto

Autoridad

• El equipo tiene poder para tomar cualquier

decisión requerida para alcanzar el éxito.

• El equipo tiene poder para solicitar cualquier

Administra el Sprint Backlog y rastrea el
3 progreso del Sprint
recurso que necesite (incluyendo
entrenamiento adicional)

80
 Scrum

Trabajo en equipo

Multi funcional

3-9 personas Auto organizado (cómo)

Colaborativo Auto administrado (cuánto)

81
Product Backlog

86
 Scrum

Product Backlog
• Única fuente de requerimientos
• El backlog consiste de elementos del Product
• Contiene todo lo necesario para cumplir con la Backlog (PBI) Product Backlog Items

visión del producto

• Los PBI son ordenados por valor de negocio
• Lista ordenada de características, funciones,
requerimientos, mejoras, y arreglos • Los PBI son evaluados verticalmente
• Nunca está completo • El Product Owner es la autoridad final en el
orden del Backlog
• Constante cambio para identificar las
necesidades del producto - Dinámico • La mayoría de los equipos Scrum utilizan
historias de usuario como PBI.
• Re priorizado frecuentemente
• Es emergente o elabora progresivamente
87
 Scrum

Refinamiento del Product Backlog

• El refinamiento del Product Backlog puede tomar hasta 10% del tiempo del Sprint
• Participantes: El equipo Scrum
88
Historias de Usuario

89
 NO
Scrum

Historias del usuario

• Una historia del usuario es un requerimiento del • No es una descripción detallada
producto
• Usar una nota pequeña para mejorar el espacio
• Una historia del usuario tiene un valor agregado
visible para el cliente.

• Cuando se implementa una historia de usuario, se

Me gustaría crear un
desarrolla una nueva característica que el cliente perfil Me gustaría tener una
puede usar batería que dure 2 días
en mi teléfono
• Esto no es una historia del usuario: “La aplicación
debió ser programada en Java”
Me gustaría tener un
Numpad en mi portátil
• Esto es una historia del usuario: “La aplicación
debería permitirme ver los datos” Los pisos de mi
apartamento deberían
ser fáciles de limpiar

90
 NO
Scrum

Historias del usuario

Como <Rol> quiero <acción> [para que <valor de negocio>]

Como miembro de LifeMiles me gustaría recibir información con cupones y descuentos en puntos de viajero frecuente
[para comprar los puntos necesarios para viajar]

91
 NO
Scrum

Historias del usuario – una nota no es suficiente

Conversación Criterios de aceptación

• Cuando una nota es escogida para • En Scrum sólo los productos terminados tiene
implementar durante el Sprint, debe ser valor, por está razón los criterios de aceptación
discutida. deben ser desarrollados por el evaluador.

• El Product Owner debe resolver las preguntas • El equipo y el Product Owner desarrollan los
del equipo de desarrollo criterios de aceptación juntos

• Todas las preguntas deben ser escritas en • Los criterios de aceptación son muy
notas importantes para el desarrollador y también
para la evaluación del producto.

• Los criterios de aceptación pueden cambiar

92
 Scrum

Definición de terminado vs Criterios de

aceptación
Definición de terminado Criterios de aceptación

Lista de chequeo Condición de satisfacción

Cada historia de usuario debe Es individual para cada
que cumplir estos condiciones historia de usuario

Ejemplo Ejemplo
• Desarrollado Compra con tarjeta de
• Probado crédito funciona con:
• Cumple criterios de • Visa
aceptación • Master Card
• Integrado • American Express
• Documentado

93
 NO
Scrum
Puntos de la historia
Estimar basado en:
– Esfuerzo
– Riesgo
– Complejidad
– Incertidumbre

Sin Unidad
Medidas relativas: Usar escala de orden
Historia 1: es más difícil aproximada de magnitud
comparada con la 2 (1, 2, 3, 5, 8,1 3, 21 …)

98
 NO
Scrum

Como estimar

Historia de Estimado Resultado

referencia

• Elegir la historia más pequeña • Estimar el tamaño relativo de las • Discutir los
demás historias resultados y votar
independientemente, luego nuevamente, hasta
compartirlas como equipo que todos los
• Ej. Planning Poker © (Mountain números estén
Goat) dentro de 3 cartas,
luego promediar.
102
Estimación

95
 NO
Scrum
Estimar la carrera

Estimar tiempo Estimar tamaño

• John: Vamos a necesitar 30 min • John: Son 10 km
• Diego: Vamos a necesitar 60 min • Diego: Son 10 km

96
“Las horas no escalan”

97
 NO
Scrum

Porque puntos de historia?

Medición universal Tamaño no tiempo
1 Los puntos son una medida universal 4 La estimación es una forma de decir el
en todo el equipo. No está sesgado por tamaño de una historia, no cuánto tiempo
la experiencia o habilidades o cualquier se tarda en implementarla.
individuo en el equipo.
Puntos son constantes
Estado estable
5 Días de hombre ideal es un tamaño
2 Después del 3 o 4 sprint, el equipo llega a
que varía con el tiempo dependiendo
un estado estable y se hace más fácil para
del rendimiento del equipo. Los
el product owner de llenar el backlog con
puntos de historia son relativamente
los historias de puntos de estado estable.
constantes.
Nada más y nada menos.
Estimaciones relativas son mas exactos
En la zona 6 Está probado que la estimación
relativa es más correcta que
3 Una vez que el equipo alcanza el estado
absoluta.
estable los ejecutivos creen en el equipo
técnico y esto pone al equipo en la zona
de alta motivación y confianza.
Fuente: Jack Milunsky Fuente:: Tomas Björkholm
 NO
Scrum

Cono de incertidumbre
Puntos de historia
+ 400%
Horas

- 100%

Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan (2012) Scrum + Engineering Practices: Experiences of Three
Microsoft Teams. IEEE Best Industry Paper Award, 2011 International Symposium on Empirical Software Engineering and
Measurement.

100
 NO
Scrum

Exactitud vs Esfuerzo
Exactitud

Esfuerzo

Fuente: Agile Estimating & Planning by Mike Cohn

101
Sprint Backlog

104
 Scrum

Sprint Backlog
Product Backlog

Product Backlog Items

Desglosar las historias en tareas

105
Incremento del producto

106
 Scrum

Incremento de producto
• Al final de cada Sprint, el equipo Scrum es responsable de presentar un incremento
de producto potencialmente entregable

• El Incremento es la suma de todos los elementos de la Lista de Producto completados

durante un Sprint y el valor de los incrementos de todos los Sprints anteriores.

• Tiene que cumplir la definición de terminado del Eqiupo

• Aceptado por el Product Owner

107
Planeación del Sprint

109
 Scrum

Planeación del Sprint

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto?

• El equipo de desarrollo • Al inicio de cada Sprint • Product Backlog • ¿Qué? Meta del Sprint
• El Product Owner • Duración: 8 horas para • El último incremento del • ¿Cómo? Sprint Backlog
• El Scrum Master un Sprint de 1 mes producto
• Capacidad proyectada del
• Otros pueden ser
equipo de desarrollo
invitados durante el Sprint
• Desempeño anterior del
equipo de desarrollo
110
 Scrum

Planeación del Sprint

• Tema 1 (Qué): Seleccionar los puntos del PB que • Capacidad, es cuánto tiempo tiene disponible el
serán completados en el Sprint (la meta) equipo de desarrollo para trabajar durante el
Sprint.
• Tema 2: (Cómo): Desglosar los puntos del PB.
• El Product Owner define prioridades, contesta • Considerar el tiempo requerido para reuniones,
preguntas Definición de Terminado y establece la tiempo libre para alguno de los miembros del
meta del Sprint basado en la velocidad histórica. equipo, etc.

• El equipo de desarrollo desglosa los puntos del PB • Velocidad, es la cantidad de trabajo que el
en tareas, asegurando que estas se pueden equipo de desarrollo ha sido capaz de producir
terminar en un día ideal (o menos). históricamente basado en datos reales.

• El Scrum Master facilita y asegura que el marco de

referencia Scrum sea seguido.
• Es importante que la duración el Sprint se
mantenga consistente para que el equipo de
desarrollo pueda establecer una cadencia y así
mismo establecer una velocidad.
Scrum Diario

112
 Scrum

Scrum Diario

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto tiempo?

• El equipo de desarrollo • A la misma hora todos Cada miembro del equipo • Un entendimiento
• El Scrum Master (no es los días, es definida por responde lo siguiente: común del trabajo más
obligatorio) el equipo • ¿Qué hice ayer? importante para avanzar
• Duración: Máximo 15 • ¿Qué haré hoy? hacia la meta.
minutos • ¿Veo algún • Un Backlog actualizado
impedimento? de los impedimentos.

113
 Caso

James Coplien – Saturación de comunicación

120

% de saturación de comunicación
100 52 veces mas rápido

80
Saturación de comunicación
60 Bell Labs Pasteur Project
82 empresas
40

20
Como resultado quitaron todos los
títulos. 0
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80

52x
Mas rápido
Número de roles

114
 Merger: Delta Airlines – North West Airlines

115
Caso
 NO
Scrum
El tablero Scrum es sencillo
Do
Hacer Haciendo Terminado

Historia 1

Historia 2

Historia 3

• El Sprint Backlog debe mostrar todo el tiempo qué puntos están siendo trabajados y por quién
• El Sprint Backlog es actualizado por lo menos una vez al día
116
 NO
Scrum
El tablero Scrum puede incluir columnas
adicionales
Do
Hacer En espera Haciendo Terminado

Historia 1

Historia 2

Historia 3

117
 NO
Scrum
Un Buffer para tareas impredecibles puede
ser incluido
Do
Hacer Haciendo Terminado

Buffer

Historia 1

Historia 2

118
 NO
Scrum
Señales de alarma
Puntos

Do
Hacer Haciendo Terminado

Buffer
10

Historia
1

Dias

Story 2

119
 NO
Scrum
Señales de alarma (2)
Puntos

Do
Hacer Haciendo Terminado

Buffer
2

Historia
1

Dias

Historia
2

120
 NO
Scrum
Señales de alarma (3)
Puntos

Do
Hacer Haciendo Terminado

Buffer
10

Historia
1

Dias

Historia
2

121
 NO
Scrum
Multitareas resulta en tiempo de administración
pobre

Sin Multitareas Prep

Prep

Prep
Tarea A Tarea B Tarea C Pérdida de tiempo
debido al mal
trabajo en
multitareas

Con Multitareas Tarea Tarea Tare Tare Tarea Tare Tarea Tare Tare
Prep

Prep

Prep

Prep

Prep

Prep

Prep

Prep

Prep

Prep
Tarea B
A A aC aA B aC B aC aB

123
 NO
Scrum

Multitareas tiene un impacto negativo en el desempeño

Multitasking can hurt social skills Multitasking Hurts Your Academic Performance
1 Stanford University 4 University of Vermont

Multitasking puts your brain on overload Multitasking Makes You Interrupt Yourself More
2 University of California, San Francisco and California
State University
5 University of California

Emails and Texts Hinder Multitasking lowers your IQ, similar to

3 High-Level Thinking 6 smoke marijuana or stay up all night.
Microsoft IQ drops to that of an 8-year-old child
University of London

124
 NO
Scrum

Multitareas entre proyectos

Proyectos simultáneos Disponibilidad por proyecto Deficiencias causadas por cambio de contexto

1 100% 0%

2 40% 20%

3 20% 40%

4 10% 60%

5 5% 75%

Fuente: Gerald Weinberg: Quality Software Management

125
Revisión del Sprint

126
 Scrum

Revisión del Sprint

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto?

• El equipo de desarrollo • Al final de cada Sprint • Incremento • Incremento del

• El Product Owner • Duración: 4 horas para • Product Backlog producto para potencial
• El Scrum Master un Sprint de 1 mes envío
• Stakeholders • Velocidad (¿Qué está
terminado?)
• Retroalimentación
(actualización del
Product Backlog)
127
 Scrum

Revisión del Sprint

• El equipo demuestra un código de trabajo a los stakeholders
• Sólo se muestran las historias 100% completadas
• Las historias parcialmente completadas son ignoradas
• El Product Owner confirma que está “Terminado”
• Retroalimentación directa de los stakeholders
• La retroalimentación se incorpora en el Product Backlog

128
Retrospectiva del Sprint

129
 Scrum

Retrospectiva del Sprint

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto?

• El equipo de desarrollo • Después de la revisión • Información de los • ¿Qué salió bien?

• El Product Owner del Sprint equipos acerca del • Mejoras potenciales
• El Scrum Master • Duración: 3 horas para último Sprint • Plan de mejoras
un Sprint de 1 mes

130
 NO
Scrum
Retrospectiva del Sprint – Muchas opciones

131
 NO
Scrum

Sprint Retrospective
• Preparar el escenario
• Coleccionar data
• Generar aprendizaje
• Determinar que hacer
• Cerrar Retrospectiva

Fuente: Esther Derby

132
 NO
Scrum

Retrospectiva del Sprint (Una opción)

Preparar el escenario Coleccionar data (Línea de tiempo)
• Saluda a los participantes y revisar agenda y • Crear una línea del tiempo donde las personas
meta de la reunión puedan ingresar sus notas
• Breve pregunta (en uno o dos palabras que • Divide equipo en grupos pequeños
esperas de esta reunión? • Pedir a los miembros del equipo que recuerden
• Escucha las respuestas todos los eventos: memorables, significativos a
Source: Esther Derby nivel personal, o profesional y que los escriban
• Cuando todos los post-its estan en la pared
invita al equipo a revisar la línea de tiempo

First story
ready for
Sam sick
test
Story #25
removed
from sprint
New desks Sprint
installed Big LAN Team flow! demo
argument shootout

Semana 1 Semana 2 Semana 3 Source: Henrik Kniberg

133
 NO
Scrum

Retrospectiva del Sprint (Una opción)

Generar aprendizaje (5 Porques) Determinar que hacer (objetivos SMART)
• Revisar lo que han identificado • Define objetivos SMART para los top 3
• Divide el equipo en grupos pequeños (no
preguntado al otro porque hasta se identifica Cerrar Retrospectiva (+/Delta)
la causa raíz • El equipo identificar las fortalezas (que
debemos que hacer mas) para la siguiente
Generar aprendizaje( Priorizar con puntos) retrospectiva
• Luego, permitir que los miembros voten
mediante el uso de magnetos

• Identificar las 3 más votadas e identificar la

mejor manera de hacer mejoras

Source: Henrik Kniberg

134
 NO
Scrum
Retrospectiva del Sprint

Velocidad

1 2 3 4 5 6 7 8 9 10
Sprint
Velocidad efectiva Velocidad efectiva sobre tiempo
sobre tiempo (con retrospectivas)
(sin retrospectivas)
Fuente: Henrik Kniberg
135
Product Backlog Refinement

136
 Scrum

Product Backlog Refinement

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto?

• El equipo de desarrollo • Cuando sea necesario • Visión del producto • Product Backlog
• El Product Owner (proceso continuo) • Product Backlog refinado
• Duración: Regla del • Velocidad
pulgar: Máximo 10% del
tiempo del Sprint

137
Plan de lanzamiento (Release)

138
 NO
Scrum
Plan de lanzamiento (Release)

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto?

• El equipo de desarrollo • Cuando sea necesario • Visión del producto • Plan de lanzamiento
• El Product Owner (revisar al final de cada • Product Backlog
• El Scrum Master Sprint) • Meta de lanzamiento
• Stakeholders • Duración: no regla • Velocidad

139
 NO
Scrum
Plan de lanzamiento (Release)
Basado en el tiempo
Basado en alcance
Refinar (discutir, ordenar,
cortar) ítems obligatorios
Refin
Refinar (discutir, ordenar, ar
en el product backlog
tamaño) puntos
obligatorios en el product
Refinar ordenado

backlog ordenado

históri Definir velocidad

co histórica

Progreso del gráfico

Gráfico contra los puntos Calcular velocidad media
obligatorios media
.

Pronosticar conjunto de
Pronós
funcionalidades basado
Predecir cuando estarán Pronós tico
en una confianza del 90%
listos tico

140
 NO
Scrum
Plan de lanzamiento (Release) – alcance fijo
Points Cuando eso esta
terminado?

Mitad de marzo

Sprints

141
 NO
Scrum
Plan de lanzamiento (Release) – fecha fija
Points

Algo de esto
Que vamos a tener
listo 1ero de febrero
Todo esto

Sprints

142
Aplicabilidad de Scrum

57
 NO
Scrum
Entorno ideal para Scrum
§ Promover valores y principios ágiles

§ Los gerentes eliminan activamente impedimentos organizacionales

§ Alineación de grupos internos

§ Alineación de proveedores

58
Evidencia empírica

59
 Caso

Scrum es utilizado en diferentes industrias

60
 Caso

Salesforce.com
Mas releases a producción
4X

94% 38% 61% 89%

Aumento en Aumento en Reducción en tiempo de De desarrolladores que

funcionalidades entregadas productividad/ingeniero ciclo de lanzamiento están contento en el trabajo

61
 Caso
El tiempo de Satisfacción de clientes
lanzamiento disminuyó aumento
de 1 año a 102 días

72% 6%
Scrum en una compañía de
telecomunicaciones en China

• Unidad de negocio red fijo +500 empleados

• Implementación con piloto (3 equipos)
• Sprint de una semana
• Releases de 4 semanas
• Todos los jueves sesión de coaching 73% 12%
• LeSS para escalar
• Roll Out para 42 equipos

Fuente: https://www.agilealliance.org/resources/experience-
reports/dragon-dance-large-scale-agile-transformation-in- El tiempo promedio de Eficiencia promedia de
traditional-telecommunication-company/ entrega disminuyó de 30 I&D aumento
a 8 días
 Caso

Multi-Mission Bus Demonstrator

Sistema complejo usando ágil
• Organización plana
• Equipos en un sitio
• Método de prueba incremental
• Prototyping

Costo 3% (de tradicional US$ 10M)

Tiempo 14% (de tradicional 14 meses)

Fuente: Carlson & Tuner: Review of Agile Case Studies for

Applicability to Aircraft Systems Integration 2013
 Caso

Scrum en un departamento de mercadeo

• Sprint de 3 semanas
• Iniciar con sesión de planeación (incluyendo
estimación)
• Termina con demo
• Retrospectiva
• Scrum diario
• Usan historias de usuario
• Excepción: el equipo entero funciona
como Product Owner

30% mas rápido

Fuente: https://www.agilealliance.org/resources/experience-
reports/marketing-scrum-vs-scrum-two-marketing-case-studies- 30% mas eficaz
now-act-first-apologize-later/
 NO
Scrum

70% de los usuarios de Scrum pertenecen

a una industria diferente a TI

Fuetn:e State of Scrum 2015

63