Líder servicial Líder delegador Autocrático Líder directivo

• Escuchar • Participan en la • Toman decisiones Instruyen a los

cuidadosamente mayoría de la por su cuenta miembros del equipo
• Comprometerse toma de • No da tiempo a sobre las tareas que
al servicio decisiones los miembros del se requieren y sobre
• Compartir el • Está en sintonía equipo para tomar cómo y cuándo
poder y la con el proyecto y decisiones deben llevarse a
autoridad cuando el tiempo cabo
Estilos de es limitado

Liderazgo
Líder Laissez Líder de apoyo y Líder enfocado Líder asertivo
Faire entrenamiento en las tareas
• El equipo se • Dan instrucciones • Se enfocan en las
queda sin • Apoyan y tareas • Confrontan los
supervisión monitorean al • Que se hagan las problemas
• Líder no interfiere equipo tareas con apego • Muestran
con las • Da una a los plazos confianza
actividades perspectiva en • Establecen
diarias tiempos de autoridad con
incertidumbre respeto

1) Escuchar

2) Empatía

3) Recuperación

4) Toma de conciencia

Liderazgo 5) Persuasión

Servicial 6) Conceptualización

7) Prospectiva

8) Administración

9) Compromiso con el crecimiento de los demás

10)Desarrollo de una comunidad

45
 DINÁMICA
Donut

Scrum Master Nadie

5 Facilitar reuniones 3 Señalar los errores de alguien
10 Proteger el equipo de interferencias extremas 11 Ser manager del equipo
16 Actuar como coach de proceso con los demás 22 Asignar tareas a los demás
20 Resolver impedimentos ligados a la organización 28 Crear informes de situación
24 Ayudar al equipo para que se auto-organice 37 Valorar el rendimiento de los
30 Comprobar que se sigue el proceso miembros del equipo
33 Mejorar el grado de madurez agile del equipo
38 Asegurarse que los artefactos del proyecto están al
día.
7 Motivar al equipo 12 Seguir el progreso
durante una iteración

Donut
Product Owner
1 Ajustar el alcance
9 Anular una iteración
15 Construir el backlog del
producto
19 Priorizar el backlog
23 Transmitir la visión del producto
25 Recopilar las necesidades de
los stakeholders
31 Aceptar o no un ítem cómo
“done”al dinal de un sprint
35 Tener a los stakeholders
informados
39 Ser el representante del negocio
/ de los clientes
Todos
2 Asegurarse que algo útil se
está desarrollando
8 Asegurar la calidad
18 Decidir cómo invertir sus
recursos (p.ej. Tiempo)
27 Aprender de forma continua Equipo de desarrollo
32 Mejorar de forma continua 4 Pedir información acerca del
34 Abordar los riesgos pronto dominio / negocio para entender
mejor el trabajo a realizar
14 Estimar el esfuerzo
17 Comprometerse a que cierto
trabajo este hecho durante una
iteración
21 Diseñar, programar, testar,
integrar, desplegar
6 Escribir ítems del backlog
26 Resolver impedimentos propios
13 Hablar de los product
del equipo
backlog ítems
36 Poner en marcha prácticas de
29 Hablar con
ingeniería ágiles
Stakeholders expertos

46
Proceso

Reunión
Refinamiento diaria

Calendario del Plan

de Liberación

Crear Revisión de
Entregables Retrospectiva
Reunión de
planeación

Enunciado de la Pila del Pila del Sprint Reunión de Entregables

Caso de Negocio
Visión del Producto Revisión Aceptados
del Proyecto
Proyecto Priorizado

47
 REVISIÓN Y
PLANEAR Y
INICIO IMPLEMENTAR RETROSPECTIV LIBERACIÓN
ESTIMAR
A

Crear Visión del Crear historias de Demostrar y validar

Crear entregables Enviar entregables
poyecto usuarios el sprint

Identificar Scrum Retrospectiva del

Fases Master y
Estimar historias de
usuarios
Realizar Daily
StandUp
sprint
Retrospectiva del
proyecto
Stakeholder(s)

Refinar el Backlog
Formar Equipo Comprometer
Priorizado del
Scrum (Dev) historias de usuario
Producto

Desarrollar Épicas Identificar tareas

Crear el Backlog
Priorizado del Estimar tareas
Producto

Realizar la Crear el Sprint

planificación de Backlog
lanzamiento

INICIO

Crear Visión del

poyecto

Identificar Scrum
Fase Master y
Stakeholder(s)
Inicio
Formar Equipos
Scrum (Dev)

Desarrollar Épicas

Crear el Backlog
Priorizado del
Producto

Realizar la
planificación de
lanzamiento

48
Crear Visión
del Proyecto
• Se define el Product Owner

• Se debe enfocar en el problema más que en la solución

Fase • Ceremonia de la visión del proyecto (Project Vision Meeting)

Inicio • Se requiere:
• Caso de negocio
• Visión de la compañía

• El PO lleva a cabo un análisis FODA y análisis FIT & GAP para

entender mejor el proyecto

• Se genera el enunciado de la Visión del proyecto que explica las

necesidades del negocio que el proyecto trata de cumplir

Crear el Backlog
Priorizado
del producto Es el conjunto de reglas que son aplicables a
todas las historias de usuario.

Fase
Inicio
Ayuda al equipo a agregar normas de calidad obligatorias.

El PO acepta o rechaza los entregables del Sprint

en el proceso “Revisar y validar el Sprint” con base al
criterio de terminado y a los criterios de aceptación
de la historia de usuario.

49
 Llevar el plan de la liberación

● Establece qué entregables serán liberados al cliente, a través de intervalos

Fase planeados y fechas de liberación
Inicio
● El equipo Scrum define la longitud del Sprint para el proyecto (se
recomienda que sean 2 a 6 semanas), sin embargo al implementarse a un
nivel corporativo, deben ser 2 semanas, para lograr una buena coordinación
entre los múltiples equipos.

● La planeación de las liberaciones debe ser de tal manera que asegure que
cada liberación entrega un valor significativo al cliente

● Debe considerar las interdependencias entre características u otras

precondiciones

Llevar el plan de la liberación

● Sesiones del plan de liberaciones

 El plan define cuando varios conjuntos de funcionalidad usable o

Fase
productos deben ser entregados al cliente
Inicio
 El plan puede estar orientado por funcionalidad o por una fecha
determinada

 El plan puede ser actualizado constantemente, no debe ser detallado

 Se obtiene:

 Plan de liberaciones

 Longitud del sprint

50
 Llevar el plan de la liberación

Fase
Inicio

PLANEAR Y
ESTIMAR

Crear historias de
usuarios

Fase Estimar historias de

usuarios

Planear y
Comprometer
Estimar historias de usuario

Identificar tareas

Estimar tareas

Crear el Sprint
Backlog

51
Crear Historias de
Usuario
En ocasiones los requisitos del cliente son complejos
de entender para el PO, y clasificarlos pudiera ser de
gran ayuda para poder realizar una buena HU.
Fase
Planear y Una historia de usuario es un enunciado (o un grupo de
Estimar enunciados) que expresa una funcionalidad para el
usuario final deseado. Por lo general, se divide en un
bloque secuencial de tareas.

Crear Historias de
Usuario

Titulo #
Descripción
Fase COMO <Rol>
Planear y QUIERO <Funcionalidad>
Estimar PARA <Razón>

Pruebas
Acciones que se debe hacer para
comprobar la funcionalidad

52
Crear Historias de
Usuario
I •Independiente

N •Negociable
Fase
Planear y V •Valuable
Estimar
E •Estimable

S •Small (Pequeño)

T •Testable (Demostrable)

Crear Historias de
Usuario Personas

Fase  Son características ficticias altamente detalladas que

representa a la mayoría de los usuarios, y otros interesados
Planear y que podrían no utilizar directamente el producto.
Estimar
 Ayudan a entender mejor a los usuarios, sus
requerimientos y metas.

 Se puede asignar un nombre ficticio y una Imagen.

53
Crear Historias de
Usuario
Historias de Ayudan a mejorar la comunicación entre el Scrum team y los
usuario interesados.

Definen: ¿Quién?, ¿Qué? y ¿Por que?

Fase
Planear y
Estimar
Remueven la necesidad de documentación detallada de los
requerimientos del cliente

Criterios de
aceptación Dan objetividad para considerar si está o no realizada la HU en la
revisión del Sprint.

Criterios de
Aceptación Criterios de Aceptación

• Una funcionalidad se considera “hecha” si es potencialmente

entregable y cumple con los criterios de prueba de aceptación.
Fase
• Ayuda a clarificar los requerimientos y ayuda al equipo a agregar
Planear y normas de calidad
Estimar
• Los criterios de aceptación definidos claramente son cruciales para
la entrega oportuna y eficaz de las historias de los usuario

• Son escritos y definidos por el Product Owner y comunicados al

Scrum team

• Describen explícitamente las condiciones que las historias

de usuario deben satisfacer

54
Criterios de
Aceptación Criterio de terminado
(DoD)

Son una serie de reglas aplicables a todas las historias de usuario

Fase en un determinado sprint
Planear y
Estimar
Ayuda al equipo a agregar normas de calidad obligatorias.

El PO acepta o rechaza los entregables del Sprint en el

proceso “Revisar y validar el Sprint” con base al criterio de
terminado y a los criterios de aceptación de la historia de
usuario.

Criterios de
Aceptación Criterios de Aceptación vs
Criterio de terminado (DoD).
 El criterio de aceptación es único para historias de
usuario individuales.
Fase
 El Done Criteria es el conjunto de reglas que son aplicables
Planear y a todas las historias de usuario.
Estimar
 Revisión por parte de otros miembros del equipo
 Completar las pruebas de unidad de las historias de usuario
 Completar las pruebas de aseguramiento de calidad
 Completar toda la documentación relacionada con la historia
de usuario
 Éxito en la demostración de todos los
interesados/representantes del negocio

55
Aprobar, Estimar y
comprometerse a
Historias de Usuario

Estima y se
compromete

Fase • ¿Aborda los

Scrum team • El Scrum team se
Planear y requerimientos del compromete a un
negocio? subconjunto de HU
Estimar • ¿Es correcto el • Estiman las HU
criterio de • La estimación no es
aceptación? exacta

Product
Scrum team
owner
Evalúa
las HU

Aprobar, Estimar y Crear Tareas

comprometerse a
Historias de Usuario
• El Scrum team trabaja en las HU comprometidas
en el proceso anterior.
Fase • El PO apoya al Scrum team a entender mejor las HU
Planear y
Estimar • Estimación de la duración y el esfuerzo requerido
para convertir las tareas en entregables.

• Consenso sobre el criterio de estimación: tiempo

ideal, puntos de historia.

• Técnicas de estimación: estimación análoga,

descomposición, juicio de expertos

56
Aprobar, Estimar y Crear Tareas
comprometerse a
Historias de Usuario

• Lista de tareas con esfuerzo estimado

Fase
• La información es usada para determinar la velocidad
Planear y para el Sprint
Estimar
• La lista de tareas es usado por el Scrum team durante el
Sprint planning meeting para crear el Sprint backlog y el
Sprint Burndown Chart
• Actualización de lista de tareas

Aprobar, Estimar y Técnicas de estimación

comprometerse a
Historias de Usuario
• Estimación por afinidad (CH,M,G)

Fase
Planear y
Estimar

57
Aprobar, Estimar y Técnicas de estimación
comprometerse a
Historias de Usuario
• Wideband
EstimaciónDelphi
por afinidad (CH,M,G)

Fase
Planear y
Estimar

Aprobar, Estimar y Técnicas de estimación

comprometerse a
Historias de Usuario
• Estimación
Wideband Delphi
por afinidad (CH,M,G)
Puntos de historia

Fase
Planear y
Estimar

es una técnica para calcular una estimación basada en el consenso, en su mayoría

utilizada para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo.

58
Aprobar, Estimar y Técnicas de estimación
comprometerse a
Historias de Usuario
• Fist
Wideband
of Five Delphi
Estimación por afinidad (CH,M,G)

1. En desacuerdo 3. No estoy seguro

y me gustaría 5. Totalmente
Fase con el grupo
asumir la conclusión de acuerdo con la
y tengo algunas conclusión
Planear y preocupaciones de consenso del
grupo del grupo
Estimar

2. En desacuerdo 4. Estoy de
con el grupo y acuerdo con
quisiera discutir el grupo y
temas menores quisiera discutir
temas menores

Aprobar, Estimar y
comprometerse a Product
Historias de Usuario Backlog
Meta del
Entregable

Visión

Fase
Planear y
Estimar
Sprint Backlog

Scrum
master,
8 hrs. Para
Inicio del ¿Cuánto equipo de
¿Cuándo? sprints de ¿Quién?
Sprint tiempo? desarrollo,
un mes
Product
Owner

59
 IMPLEMENTAR

Crear entregables

Fase Realizar Daily

StandUp
Implementar
Refinar el Backlog
Priorizado del
Producto

Crear entregables
Crear Entregables
Scrumboard: sirve para planear y dar seguimiento al sprint.

Fase
Implementar

60
Crear entregables
Crear Entregables

• El equipo de desarrollo (Delopment) es el responsable de crear los

entregables del Sprint
Fase
• Entregables del sprint :
Implementar
– Tienen todas las características y funcionalidades definidas en la HU
incluidas en el sprint
• Deberán pasar las pruebas correspondientes antes de realizar la
Ceremonia de revisión del Sprint (Sprint review meeting )

• Ni el PO o el SM pueden decidir cómo va a trabajar el equipo para

desarrollar los entregables

Realizar Daily
¿Qué logré el día de
StandUp ayer?
¿Qué debo terminar
hoy?
El Scrum master
Scrum team ¿Qué obstáculos o resuelve problemas
Comunica el estado impedimentos tuve? e impedimentos.
de su trabajo y su
Sólo es facilitador.
Fase plan en las
El PO sólo es
próximas 24 hrs.
observador
Implementar

Actualizar
Duración Daily -Scrumboard
15 mins Standup -Impediment log

61
Realizar Daily
StandUp
INPUT OUTPUT
Ayer hice…
15 • l día
Inspecciona y adapta
• El trabajo Hoy mi plan es...
Min Me bloquea...
de ayer • Coordinación:
comprobación que todo
Fase el equipo va en la misma
Implementar dirección
• Posibilidad de
reorganizarse
PO • Identificación de
problemas que el equipo
TL tiene que resolver
• Transparencia, confianza
• Mejor auto-organización

Realizar Daily
• Velocidad : representa el número de HU o número de funcionalidades
StandUp
entregadas en un simple sprint.

Velocidad = ∑ Puntos de Historia de todas las H.U.

•Velocidad inicial = ∑Puntos de Historias comprometidos

Fase •Velocidad real = ∑Puntos de Historias Terminadas
Implementar •Velocidad promedio = Promedio de las velocidades reales con relación a
los sprint recorridos.

• Valor entregado al negocio: mide el valor de las HU entregadas

desde la perspectiva del negocio.

• El resultado más importante de este proceso es:

 Sprint Backlog
 Scrum Board
 Sprint Burndown Chart

62
Realizar Daily
StandUp Sprint Burndown Charter
• Gráfica que muestra la cantidad de trabajo restante para concluir el
sprint
• Debe ser actualizado al final del trabajo completado de cada día

Fase
Implementar
Tendencia actual

Tendencia ideal

Realizar Daily
StandUp

• Actualizar el Scrumboard

Fase
Implementar

• Actualizar la bitácora de impedimentos (impediment log)

Consecut- Asunto o Fecha Reportado Persona Fecha Estatus Fecha de Solucion(es)
ivo problema registro por asignada compromiso cierre

63
 Dinámica

Burndown

Refinar el Backlog
Priorizado del
Producto Refinar al Product Backlog
• El PO es responsable de refinar el PBL priorizado

Fase • Se realiza antes de la próxima Ceremonia de Planeación del

Implementar Sprint.

• Se recomienda usar entre el 7% y 10% de tiempo de cada Sprint

para esta actividad

• El PO mantiene reuniones con interesados relevantes para

obtener información y requerimientos.

• Permite incorporar los últimos requerimientos técnicos y del

negocio.

64
Refinar el Backlog
Priorizado del
Producto Refinar al Product Backlog
El product backlog puede ser re-priorizado debido a:

Fase Nuevas historias de usuario

Implementar Nuevas solicitudes de cambio

Nuevos riesgos identificados

Actualización de historias de usuario

Re-priorización de historias de usuario existentes

Rechazo de entregables

Refinar el Backlog
Priorizado del
Producto
Refinamiento de los PBL

Fase
Implementar

65
Refinar el Backlog
Priorizado del
Producto

Fase
Implementar Al final del ¿Cuánto
4 hrs. para
un mes de
Equipo, PO,
Scrum
¿Cuando? ¿Quién?
sprint tiempo? duración del master,
sprint Interesados

REVISIÓN Y
RETROSPECTIV
A
Fase
Revisión y Demostrar y validar
el sprint
Retrospectiva
Retrospectiva del
sprint

66
Demostrar y validar
el sprint
Demostrar y validar el Sprint
• El Development demuestra los entregables desarrollados al PO.

Fase • El PO valida que los entregables cumplen los requerimientos de los

Revisión y
criterios de aceptación.
Retrospectiva
• Los elementos que no son aceptados se regresan a la pila priorizada del
producto PBL (parte de otro sprint)

• Se lleva una lista de los entregables aceptados

• El Scrum master se asegura que el PO no cambia los requerimientos o

criterios de aceptación durante el Sprint

Retrospectiva del
sprint Retrospectiva del Sprint

• El equipo Scrum identifica mejoras potenciales en el proceso

Fase
Revisión y • El Development y el Scrum master asisten a la Ceremonia, también se
Retrospectiva recomienda que asista el PO (no obligatorio).

• La información, opiniones, discusiones y elementos de acción planteados

en la Ceremonia se registran en la bitácora de retrospectiva del Sprint.

• Es el paso final en un Sprint

67
 • Bienvenida a cada uno
Retrospectiva del • Propósito de la Ceremonia
sprint Preparar el escenario • Medición del estado de ánimo

• El equipo comparte datos e información

• Identifica fortalezas y debilidades del Sprint anterior
Recopilar datos • Muestra las cosas más importantes que sucedieron en el
Sprint
Fase
Revisión y • ¿Por qué?
Retrospectiva Generar una visión
• Cosas que funcionaron bien y cosas que deben ser
cambiadas
• Ayuda a tener una perspectiva e identificar la causa raíz

• El equipo se da cuenta de las acciones para mejorar y de

las cosas que ayudan a prevenir o reducir errores
Acción

• Cada miembro del equipo tiene la posibilidad de hacer

Círculo de preguntas y preguntas o expresar dudas
• Clarifica las acciones para el próximo sprint
cierre

Retrospectiva del
sprint

 Acciones de mejora acordadas

 Elementos asignados y fechas compromiso

Fase
Revisión y  Propuesta de elementos no funcionales para incluir en el product
Retrospectiva
backlog (tiempos de respuesta, limitaciones de capacidad, temas de
seguridad).

 Bitácora de retrospectiva del Sprint (Retrospect Sprint Log)

 Lecciones aprendidas del Scrum team

68
Retrospectiva del
sprint

Fase
Revisión y Scrum
4 hrs. para
Retrospectiva ¿Cuando?
Al final del ¿Cuánto un mes de
¿Quién?
master,
Development,
sprint tiempo? duración del
PO
sprint
(opcional)

LIBERACIÓN

Enviar entregables

Fase Retrospectiva del

proyecto
Liberación

69
Enviar Entregables

Entrega de liberación

• No todo Sprint concluye con una liberación

Fase
Liberación • Se realizarán de acuerdo al calendario de liberaciones

• En algunos casos se considera un plan piloto para los entregables liberados

• Se realizará de acuerdo a los métodos de implementación de la

organización

Enviar Entregables

Fase de Inicio Fase de Liberación

Fase
Liberación Elaborar el Plan Liberación de
de liberaciones Entregables
(Conduct Release Planning) (Ship Deliverables)
Calendario
del plan de
liberaciones
(Release Planning
Schedule)

70
Enviar Entregables
Entrega de liberación
Se obtiene:

 Acuerdo de trabajo entregado: firma de aceptación del cliente

Fase
o patrocinador
Liberación
 Entregas de trabajo

 Lanzamiento del Producto

 Contenido de la liberación

 Notas de la liberación

Enviar Entregables  Se reúnen los interesados y el Scrum core team, en conjunto

revisan, analizan e identifican que fue lo correcto y lo incorrecto
realizado durante el ciclo de vida del actual proyecto.

 El objetivo es identificar: formas de colaboración, mejoras en la

Fase eficacia del equipo en futuros proyectos y mejores prácticas.
Liberación
 Mejora toda la implementación de SCRUM

 Las sugerencias, opiniones y conocimiento obtenido en la Ceremonia

se registran para futura referencia.

 La salidas son: acuerdos de acciones de mejora, elementos de

acción asignados y fechas de entrega, recomendaciones para el
Scrum Guidance Body a

71
 Dinámica

Mapa conceptual

Riesgo

72
 También el manifiesto Agile toma ventaja de los
imprevistos.
Recordando…

seguimiento
Respuesta al cambio sobre
de un plan

“ Es un evento incierto, que puede afectar los

objetivos de un proyecto y puede contribuir a su
éxito o fracaso.”

¿Qué es?
• Riesgo es que sucedan cosas diferentes a lo planeado.

• Pueden ser sucesos con aspectos negativos que conocemos como

AMENAZAS

• Existen siempre sucesos con impactos positivos, en cuyo caso las

llamaremos OPORTUNIDADES.

73
 Se incurre en mayor riesgo
Ocurre el mayor impacto

Plan Ejecución

Concepto Desarrollo Implantación Terminación

Oportunidad y Riesgo
Concepto Incremento del Riesgo

Periodo cuando

$ Valor
se incurre en
Periodo de
el mayor riesgo
Impacto mayor
Impacto del riesgo

Paso del Tiempo

Apetito al riesgo: Cantidad de

incertidumbre que la
organización está dispuesto a
asumir.
Actitudes Actitud
ante el ante el
riesgo riesgo de la
Tolerancia al riesgo: Cantidad de riesgo
que los stakeholders resistirán. empresa

Umbral del riesgo: Nivel de riesgo

aceptable para la organización.

74
Aversión al riesgo: No esta dispuesto
a aceptar el riesgo

Actitud ante
Neutral ante el riesgo: No se ve
afectado por el nivel de
incertidumbre de los resultados.
el riesgo de
Stakeholder
Amante al riesgo: Está dispuesto a
asumir el riesgo.

IDENTIFICACIÓN DE EVALUACIÓN DE RIESGOS

RIESGOS Procedimiento
de Gestión de
Riesgos
COMUNICACIÓN DE
RIESGOS MITIGACIÓN DE RIESGOS

PRORIZACION DE
RIESGOS
Risk Adjusted Backlog Risk Burn Down Chart

75
 Probabilidad Amenazas/Oportunidades

0.90 0.09 0.27 0.45 0.63 0.81

0.70 0.07 0.21 0.35 0.49 0.54
0.50 0.05 0.15 0.25 0.35 0.63 Evaluación
0.30 0.03 0.09 0.15 0.21 0.27 de riesgos
0.10 0.30 0.50 0.70 0.90
(Matriz de
probabilidad e
impacto)
Calificación Nivel de
del riesgo Gestión
Riesgo bajo Desestimar
Riesgo medio Monitorear
Riesgo alto Control

Riesgos Probabilidad Impacto V.E Calificación Acciones

El cronograma del proyecto se Dar seguimiento a la
ve afectado porque el entrega y sanción al
proveedor entrega kioskos 0.5 0.9 0.45 MEDIA proveedor si no
fuera de tiempo cumple con lo
acordado
El tiempo se ve afectado por No aceptar el producto Matriz de
recibir Kioskos con defectos de hasta que cumpla con
fábrica y retrasa los tiempos de 0.9 0.9 0.81 ALTA
las condiciones probabilidad
entrega acordadas
No encontrar las infraestructura Inspeccionar las e impacto
solicitada para la Instalación de sucursales antes de
los kioskos comenzar con la
0.9 0.9 0.81 ALTA
instalación para
verificar la
infraestructura
El sistema no está finalizado a Realizar juntas de
tiempo para instalación, debido avance para verificar
a falta de pruebas integrales 0.9 0.9 0.81 ALTA entregables de
acuerdo a los tiempos
del cronograma

76
 • Un árbol de decisión considera eventos futuros para tomar una decisión
en el presente
• Calcula el valor monetario esperado (probabilidad multiplicada por
impacto)

Ejemplo
Una compañía está intentando determinar si vale la pena hacer prototipos para
su proyecto. Ya han establecido los siguientes impactos, los cuáles indican si el
Árboles de
equipo funciona o no. decisiones
Costo de realizar el prototipo $200,000.00
Al realizar el prototipo se cuenta con 35% de probabilidad de falla con un
impacto de 120,000.00
Al no realizar protitopo se cuenta con 30% de éxito y $450,000.00 de impacto si
algo sale mal.
¿Con o sin prototipo?

Falla: 35% probabilidad y

$120,000 impacto
Prototipo
Costo de instalación
$200,000
Aprobación: sin impacto

Falla: 70% probabilidad y

Árboles de
$450,000 impacto decisiones
Sin prototipo
$0
Aprobación: sin impacto

Respuesta: Si únicamente consideras los costos de instalación necesarios para

empezar a hacer prototipos, parecería una mala idea gastar dinero en hacer
prototipos. Sin embargo, el análisis muestra lo contrario. Tomando en cuenta
únicamente un evento a futuro, la decisión es que sería más barato hacer el prototipo.
La respuesta es $242,000, es decir el valor monetario esperado para la decisión de
hacer un prototipo.

77
 Scrum es rápido en identificar y mitigar riesgos y puede mejorar en gran medida las
herramientas de gestión de riesgos
 La lista priorizada de riesgo es combinada con la lista de requerimientos priorizada
para crear un nuevo Backlog ajustada por riesgo.
Backlog Ajustado por

Lista de riesgos
priorizada
Feautures Priorizadas
riesgos

Funcionalidad 1
Backlog de
Riesgo 1
Funcionalidad 1
Acción 2 de Riesgo

Funcionalidad 2
Riesgos
Funcionalidad 2 Funcionalidad 3
Riesgo 2 Acción 2 de Riesgo
Funcionalidad 4
Riesgo 3 Funcionalidad 3
Acción 4 de Riesgo

Riesgo 4 Acción 4 de Riesgo

Funcionalidad 4 Funcionalidad 5

Riesgo 5 Acción 5 de Riesgo

Acción 5 de Riesgo Funcionalidad 5
Funcionalidad 6
Riesgo 6
Funcionalidad 6 Funcionalidad 7
Riesgo 7 Acción 7 de Riesgo Acción 5 de Riesgo

Funcionalidad 7

 La información sobre los riesgos proporcionada a los

interesados debe incluir el impacto potencial y los planes de
respuesta para cada riesgo.

 El equipo Scrum puede además discutir con el Scrum Master

los riesgos relacionados a sus respectivas tareas durante las Comunicación
reuniones diarias de Standup. del riesgo
 El propietario del producto es el/la responsable de priorizar
los riesgos y comunicar la lista priorizada al equipo Scrum.

78
Las siguientes prácticas de Scrum facilitan la gestión
efectiva del riesgo:

• La flexibilidad reduce el riesgo relacionado al entorno

empresarial

• La retroalimentación constante reduce el riesgo Gestión del

relacionado a las expectativas
riesgo
• La propiedad del equipo reduce la estimación de riesgo

• La transparencia reduce el riesgo de no detección

• La entrega iterativa reduce el riesgo de inversión

Escalado

79
 • Se enfoca a la revisión de los entregables y al
trabajo que ha sido realizado y determina el camino
para mejorar las prácticas y métodos usados para Scrum de
hacer el trabajo del proyecto. Scrums

• En grandes organizaciones, el proceso de la fase de

retrospectiva y revisión podría incluir Scrum de Scrums

Scrum de Scrums

• ¿Qué pasa cuando se quiere escalar Scrum a proyectos Scrum de

más grandes? Scrums

• Muchos equipos Scrum necesitan coordinación

• Es similar a una Daily StandUp Meeting para todos los

scrums

80
 Similar al Daily Standup Meeting

• ¿Qué ha hecho mi equipo desde la última reunión?

Scrum de
• ¿Qué hará mi equipo antes de la próxima reunión? Scrums
• ¿Hay algún obstáculo que entorpezca o retrase al equipo?

• ¿El equipo va a necesitar algo del otro equipo?

Convocar Scrum de Scrums

(Convene Scrum of Scrum’s)

Sincronizar los equipos

Facilita el flujo de
información
Mejora la comunicación
Scrum de
6 – 10 miembros
Scrums
6 – 10 miembros
6 – 10 miembros
Coordinada por el Chief Scrum Master
Se lleva a cabo en intervalos predeterminados o cuando el equipo Scrum
lo requiera
En grandes proyectos se puede escalar a una reunión de Scrum de Scrum
de Scrums

81
 Scrum de
Scrums

PERO SERÍA MUCHA GENTE EN UNA REUNIÓN

Cuerpo de · Proporcionar una guía general para los procedimientos de gestión de

asesoramiento de Scrum cambios que deben seguirse durante todo el proyecto
Propietario del producto · Proporcionar solicitudes de cambio para las carteras -Aprobar los
de la cartera productos que son modificados, eliminados o añadidos de acuerdo con
los requisitos de la cartera
Scrum Master de la · Facilitar la identificación, evaluación y gestión de las solicitudes de
cartera cambio para las carteras
Propietario del producto · Proporcionar solicitudes de cambio para los programas
del programa · Aprobar los productos que son modificados, eliminados o añadidos de
acuerdo con los requisitos del programa
Scrum Master del
programa
· Facilitar la identificación, evaluación y gestión de las solicitudes de
cambio para los programas
Roles y
Socios(s) · Proporcionar la solicitud de cambios responsabilidades
· Participar en la aprobación y priorización de las solicitudes de cambio
Propietario del producto · Proporcionar solicitudes de cambio de un proyecto · Evaluar el impacto
de las solicitudes de cambio planteadas por la cartera, el programa o el
proyecto · Priorizar las historias de usuario en la lista priorizada de
pendientes del producto del proyecto · Evaluar el impacto de los
problemas sobre los objetivos del proyecto identificados por el equipo
Scrum · Proporcionar una comunicación clara a los socios sobre los
elementos de la lista de pendientes del producto que se han vuelto a
priorizar
Scrum Master · Facilitar la identificación y evaluación de los problemas y solicitudes de
cambio por el equipo Scrum
Equipo Scrum · Sugerir mejoras o cambios durante los procesos de creación de
entregables y realización de la reunión diaria de pie

82
Jefe Propietario del Producto (Chief Product Owner)

• Esta función se encarga de coordinar el trabajo de múltiples Propietario del producto.

Es el Jefe Propietario del producto quien prepara y mantiene la lista de productos
priorizada.

Jefe Scrum Master (Chief Scrum Master)

• El Jefe Scrum Master es el responsable de resolver los impedimentos que afectan a

más de un Equipo Scrum. Es el coordinador de la coordinación entre distintos
Equipos Scrum que trabajan en un proyecto Scrum se realiza normalmente a través
Otros Roles
de Scrum of Scrums

Conjunto de Orientación de Scrum (Scrum Guidence Body)

• Es un rol opcional, aunque altamente recomendado para formalizar las prácticas

organizacionales relacionada a Scrum. Se compone de un grupo de documentos y/o
un grupo de expertos que normalmente están involucrados en definir los objetivos
relacionados a la calidad.

Portafolios, programas y/o Es un grupo de programas relacionados con la finalidad

de entregar resultados de negocio como se define en la
proyectos de cualquier sector declaración de la visión del portafolio.

Productos, servicios o Complejidad

cualquier otro Es un grupo de proyectos relacionados con la finalidad
resultado que se de entregar resultados de negocio definidos en la
entregará a los socios declaración de la visión del programa.

Proyectos de
cualquier
Un proyecto es un emprendimiento colaborativo para
tamaño y crear nuevos productos o servicios.
complejidad

83
 1. Portfolio Propietario del producto—Define los objetivos
estratégicos y las prioridades del Portfolio.
Portafolio 2. Portfolio Scrum Master—Resuelve problemas, elimina
Impedimentos, facilita, y lleva a cabo reuniones para el
Porftolio.

1. Program Propietario del producto—define los objetivos y

las prioridades estratégicas para el programa.
2. Program Scrum Master—Resuelve problemas, remueve
Complejidad
Programa Impediments, facilita, y lleva a cabo reuniones para el
programa.

Equipo de desarrollo.
Dueño del producto Scrum Master

Proyecto

Portafolio
Conjunto de Orientación de
Scrum • Administrar todos los programas y proyectos
(Scrum Guidence Body) • Trabajo a realizar está contenida en un Portfolio Backlog

• Opcional
• Podría ser sólo un
conjunto de documentos o
grupo de expertos
• Definir los objetivos
relacionados con la
calidad, regulación
gubernamental, seguridad
y otros parámetros claves
• Utilizado por los Scrum
Teams cuando es
necesario para su trabajo
Programa
• Administrar proyectos relacionados
• Trabajo a realizar está contenida en un Program
•
Backlog
Realizar la reunión de priorización del Program Backlog
Complejidad
de 2 a 6 meses
Proyecto
• Los proyectos gestionados por los respectivos Scrum
Teams
• Un proyecto puede tener uno o más Scrum Tems
• Trabajo a realizar está contenido en un Product
Backlog
• Trabajo acompañado en Sprint de 1 a 6 semanas
• Realizar Scrum of Scrums para coordinar y
comunicarse entre Scrum Teams

84
 Thai
Traditional Chinese

Thank You English

Russian

Gracias Spanish

Merci
French
Obrigado
Brazilian Portuguese
Arabic

Grazie Danke
Italian German
Simplified Chinese

Japanese

Anexo

85
¿Quién
aprueba el
cambio?

¿Quién
valida el
cambio?

86
 Estimación del valor del proyecto
• Retorno sobre la inversión
• Valor presente neto
• Tasa interna de retorno Técnicas de
Planificar por valor Justificación
• Mapa de flujo de valor
• Priorización basa en el valor para el cliente
del negocio
• Esquemas simples cuando es
• MoSCoW
• Dinero Monopoly complejo
• 100 puntos
• Kano
Clasificación relativa de priorización

Mapeo de historias

• Retorno sobre la inversión.

Evalúa los ingresos neto esperados que se busca
obtener a partir de un proyecto.
RSI RSI=(Ingresos del proyecto – Costo del proyecto)/Costo de
proyecto Técnicas de
Justificación
• Valor Presente Neto.
del negocio
Se utiliza para determinar el valor neto actual de un cuando es
VPN futuro beneficio económico.
complejo
• Tasa Interna de Retorno.
Tasa de descuento sobre una inversión a fin de evaluar
TIR la tasa de retorno del proyecto.

87
Ejemplo: El RSI para un proyecto que tendrá un costo de $125,000 en desarrollarse y con
beneficios económicos estimados en $300,000, se calcula de la siguiente forma:

RSI = ($300,000 – $125,000) / $125,000 = 1.4 Técnicas de

Por lo tanto, el RSI es 1.4 veces la inversión (o 140 %). Justificación
Ejemplo: ¿Cuál de los siguientes dos proyectos es la mejor opción si se utiliza el VPN como
criterio de selección?
del negocio
• El proyecto A tiene un VPN de $1,500 y se completará en 5 años.
cuando es
• El proyecto B tiene un VPN de $1,000 y se completará en 1 año. complejo
Solución: El proyecto A, ya que su VPN es más elevado. Aquí no se toma en cuenta el
hecho
de que el proyecto B tiene una duración más corta que el proyecto A, pues el tiempo ya
está
representado en los cálculos del VPN (debido a que es el valor actual y no el valor futuro
que
se considera en el cálculo).

Técnicas de
Ejemplo: Basado en el TIR, ¿cuál proyecto es más conveniente?
• Proyecto A, que tiene una TIR del 15 % y se completará en 5 años. Justificación
• Proyecto B, que tiene una TIR del 10 % y se completará en 1 año.
Solución: El proyecto A, ya que su TIR es mayor. Aquí no se toma en cuenta el hecho de del negocio
que el
proyecto B tiene una duración más corta que el proyecto A, pues el tiempo ya está cuando es
representado en los cálculos del TIR (tal como en el VPN, es el valor actual y no el valor
futuro complejo
el que se utiliza para determinar la TIR).

88