Scrum Master, Agislismo en Proyectos.

1
 Instructores:
HECTOR LOPEZ FUENTES
Arquitecto y gerente de proyectos de software, Especializado en proyectos en el
área Tecnológica.
• Ingeniero de Sistemas de la Universidad San Buenaventura Cartagena
• Especialista en Ingeniería de Software, Universidad del Norte Barranquilla.
• Miembro de la Asociación Colombiana de Ingenieros de Sistemas
• Consultor en temas de: Planeación Estratégica de TICs, Arquitectura
Empresarial, Arquitectura de Soluciones de TIC y Arquitecturas Orientadas a
Servicios, Gerencia de Proyectos, Gobernabilidad de TI, Sistemas de Gestión
de seguridad (Iso 27001)
• Con 6 años de experiencia en compañías públicas y privadas en proyectos de
innovación tecnológica, Gestión de Servicios de TICs, desarrollo de software,
seguridad de la información y arquitectura empresarial.

(57)310 – 300 3233

 CONTENIDO
1. Introducción y Contexto de Proyectos
2. Introducción a las practicas agiles
3. Introducción a Scrum
4. Scrum a Fondo
5. Ejercicio Scrum-LEGO

3
 Justificación del Curso

• Scrum Master es una certificación que valida los

conocimientos de un profesional relativos a
la mezcla de las metodologías ágiles y las prácticas
de Scrum.
• Las Metodologías ágiles son populares en los
enfoques de desarrollo de software y cada vez más
se están utilizando en otras áreas. Este
Entrenamiento se enfoca en cómo usar Scrum y
como ser un Scrum Master para cualquier tipo de
proyecto.
4
 Justificación del Curso

• Las Prácticas de Scrum incluyen el

establecimiento de equipos multi-funcionales
y autogestionados, produciendo una entrega
de trabajos al final de cada iteración o Sprint.

5
 BIBLIOGRAFÍA & MATERIAL DE REFERENCIA

• La Guia de Scrum – Julio 2014

• Manifiesto Agil.
• Material de apoyo.

6
 CONTENIDO
1. Introducción y Contexto de Proyectos
2. Introducción a las practicas agiles
3. Introducción a Scrum
4. Scrum a Fondo
5. Ejercicio Scrum-LEGO

7
 Qué es un Proyecto?

Un proyecto es un
esfuerzo temporal para
generar un producto,
servicio o resultado
único.

8
 Qué es un Proyecto
• Definición de Proyecto:
– Envoltorio Temporal con un principio y final
– Crea un servicio, producto ó resultado único
– Se hace por un motivo (ojalá alienado al plan
estratégico del negocio)
– Tiene actividades interrelacionadas
– Es Progresivamente elaborado mientras se adquiere
mayor información
• Es un envoltorio temporal para la creación de un
producto ó servicio único

9
 La Triple Restricción
Alcance

Exito

Calidad Costo

Tiempo
11
Aproximaciones a la gestión de
proyectos de Software

Metodologías guiadas por un plan. Algunos

las consideran como la aproximación
tradicional al desarrollo de software.
Metodologías ágiles. Entre las mas
conocidas se encuentran XP, SCRUM, UP
(RUP), etc. Algunos no consideran RUP como
ágil, pues es una mezcla.

Agilidad, disciplina o caos

… obedece a la mala
adaptación de la planeación
predictiva al desarrollo de
software

Salvo excepciones, el modelo en cascada

no funciona bien en el desarrollo de software

Agilidad, disciplina o caos

Requerimientos

Análisis y diseño

Diseño detallado

Codificación

Pruebas

Operaciones
 Manufactura predecible
Es posible completar las
especificaciones y luego construir el
producto de manera repetida
Cerca al comienzo, se pueden hacer
estimaciones confiables de esfuerzo y
costo
Es posible identificar, definir, programar
y ordenar todas las actividades en
detalle
La adaptación a cambios impredecibles
no es la norma pues la rata de cambios
es baja
Desarrollo de nuevo
producto
Raramente es posible crear desde el
comienzo especificaciones que no
cambien
Cerca al comienzo no es posible
estimar. La confiabilidad crece en la
medida que avanza el proyecto
Cerca al comienzo no es posible hacerlo
pues se trata de un nuevo producto (casi
siempre)
La adaptación a los cambios es la
norma. La rata de cambios es elevada
Sobre costos, proyectos muy demorados en el
tiempo, baja calidad. En general, proyectos
impredecibles.
Integración en etapas finales y problemas tardíos
de diseño
Mucho re trabajo
Software que no satisface las necesidades de
clientes y usuarios

Insatisfacción generalizada de los interesados

(Cliente, usuarios, grupo de ingeniería, proveedor
del software, etc.)
• Pérdida de dinero (sobre costos, necesidad
del producto, etc.)
• Cuestionamiento al grupo de ingeniería
(interno
o externo)
• Abordar el problema incorrecto

Hoy en día no triunfan las empresas mas poderosas

económicamente, lo hacen las más rápidas y más
innovadoras
El desarrollo en cascada es fácil de explicar. El
iterativo e incremental es mas complejo

Puede dar la ilusión , en algunas personas, de un

proceso ordenado, predecible y medible

Porque no se quiere hacer el esfuerzo para

buscar otras formas de hacerlo
Por presión de compradores, la cual a su vez
proviene de los CEO, CIO, etc. “Cuánto se
demora”, “Cuánto vale”, etc.
 CONTENIDO
1. Introducción y Contexto de Proyectos
2. Introducción a las practicas agiles
3. Introducción a Scrum
4. Scrum a Fondo
5. Ejercicio Scrum-LEGO

19
 Manifiesto Ágil
• El 17 de febrero de 2001 diecisiete críticos de los
modelos de mejora del desarrollo de software, se
reunieron en Utah para tratar sobre técnicas y procesos
para desarrollar software. En la reunión se acuñó el
término “Métodos Ágiles” para definir a los métodos
que estaban surgiendo como alternativa a las
metodologías formales que se consideraban
excesivamente “pesadas” y rígidas por su dependencia
de planificaciones detalladas previas al desarrollo.
• Los integrantes de la reunión resumieron los Doce
principios en cuatro postulados (valores), lo que ha
quedado denominado como Manifiesto Ágil.
• http://www.agilemanifesto.org/iso/es/
20
Aspectos o Valores del Manifiesto

21
 Actividad
Manifiesto Ágil

22
 Valorar más a los individuos y su
interacción que a los procesos y las
herramientas
• Por supuesto que los procesos ayudan al trabajo. Son una guía de
operación. Las herramientas mejoran la eficiencia, pero sin personas con
conocimiento técnico y actitud adecuada, no producen resultados.
• Las empresas suelen predicar muy alto que sus empleados son lo más
importante, pero la realidad es que la teoría de producción basada en
procesos, ha dado a estos más relevancia en tareas que deben su valor
al conocimiento y al talento de las personas que las realizan.
• Los procesos deben ser una ayuda y un soporte para guiar el trabajo.
Deben adaptarse a la organización y a las personas; y no al revés. La
defensa de los procesos lleva a pensar que con ellos se pueden
conseguir resultados extraordinarios con personas mediocres. Este
principio es peligroso cuando los trabajos necesitan creatividad e
innovación. 23
 Valorar más el software que funciona
que la documentación exhaustiva
• Poder ver anticipadamente cómo se comportan las funcionalidades
esperadas sobre prototipos ofrece una retroalimentación que genera ideas
imposibles de concebir en un primer momento; difícilmente se podrá
conseguir un documento que contenga requisitos detallados antes de
comenzar el proyecto.
• El manifiesto no afirma que no hagan falta. Los documentos son soporte de
la documentación, permiten la transferencia del conocimiento y en muchas
cuestiones legales o normativas son obligatorios, pero se resalta que son
menos importantes que los productos que funcionan. Menos trascendentales
para aportar valor al producto.
• Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y
generación de valor que se logra con la comunicación directa entre las
personas y a través de la interacción con los prototipos. Por eso, siempre que
sea posible debe preferirse, y reducir al mínimo indispensable el uso de
documentación, que genera trabajo que no aporta un valor directo al
producto. 24
 Valorar más la colaboración con el
cliente que la negociación contractual
• Las prácticas ágiles están especialmente indicadas para
productos difíciles de definir con detalle en el principio, o que si
se definieran así tendrían al final menos valor que si se van
enriqueciendo con retro-información continua durante el
desarrollo. También para los casos en los que los requisitos van a
ser muy inestables por la velocidad del entorno de negocio.

• Para el desarrollo ágil el valor del resultado no es consecuencia

de haber controlado una ejecución conforme a procesos, sino de
haber sido implementado directamente sobre el producto. Un
contrato no aporta valor al producto. Es una formalidad que
establece líneas divisorias entre responsabilidades, que fija los
referentes para posibles disputas contractuales entre cliente y
proveedor.
25
 Valorar más la respuesta al cambio
que el seguimiento de un plan
• Para un modelo de desarrollo que surge de
entornos inestables, que tienen como factor
inherente el cambio y la evolución rápida y
continua, resulta mucho más valiosa la capacidad
de respuesta que la de seguimiento y
aseguramiento de planes pre-establecidos. Los
principales valores de la gestión ágil son la
anticipación y la adaptación; diferentes a los de la
gestión de proyectos ortodoxa: planificación y
control para evitar desviaciones sobre el plan.

26
 12 Principios del Manifiesto Ágil
1. Nuestra mayor prioridad es satisfacer al cliente mediante
la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan el
cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de
tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo el
proyecto.
27
 12 Principios del Manifiesto Ágil
5. Los proyectos se desarrollan en torno a individuos motivados.
Hay que darles el entorno y el apoyo que necesitan, y confiarles
la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al
equipo de desarrollo y entre sus miembros es la conversación
cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.

28
 12 Principios del Manifiesto Ágil
9. La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.
10.La simplicidad, o el arte de maximizar la cantidad
de trabajo no realizado, es esencial.
11.Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.
12.A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.

29
 Declaración de Interdependencia
• El manifiesto ágil es muy conocido en el mundo de las
metodologías ágiles, sin embargo, el DOI o “La Declaración
de Interdependencia” es un gran desconocido.
• Este manifiesto se firmó en el 2005 por un grupo de jefes de
proyecto, gerentes y expertos incluyendo dos de los autores
originales del “Manifiesto por el desarrollo ágil del
software“. Este manifiesto, al contrario que el anterior, está
más enfocado a la gestión ya que la idea original era
extender el manifiesto por el desarrollo ágil de software a
productos que no fueran solamente software, a gestión de
proyectos en particular y a gestión en general.

30
 Declaración de Interdependencia
• Incrementamos el retorno de la inversión enfocándonos en
tener un flujo continuo de valor.
• Entregamos resultados fiables involucrando al cliente
frecuentemente y haciéndolos responsables de parte del
trabajo.
• Esperamos incertidumbre y la manejamos mediante iteraciones,
anticipación y adaptación.
• Dejamos correr la creatividad y la innovación reconociendo que
los individuos son la máxima fuente de valor y creando un
entorno de trabajo donde puedan marcar la diferencia.
• Fomentamos el rendimiento a través de la responsabilidad
compartida en los resultados y en la efectividad del equipo.
• Mejoramos la efectividad y la fiabilidad mediante estrategias,
procesos y prácticas específicas para cada situación.
31
 Que es agilidad?
• Es la capacidad de crear y
responder a cambio con el fin de
obtener ganancia en un entorno
empresarial turbulento.

• En cualquier disciplina, ser ágil es

una cualidad, por lo tanto esto
debe ser una meta que se debe
tratar de alcanzar.
32
 ¿Por qué agilidad?
• La agilidad es una necesidad que surge del hecho
de que desarrollar software es algo complejo y no
se puede planificar de manera perfecta dada la
velocidad y los distintos cambios. Aunque admitir
esto requiere coraje, requiere de mas coraje
admitirlo y vivir de acuerdo a sus consecuencias.

• La gestión de proyectos Ágil especialmente implica

la adaptabilidad durante la creación de un
producto, servicio o cualquier otro resultado.

33
Métodos agiles

34
Métodos Agiles Vs Tradicionales

35
Métodos Agiles Vs Tradicionales

36
37
38
 Herramientas
• Seenowdo
• Pango Scrum
• ScrumDo
• LeanKit
• Scrumrf
• Atlassian Jira
• TinyPM
• IceScrum
• Trello

39
 CONTENIDO
1. Introducción y Contexto de Proyectos
2. Introducción a las practicas agiles
3. Introducción a Scrum
4. Scrum a Fondo
5. Ejercicio Scrum-LEGO

40
 Que es Scrum?
• Scrum es un marco de trabajo para el
desarrollo y el mantenimiento de productos
complejos. En Scrum se describen los roles,
eventos y artefactos de Scrum, y las reglas que
los relacionan.
• Ken Schwaber y Jeff Sutherland desarrollaron
Scrum.

41
 Otra Definición

• Marco de Trabajo de adaptación iterativa e

Incremental, rápida, flexible y eficaz
diseñada para ofrecer un valor significativo
de forma rápida en todo el proyecto.
• Scrum es:
– Ligero
– Fácil de entender
– Extremadamente difícil de llegar a dominar
42
 Control del Proceso
Empírico (empirismo)
• Las decisiones de Scrum se toman sobre la
base de la observación y experiencia mas que
sobre una planeación detallada.

Transparencia Inspección Adaptación

43
 Adopciones de Scrum
Scrum Técnico Scrum Pragmatico
• Marco de reglas para el • 4 aspectos de agilidad
desarrollo de scrum • Incertidumbre
• Roles • Fases del desarrollo
• Ceremonias • Control Sutil
• Artefactos • Difusión del
Conocimiento

45
46
Historia

47
Ciclo de Vida de Scrum

48
49
 CONTENIDO
1. Introducción y Contexto de Proyectos
2. Introducción a las practicas agiles
3. Introducción a Scrum
4. Scrum a Fondo
- Roles
- Artefactos
- Eventos o ceremonias de Scrum.
5. Ejercicio Scrum-LEGO
50
Roles

51
 Roles
• Entender los roles y responsabilidades
definidos en Scrum es muy importante para
garantizar el éxito en la implementación de
Scrum.

• Product Owner – Scrum Master – Scrum

development|: comprometidos
• Stakeholder: Implicado

52
 Scrum Team – Scrum Core Roles

• Son aquellos roles obligatorios para producir

el producto o servicio del proyecto

53
 Características del equipo Scrum
• Auto-organizados.
• Multifuncionales

Los equipos auto-organizados eligen la mejor forma de llevar a

cabo su trabajo y no son dirigidos por personas externas al equipo.

Los equipos multifuncionales tienen todas las competencias

necesarias para llevar a cabo el trabajo sin depender de otras
personas que no son parte del equipo. El modelo de equipo en
Scrum está diseñado para optimizar la flexibilidad, la creatividad y
La productividad

54
 Como aplicarlo?
• Que características deberían tener los
miembros de Scrum?.
• Que problemas podrían tener equipos Scrum
Recien constituidos?
• Que problemas podrían tener equipos Scrum
con integrantes “Juniors”?

55
Actividad roles

56
 Producto Owner

• Representa la voz del cliente y es el

encargado de maximizar el valor del
producto.
• Un PO siempre debe tener una
visión Dual:
– Entender y apoyar las necesidades e
intereses de todos los Stakeholders.
– Comprende las necesidades y el
funcionamiento del Development team
57
Características del PO

58
 Características
• Es una única persona, NO un comité.
• Quien quiera realizar cambios en la prioridad
de la lista del producto, deben “convencer” al
PO.
• Toda la organización debe respetar sus
decisiones.

59
Responsabilidades del PO

60
Responsabilidades del PO

61
 Gestionar la lista de producto
• Expresar claramente los elementos de la Lista del Producto
• Ordenar los elementos en la Lista del Producto para
alcanzar los objetivos y misiones de la mejor manera
posible
• Optimizar el valor del trabajo desempeñado por el Equipo
de Desarrollo
• Asegurar que la Lista del Producto es visible, transparente
y clara para todos, y que muestra aquello en lo que el
equipo trabajará a continuación.
• Asegurar que el Equipo de Desarrollo entiende los
elementos de la Lista del Producto al nivel necesario

63
 Scrum Master

• Es un Líder Servicial, un facilitador.

Su responsabilidad es asegurar que
Scrum es “entendido y adoptado”.
• Esta al servicio del equipo Scrum
para que esté dotado de un
ambiente adecuado para terminar el
proyecto con éxito y esto incluye
“eliminar los impedimentos” que
encuentra el equipo.
64
Características

65
Responsabilidades del SM con el PO

66
Responsabilidades del SM
con la organización

67
Responsabilidades del SM
con el Development Team

68
 Development Team
• Es el Grupo o equipo de
personas responsables de la
comprensión de los requisitos, la
estimación y la creación de los
entregables.
• Solo los miembros del
Development participan en la
creación del incremento

70
 Tamaño del equipo
• El tamaño óptimo del Equipo es de 3 a 9 miembros.
• Tener menos de tres miembros en el Equipo de
Desarrollo reduce la interacción y resulta en ganancias
de productividad más pequeñas. Los Equipos de
Desarrollo más pequeños podrían encontrar
limitaciones en cuanto a las habilidades necesarias
durante un Sprint.
• Tener más de nueve miembros en el equipo requiere
demasiada coordinación. Los Equipos de Desarrollo
grandes generan demasiada complejidad como para
que pueda gestionarse mediante un proceso empírico.
71
Características del
Development Team

72
Responsabilidades del
Development Team

73
Responsabilidades del
Development Team

74
https://www.youtube.com/watch?v=XQP_vM7G
IFM

75
 Stakeholders
• Es el termino colectivo que incluye a:
– Clientes
– Usuarios
– Patrocinadores.
• Que interactúan con frecuencia con el equipo
Scrum (scrum Team) para proporcionar
entradas y facilitar la creación del producto o
servicio del proyecto.

78
79
 Conceptos claves
• Historias de usuario: es una representación de un
requisito del usuario en forma escrita, utilizando
lenguaje común del usuario
• Épicas: Es una historia de usuario demasiado grande
para caber en un Sprint, a menudo este termino se
utiliza para describir una gran funcionalidad que
tendrá que dividirse en historias mas pequeñas.
• Task-tareas: Es una representación del requisito que
esta en lenguaje de usuario pero de una forma
técnica en la que se define como se va a trabajar.
80
Nivel de detalle

81
 Como esta conformada una Historia de usuario.

• Una Historia de usuario • Modelo Invest:

debe estar conformada – Independencia.
por las 3C:
– Negociables
– Card: Descripción escrita
de lo que necesita el – Valiosa
usuario. – Estimable
– Conversación: El PO y el – Pequeña (Short)
ST aclaran detalles. – Verificable. (testeable)
– Confirmación: sirve para
determinar lo que se
espera
82
 INVEST
• Independiente: Describe una funcionalidad completa, que no
tiene una dependencia inherente con otra historia.
• Negociable: Puede ser modificada hasta que no está en proceso
de desarrollo, o incluida en un sprint que se está ejecutando.
• Valiosa: El producto tiene más valor para el cliente cuando la
funcionalidad está completada.
• Estimable: Es posible estimar el tamaño de la historia.
• Pequeña(Short): Tiene que poder estimarse con precisión
suficiente empleando técnicas ágiles, que se basan en juicio de
expertos y emplean unidades de medida relativas.
• Comprobable (Testable): Debe incluir información para
determinar cuándo está terminada y cumple las expectativas del
cliente.

83
Titulo: ID
Descripción:
Quien Quiero Beneficio
Prioridad Estimación

CRITERIOS DE ACEPTACIÓN

84
85
 Task - Tarea
• Unidad de trabajo gestionada por el
Development Team. Una tarea tiene asignada
una persona para su realización y es
recomendable que el esfuerzo estimado para
llevarla a cabo sea como máximo el equivalente a
una jornada de trabajo.
• Una tarea es creada en lenguaje técnico,
mientras la historia de usuario es creada en
lenguaje de usuario

86
 Características de una
Tarea
• SMART
ID:
• S: Specific (especifica)
• M: Medible Responsable:
• A: Alcanzable Descripción:
• R: Relevante
• T: Tiempo determinado Estimación:

87
 Definición de Hecho (DoD)

• Cuando un elemento del Product Backlog se

describe como “Terminado”, todo el mundo debe
entender lo que significa “Terminado”. Aunque
esto varía significativamente para cada Equipo
Scrum, los miembros del Equipo deben tener un
entendimiento de lo que significa que el trabajo
esté completado, para asegurar la transparencia.

88
 El Quién, Cuándo y Cómo de la definición de
hecho
Quién: la definición de hecho debe de construirse entre el
equipo y el Product Owner. El Scrum Master tiene la labor
de facilitar su generación, recopilar los acuerdos tomados
y de ayudar a su puesta en práctica.
Cuándo: debe de realizarse al inicio del proyecto, antes de
empezar el desarrollo. Evidentemente, por la propia
evolución del proyecto podremos encontrarnos con la
necesidad de realizar ajustes en la definición original,
tanto para introducir como para eliminar puntos de
control.
Cómo: para poner en práctica la definición de hecho lo más
sencillo y adecuado es interpretarla como un checklist a
utilizar por el equipo durante el desarrollo, pero
sobretodo, antes de cerrar las historias.
89
Ejemplo

90
91
 Artefactos SCRUM
• Los artefactos Scrum son herramientas que
propone SCRUM para mantener organizado
un proyecto:
• Product Backlog
• Sprint Backlog
• Incremento del Producto
• Burn-down Chart (seguimiento del Sprint)

92
 Product Backlog
• Artefacto escencial de Scrum, es una lista ordenada
de las ideas (historias de usuario) para el producto,
todo el trabajo del equipo proviene del Product
Backlog.
• El Product Owner es el responsable de este
artefacto, incluyendo el contenido, disponibilidad y
orden.
• La Lista de Producto nunca está completa. El
desarrollo más temprano de la misma solo refleja los
requisitos conocidos y mejor entendidos al principio.
La Lista de Producto evoluciona a medida de que el
producto y el entorno en el que se usará lo hacen.
93
 Product Backlog
• Mientras el producto exista, su Lista de Producto también
existe.
• La Lista de Producto enumera todas las características,
funcionalidades, requisitos, mejoras y correcciones que
constituyen cambios a ser hechos sobre el producto para
entregas futuras.
• Los elementos de la Lista de Producto tienen como
atributos la descripción, la ordenación, la estimación y el
valor.
• Los requisitos nunca dejan de cambiar, así que la Lista de
Producto es un artefacto vivo. Los cambios en los requisitos
de negocio, las condiciones del mercado o la tecnología
podrían causar cambios en la Lista de Producto.
94
Ejemplos

95
PBL en una Dinámica
Empresarial

96
 Refinar el PBL
• Es el acto de añadir Detalle, estimaciones y orden a los
elementos de la lista de Producto. Se Trata de un
Proceso continuo, en el cual el Product Owner y el
Development Team detallan los elementos del Backlog
de producto. El equipo decide como y cuando hacer el
refinamiento.
• Esta tarea consume no mas del 10% de la capacidad
del Development Team.
• ¿Quien Define cual es la estimación de un elemento
del PBL?

97
 Sprint Backlog
• Es el conjunto de elementos (Historias de
usuario) del Product Backlog mas un plan
(Tareas) para entregar el incremento de
producto y conseguir el objetivo del Sprint.
• El Sprint Backlog hace visible el trabajo que el
equipo identifica como necesario para
alcanzar el objetivo del Sprint.
• Este Sprint Backlog se ve representado por
medio de tableros Scrum.

98
 Sprint Backlog
• El equipo modifica el Sprint Backlog a lo largo
de todo el Sprint.
• Se añaden o eliminan tareas a medida q se
hace necesario.
• Se actualizan las horas restantes estimadas
por cada tarea.
• Solo el Development Team puede cambiar las
tareas o las estimaciones.

99
100
Del PBL al Sprint Backlog

101
 Burn-Down Chart
• El Diagrama Burn-Down Chart es una representación
Grafica del trabajo por hacer en un Sprint o
Producto.
• En cualquier momento durante un Sprint, es posible
sumar el trabajo restante total en los elementos de
la Lista de Pendientes del Sprint. El Equipo de
Desarrollo hace seguimiento de este trabajo
restante total al menos en cada Scrum Diario para
proyectar la posibilidad de conseguir el Objetivo del
Sprint.

102
103
 Incremento del Producto
• Al final de cada Sprint se Produce un incremento de
producto utilizable. Este debe contar con una calidad lo
suficientemente alta como para ser entregado a usuarios
finales.
• 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.
• El incremento del producto debe cumplir con la
Definición de Hecho (DoD) actual de cada equipo Scrum
y cada parte del miso debe ser aceptable para el product
owner.
104
105
106
 Eventos Scrum “Ceremonias o
Reuniones”
• La comunicación es muy importante para el éxito de los
proyectos por esta razon los equipos Scrum emplean
una serie de reuniones claves:
• Sprint
– Sprint Planning Meeting
• Sprint goal
– Daily Scrum Meeting
– Sprint Review
– Sprint Retrospective.
• Todos los eventos son bloques de tiempo (time-boxes),
de tal modo que todos tienen una duración máxima
107
 Sprint
• El corazón de Scrum es el Sprint, es un bloque de
tiempo (time-box) de un mes o menos durante el cual
se crea un incremento de producto utilizable. Cada
nuevo Sprint comienza inmediatamente después de la
finalización del Sprint previo.
• Los Sprints contienen las demás ceremonias de
Scrum.
• Durante el Sprint:
– No se realizan cambios que puedan afectar al Sprint Goal
– Los objetivos de calidad no disminuyen; El alcance puede
ser clarificado y renegociado entre el Dueño de Producto y
el Equipo de Desarrollo.

108
 Sprint
• En el Sprint el Development team construye el
incremento del producto.
• El Scrum Master facilita y proteje al Equipo de
impedimentos internos y externos, con el fin de evitar
retrasos.
• Cada Sprint puede considerarse un proyecto con un
horizonte no mayor de un mes. Cada Sprint tiene una
definición de qué se va a construir, un diseño y un
plan flexible que guiará la construcción y el trabajo y
el producto resultante. (Sprint Backlog)

109
 Porque Sprint de máximo
un mes?
• Cambios en la definición de lo que se esta
construyendo.
• Complejidad puede elevarse junto con el
riesgo.
• Riesgo de costo limitado.

110
 Cancelar un Sprint
• Un Sprint puede ser cancelado antes de que llegue a su fin.
Solo el PO tiene la autoridad para cancelar el Sprint, aunque
puede hacerlo bajo la influencia de los interesados, del
Equipo de Desarrollo o del SM.
• Un Sprint se cancelaría si el Objetivo del Sprint llega a
quedar obsoleto. En general, un Sprint debería cancelarse si
no tuviese sentido seguir con él. Pero debido a la corta
duración de los Sprints, rara vez la cancelación tiene
sentido.
• Se revisan todos los Elementos de la Lista de Producto que
se hayan completado y “Terminado”. Si una parte del
trabajo es potencialmente entregable, el Dueño de
Producto normalmente lo acepta

111
 Reunión de planificación de Sprint
• Se planifica el trabajo a realizar durante el Sprint. Este plan
se crea mediante el trabajo colaborativo del Equipo Scrum
completo.
• Tiene un máximo de duración de ocho horas para un Sprint
de un mes (o proporcional).
• El Scrum Master se asegura que se lleve a cabo, que los
asistentes entiendan su propósito y que se realice en el
bloque de tiempo.
• La Reunión de Planificación de Sprint responde a las
siguientes preguntas:
– ¿Qué puede entregarse en el Incremento resultante del Sprint
que comienza?
– ¿Cómo se conseguirá hacer el trabajo necesario para entregar
el Incremento?
112
 Que puede ser terminado
• El Development Team proyecta la funcionalidad que se
desarrollará durante el Sprint. El PO presenta el objetivo
que el Sprint debería lograr y los Elementos del Product
Backlog que lograrían el Objetivo del Sprint.
• Entradas:
– Product Backlog
– Último Incremento de producto
– Capacidad proyectada del Equipo de Desarrollo.
– Rendimiento pasado del Equipo de Desarrollo.
• El número de elementos del PBL para el Sprint depende
únicamente del Development Team. El Equipo Scrum
elabora un Objetivo del Sprint (Sprint Goal). El Objetivo del
Sprint provee una guía al equipo de desarrollo de por qué
se está construyendo el incremento.
113
 Como se completara el trabajo seleccionado?
• Con el Objetivo del Sprint y las historias de usuario (PBL) el
development Team decide técnicamente como construirá el
incremento del producto, esto hace referencia a la creación de
tareas. Las tareas se deben detallar en unidades de un día o menos
• Los elementos del PBL seleccionados y el plan para terminarlos,
reciben el nombre de Lista de Sprint Backlog.
• El Dueño de Producto puede ayudar a clarificar los elementos de la
Lista de Producto seleccionados. Si el Equipo de Desarrollo tiene
demasiado trabajo o no tiene suficiente trabajo, podría renegociar
los elementos del PBL.
• Al finalizar la Reunión de Planificación, el Equipo de Desarrollo
debería ser capaz de explicar al Dueño de Producto y al Scrum
Master cómo pretende trabajar como un equipo autoorganizado
para lograr el Objetivo del Sprint

114
 Reunión diaria (daily Meeting)
• Ceremonia diaria para evaluar y optimizar el
progreso hacia el objetivo del Sprint y crear el
plan de las siguientes 24 horas.
• Se realiza a la misma hora en el mismo lugar,
para reducir la complejidad.
• Duración máxima 15 minutos.
– Que termine ayer?
– Que voy a terminar hoy?
– Que impedimentos estoy enfrentando?

115
 Sprint Review

• Reunión al final del Sprint en donde se hace la

presentación del incremento del producto.
• Duración 4 horas para un Sprint de 1 mes.
• Se explica que elementos del PBL se han
“terminado” y cuales no. El equipo demuestra
los elementos terminados.
• Se realiza una primera aproximación a que se
realizara en el próximo sprint.

116
 Sprint Retrospective
• Ultima reunión del Sprint, el Scrum team revisa y
reflexiona sobre el sprint basado en los resultados
obtenidos.
• Duración 3 horas para sprint de 1 mes.
• El propósito de la Retrospectiva de Sprint es:
– Inspeccionar el resultado del Sprint en cuanto a
personas, relaciones, procesos y herramientas.
– Identificar y ordenar los elementos más importantes que
salieron bien y las posibles mejoras.
– Crear un plan para implementar las mejoras a la forma
en la que el Equipo Scrum desempeña su trabajo.

117
 Etapas de una retrospectiva
1. Preparar el escenario.
2. Recolectar datos
3. Reflexionar
4. Decidir que hacer
5. Cerrar la retrospectiva.

* Técnicas de retrospectiva.

118
 Temas Con mayor
ponderación en el Examen

1. Introducción a Agilísimo y a Scrum

2. Practicas de Scrum
3. Planeación en Scrum
4. Eventos en Scrum
5. Monitoreo de Proyectos Scrum
6. Rol Scrum Master Vs Product Owner
119
PREGUNTAS?

GRACIAS!!
120
 Ejercicio
• El alcalde enrique peñalego quiere construir si
ciudad. En esta ciudad su visión es reunir en
armonía el cemento con la naturaleza; por
este motivo ha contratado a la firma del señor
Samuel molego para realizar esta labor. El
alcalde y Samuel acuerdan usar para este
proyecto SCRUM.

121