AGENDA

Introducción 11 Introducción 12 ¿Qué es Agile? 12 Cynefin Framework 12 Manifiesto Ágil 13

Aspectos o Pilares del Manifiesto 13 Principios Detrás del Manifiesto Ágil 14 Principios 14
Declaración de Interdependencia 15 Los 6 Valores Declaración de Interdependencia 15
¿Qué es Agilidad? 15 ¿Cómo debemos ver a la Agilidad? 16 Business Agility 16 ¿Por qué
Metodologías Ágiles? 17 Gestión de Proyectos Tradicional 18 Definición de Scrum en el
Tiempo 18 Definición de Scrum en la Guía (2020) 19 Acerca de Scrum 20 Scrum Patterns 20
Teoría de Scrum 22 Empirismo 23 Control de Procesos Empíricos 23 Lean Thinking 24 5 Principios
del Pensamiento Lean 24 Iterativo 24 Tres Pilares de Scrum 25 Transparencia 25 Inspección
25 Adaptación 26 ®

Valores de Scrum 27 P

Valores de Scrum 28 S

Compromiso 28 T

Enfoque 28 I

Apertura 28 R

Respeto 29 C

Coraje 29 A

Valores de Scrum 29 O

Scrum Team 30 E

Scrum Team 31 O

Auto-gestionados Sobre Auto-organizados 31

R

Scrum Team 32 T

Desarrolladores (Developers) 33 M

Habilidades de los Desarrolladores 33 M

Responsabilidad de los Desarrolladores 33 R

9
Características de Agile Teams 34 Product Owner 34 Características de Product Owner 34
Responsabilidades de un Product Owner 35 Scrum Master 36 Stakeholders 37
Eventos de Scrum 38 Eventos Scrum 39 El Sprint 39 Eventos de Scrum 40 El Sprint 41 Sprint
Planning-Planificación de Sprint 44 Sprint Backlog 47 Daily Scrum (Scrum Diario) 48
Aspectos Adicionales - Daily Scrum (Scrum Diario) 49 Revision del Sprint (Sprint Review) 50
La Retrospectiva del Sprint (Sprint Retrospective) 51 Técnicas para Conducir una
 Retrospectiva 52 Las 5 Etapas de una Retrospectiva 52
Artefactos de Scrum 53 Artefactos de Scrum 54 Product Backlog 55 Compromiso: Objetivo del
Producto 56 Sprint Backlog 57 Compromiso: Objetivo del Sprint 58 Incremento 59
Compromiso: Definición de Terminado 59 Prácticas Ágiles 60
Glosario Agile 61 Ventajas de Time-Boxing 62 ®

C
Conceptos Claves 63
P

M
Nivel de Detalle 64
S

T
INVEST 64
A

C
Características: Modelo Invest 65
I

T
Estructura de User Story 64
R

C
Task 66
L

A
¿Cómo está conformada una Task? 66
N

O
Estimación Planning Póker 66
I

S
Kanban 67
E

O
PMV 67
R

P
Velocidad 67
R

T
Scrum de Scrums 68
S

A
Examen SMPC® 69
M

Insignia 69M

10
Introducción
Los proyectos se ven afectados por las limitaciones de tiempo, costo, alcance, calidad, recursos,
capacidades organizativas y otras limitaciones que los hacen difíciles de planificar, ejecutar,
administrar y finalmente tener éxito.

¿Qué es Agile?
Ágil es la capacidad de crear y responder al cambio. Es una forma de lidiar y, en última instancia,
tener éxito en un entorno incierto y turbulento.

Los autores del Manifiesto Ágil eligieron “Ágil” como la etiqueta para toda esta idea porque esa
palabra representaba la capacidad de adaptación y la respuesta al cambio que era tan importante
para su enfoque.
 Fuente: https://www.agilealliance.org/agile101/agile-glossary/

Cynefin Framework

M
Autor: Dave Snowden
U

R
Basado en https://www.youtube.com/watch?v=N7oz366X0-8
C

12
Manifiesto Ágil

El manifiesto Ágil surge el 17 de febrero del

2001, cuando se reunieron diecisiete críticos del
desarrollo de software, y acuñaron el término
“metodología Ágil” para definir los métodos
que estaban surgiendo como alternativa a las
metodologías formales.
El manifiesto Ágil está conformado por 12
principios asociados a 4 aspectos o pilares.

Fuente: https://www.agilealliance.org/manifesto
download/

Aspectos o Pilares del Manifiesto

• A los individuos y su interacción, por encima de los procesos y las
herramientas • El software que funciona, por encima de la documentación
detallada
• La colaboración con el cliente, por encima de la negociación contractual
• La respuesta al cambio, por encima del seguimiento de un plan

13
Principios Detrás del Manifiesto Ágil

La mayor prioridad es satisfacer al

cliente a través de la entrega temprana
y continua de software útil.
Bienvenidos los cambios a los
requerimientos, incluso los tardíos.
 Liberar frecuentemente software funcionando,
desde un par de semanas a un par de meses, con
preferencia por los periodos más cortos.

Los responsables del negocio y los

desarrolladores deben trabajar juntos
diariamente durante el proyecto.

Construir los proyectos alrededor de individuos

motivados. Proporcionar el ambiente y el
soporte que necesiten, y confiar en que
conseguirán realizar el trabajo.

La conversación directa es el método más

eficiente y efectivo de transmitir información,
tanto al equipo como dentro de éste.

Principios

El software funcionando es la medida

de progreso. Los procesos ágiles
®
promueven el desarrollo
C

M
sostenible.
S

La atención continua a la excelencia

A
técnica y al
C

F
buen diseño incrementan la agilidad.
I

La simplicidad - el arte de maximizar la

L
cantidad
A

N
de trabajo no hecho - es esencial.
O

F
Las mejores arquitecturas, requerimientos y
O

P
diseños emergen de los equipos auto-organizados.
R

En intervalos regulares, el equipo reflexiona

sobre A

cómo volverse más efectivo, entonces afina y

M

R
ajusta su comportamiento como corresponde.
C

14
Declaración de Interdependencia

La Declaración de Interdependencia en la gestión de proyectos fue escrita a principios del 2005 por
un grupo de 15 líderes de proyectos como un suplemento al “Manifiesto Ágil”.

Enumera seis valores de gestión necesarios para reforzar una mentalidad de desarrollo ágil,
particularmente en la gestión de proyectos complejos e inciertos.
Los 6 Valores Declaración de Interdependencia
1. Aumentamos el retorno de inversión, al enfocarnos en el flujo continuo de valor 2. Ofrecemos
resultados fiables mediante la participación del cliente en las iteraciones frecuentes, donde
también son responsables por el trabajo
3. Asumimos que habrá incertidumbre y las superamos a través de iteraciones, anticipación y
adaptación
4. Damos rienda suelta a la creatividad y la innovación al reconocer que las personas son la fuente
máxima de valor y creamos un entorno en el que puedan tener un impacto positivo 5. Aumentamos
el rendimiento a través de la rendición de cuentas por parte del grupo en cuestión de resultados y
eficacia del equipo, responsabilidades que todos comparten
6. Mejoramos la eficacia y la fiabilidad a través de estrategias situacionalmente específicas,
procesos y prácticas
http://pmdoi.org
[©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug
DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent
McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.]
¿Qué es Agilidad?

Ágil (Agile) M

Un enfoque de gestión de proyectos basado E

en la entrega de requisitos de forma iterativa e A

I
 F

incremental a lo largo del ciclo de vida. I

Desarrollo ágil L

un término genérico específicamente para las O

metodologías de desarrollo de software iterativo. S

Los métodos populares incluyen Scrum, Lean, O

DSDM y eXtreme Programming (XP). P

Fuente: https://www.apm.org.uk/resources/find-a-resource/agile-project-management/glossary/ U

15
¿Cómo debemos ver a la Agilidad?
En cualquier tipo de disciplina de gestión, ser ágil es una cualidad, por lo tanto esto debe ser una
meta que se debe tratar de alcanzar.

La gestión de proyectos Agile especialmente, implica la adaptabilidad durante la creación de un

producto, servicio o cualquier otro resultado.

Business Agility
La agilidad empresarial (Business Agility) es la capacidad de una organización para detectar cambios
interna o externamente y responder en consecuencia para ofrecer valor a sus clientes.

La agilidad empresarial no es una metodología específica ni siquiera un marco general. Es una

descripción de cómo opera una organización al incorporar un tipo específico de mentalidad de
crecimiento que es muy similar a la mentalidad ágil.

La agilidad empresarial es apropiada para cualquier organización que enfrente incertidumbre y

cambios rápidos.

La agilidad empresarial valora:

• Las personas y sus interacciones
• La colaboración
• La conducción hacia los resultados
• El aprendizaje constante

Los principios que sirven a la base de la agilidad empresarial incluyen iterar para aprender y
reflexionar sobre los comentarios y adaptar tanto el producto como el proceso.
®
C
Fuente: https://www.agilealliance.org/glossary/business-agility
P

16
¿Por qué Metodologías Ágiles?
• El 70 % de las empresas encuestadas se
encuentra actualmente en un proceso de
transformación Agile
• Las tres razones principales para adoptar
prácticas ágiles en el equipo u organización
son agilizar la entrega de productos o servicios
(14%), mejorar la alineación entre el negocio
y el departamento de TI (12%), y aumentar la
productividad (10%)

Fuente: Agile Adoption Report 2021

https://certiprof.com/pages/certiprof-agile
adoption-report-2021
¿Qué enfoques o metodologías aplica principalmente en su entorno de TI actualmente?

50% 28% 16% 6%

Agile ITIL Normas ISO DevOps
 ¿Con qué marco Ágil está usted más relacionado?
®

7%
6%
S

24% A

45% A

3% N

4% O

XP
S

Otro
A

5%
5% M

Desarrollo 1% Iterativo
UR

No sabe
CS

TS

17
Gestión de Proyectos Tradicional

Ventajas: Orden lógico.

Desventaja: Asume predictibilidad.

Definición de Scrum en el Tiempo

®

18
• Scrum fue desarrollado inicialmente para gestionar y desarrollar productos
• Fue desarrollado a principios de los años 90

Scrum está siendo adoptado por diferentes industrias, en varios modelos de negocios:
Redes de
funciones
interactivas
Desarrollar Vehículos
software Hardware autónomos
Software embebido

Escuelas

Gobiernos
 Gestionar la
operación de
organizaciones

Mercadeo

Scrum es efectivo en la transferencia iterativa e incremental de conocimiento.

Scrum se usa ahora ampliamente para productos, servicios y gestión de la organización

matriz. Definición de Scrum en la Guía (2020)

Scrum requiere un Scrum Master para fomentar un entorno donde:

• Un Product Owner ordena el trabajo de un problema complejo en un Product Backlog • El

Scrum Team convierte una selección del trabajo en un Incremento de valor durante un Sprint • El
Scrum Team y sus interesados inspeccionan los resultados y se adaptan para el próximo Sprint •
Repita

Pruébelo como está y determine si su filosofía, teoría y estructura ayudan a lograr objetivos y crear
v
a
l
o
r
.
®

El marco de trabajo Scrum es incompleto de manera intencional, solo define las partes necesarias para M

implementar la teoría de Scrum. E

En este marco de trabajo pueden emplearse varios procesos, técnicas y métodos. I

Scrum envuelve las prácticas existentes o las hace innecesarias. L

Scrum hace visible la eficacia relativa de las técnicas actuales de gestión, entorno y trabajo, de modo S

que se puedan realizar mejoras. F

S
 19
• Scrum es gratuito
• El marco de Scrum es inmutable
• Aunque la implementación de sólo algunas partes de Scrum es posible, el resultado final no es
Scrum • Scrum sólo existe en su totalidad y funciona bien como un contenedor para otras técnicas,
metodologías y prácticas

Acerca de Scrum
La definición de Scrum se encuentra en La Guía de Scrum.

Omitir elementos de Scrum, no seguir las reglas de Scrum, cambiar el diseño o las ideas esenciales
de Scrum, oculta los problemas y limita los beneficios de Scrum, e incluso potencialmente lo vuelve
inútil.

A medida que se utiliza Scrum, se pueden encontrar, aplicar y diseñar patrones, procesos y enfoques
que se ajusten al marco de trabajo.

Scrum Patterns

Proporcionan orientación a los Scrum Masters

y a los profesionales sobre dónde concentrarse
para obtener el mayor valor de las mejoras, pero
no proporcionan un manual de instrucciones para
seguir sin pensar.

Jim Coplien, co-author of Organizational Patterns of

Agile Software Development

U
R

20

Fuente: http://scrumbook.org

R
 C

21

Teoría de Scrum
Empirismo
• El empirismo se basa en tomar decisiones basados en la información concreta obtenida de la
observación que muestra el progreso del desarrollo de producto, los cambios en el mercado y los
comentarios de los cliente
• El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con
base en lo observado
• Se implementa un proceso empírico en el que el progreso se basa en la observación y la
experimentación en lugar de en los detalles.
• Lo contrario al empirismo es usar planificación previa, procesos definidos, planes predictivos,
hechos no concretos

Control de Procesos Empíricos

El Control de Procesos Empíricos tiene las siguientes características:

• Aprende a medida que avanzamos

• Esperar y aceptar el cambio
®

• Inspeccionar y adaptar usando ciclos cortos de desarrollo

C

• Las estimaciones son sólo indicativas y pueden no ser exactas

M

Scrum combina cuatro eventos formales para inspección y adaptación. C

Estos eventos funcionan porque implementan los pilares empíricos de Scrum de transparencia, C

inspección y adaptación. A

O
 R

23
Lean Thinking
• Lean Thinking es una metodología de negocios basada en la historia de las técnicas de fabricación
japonesas que se han aplicado en todo el mundo en muchos tipos de industrias. 
• Lean se centra en proporcionar altos niveles de valor al cliente mediante la mejora continua de los
procesos empresariales.
• Lean tiene sus raíces en la industria manufacturera de automóviles, particularmente en el Sistema
de Producción Toyota. La compañía japonesa fue capaz de crear un ecosistema sostenible para el
trabajo, donde son capaces de minimizar sus costos, asegurar la eficiencia en sus procesos y
vender sus productos a un precio competitivo.
• Los dos pilares de Lean proporcionan los fundamentos necesarios para desarrollar el Lean
Thinking. Estos son la Mejora Continua y el Respeto por las Personas.

5 Principios del Pensamiento Lean

1. Definir Valor
2. Mapear el Flujo de Valor
3. Crear Flujo
4. Establecer Pull
5. Perseguir la Perfección

Iterativo
Scrum emplea un enfoque iterativo e Incremental para optimizar la previsibilidady controlar el riesgo.

F
O

24
Tres Pilares de Scrum

• Transparencia
• Inspección
• Adaptación

Transparencia
El proceso y el trabajo emergentes deben ser
visibles tanto para quienes realizan el trabajo
como para quienes lo reciben.

Con Scrum, las decisiones importantes se basan

en el estado percibido de sus tres artefactos
formales.

Si los artefactos tienen poca transparencia

pueden llevar a tomar decisiones que disminuyan
el valor y aumenten el riesgo.

La transparencia permite la inspección: La

inspección sin transparencia es engañosa y
derrochadora.
Inspección
Los artefactos de Scrum y el progreso hacia
los objetivos acordados deben
inspeccionarse
con frecuencia y con diligencia para
detectar ®

variaciones o problemas potencialmente C

indeseables. M

Para ayudar con la inspección, Scrum

proporciona C

I
 cadencia en forma de sus cinco eventos.    T

La inspección permite la adaptación. A

La inspección sin adaptación se considera inútil. E

Los eventos Scrum están diseñados para provocar R

cambios. T

25
Adaptación

Si algún aspecto de un proceso se desvía fuera de

los límites aceptables o si el producto resultante
es inaceptable, el proceso que se aplica o los
materiales que se producen deben ajustarse.

El ajuste debe realizarse lo antes posible para

minimizar una mayor desviación.   

La adaptación se vuelve más difícil cuando las

personas involucradas no están empoderadas ni
se autogestionan.

Se espera que un Scrum Team se adapte en el

momento en que aprenda algo nuevo a través de
la inspección.

P
M

26

Valores de Scrum
Valores de Scrum

El uso exitoso de Scrum depende de que las personas sean más competentes en vivir cinco

valores:
• Compromiso
En el resultado, en el logro de los objetivos.
• Enfoque
En el Sprint, en el Product goal.
La focalización es esencial para conseguir que se haga algo que sea significativo.
• Apertura (Openness)
Se requiere transparencia, apertura al dar a conocer la organización, el trabajo, el progreso, el
aprendizaje y los problemas.
• Respeto
 Los miembros del equipo Scrum demuestran respeto entre sí, respeten las ideas de cada uno, se den
permiso para tener un mal día de vez en cuando, y reconozcan los logros de cada uno. • Coraje
®
Es fundamental para el éxito de un equipo.
C

M
Hacer las cosas correctas, trabajar a través de los problemas.
S

Mejorar constantemente.
E

F
Compromiso
I

L
El equipo de Scrum se compromete a lograr sus objetivos y apoyarse mutuamente.
A

S
Enfoque
S

P
Su enfoque principal es el trabajo del Sprint para hacer el mejor progreso posible hacia estos objetivos.
R

S
Apertura
A

U
El equipo de Scrum y sus partes interesadas están abiertos sobre el trabajo y los desafíos.
R

28
Respeto
Los miembros del equipo de Scrum se respetan mutuamente para ser personas capaces e
independientes, y son respetados como tales por las personas con las que trabajan.

Coraje
Los miembros del equipo de Scrum tienen el valor de hacer lo correcto y de trabajar en problemas
complejos.
Valores de Scrum
Los valores dan dirección al Equipo. Guían el Equipo.

Con respecto a

su trabajo Acciones Comportamiento

Las decisiones que se tomen, los pasos que se den y la forma en que se use Scrum deben reforzar
estos valores, no disminuirlos ni socavarlos.

Los miembros del Scrum Team aprenden y exploran los valores mientras trabajan con los eventos y
artefactos Scrum.

Cuando el Scrum Team y las personas con las que trabajan incorporan estos valores, los pilares
empíricos de Scrum de transparencia, inspección y adaptación cobran vida y generan confianza.

29

Scrum Team
Scrum Team

La unidad fundamental de Scrum es un pequeño

equipo de personas, un Scrum Team.

El Scrum Team consta de un Scrum Master, un

Product Owner y Developers. Dentro de un
Scrum Team, no hay subequipos ni jerarquías.

Es una unidad cohesionada de profesionales

enfocados en un objetivo a la vez, el Objetivo del
Producto.
 Los equipos de Scrum (Scrum Teams) son
multifuncionales, lo que significa que los
miembros tienen todas las habilidades necesarias
para crear valor en cada Sprint.

Los equipos de Scrum (Scrum Teams) son

autogestionados, lo que significa que
internamente deciden quién hace qué, cuándo y
cómo.

Auto-gestionados Sobre Auto-organizados

Equipos Auto-organizados eligen la mejor manera S

de realizar su trabajo, en lugar de ser dirigidos por T

otros fuera del equipo. - Scrum guide 2017. F

Auto-gestionados, lo que significa que

L

internamente deciden quién hace qué, cuándo y N

cómo. S

Traditional, self-managing and self- designing/ R

organising teams, self-governing (Hackman, The R

T
 design of work teams, 1987, p. 334). S

31
Scrum Team

El Scrum Team es lo suficientemente pequeño

como para seguir siendo ágil y lo suficientemente
grande como para completar un trabajo
significativo dentro de un Sprint, generalmente
10 personas o menos.

En general, hemos descubierto que los equipos

más pequeños se comunican mejor y son más
productivos.

• Scrum Teams demasiado grandes deberían

considerar reorganizarse en múltiples Scrum
Teams cohesivos (cohesionados), cada uno
enfocado en el mismo producto

• Múltiples Scrum Teams deben compartir el

mismo Objetivo del Producto, el Product
Backlog y el Product Owner
El Scrum Team es responsable de todas las actividades relacionadas con el producto:

• La colaboración de los interesados

• La verificación
• El mantenimiento
• La operación
• La experimentación
®

• La investigación y el desarrollo
C

• Cualquier otra cosa que pueda ser necesaria

M

I
Estructurados y empoderados por la organización para gestionar su propio trabajo.
F

T
Trabajar en Sprints a un ritmo sostenible mejora el enfoque y la consistencia del Scrum Team.
R

C
Todo el equipo de Scrum (Scrum Team) es responsable de crear un incremento valioso y útil en cada
L

A
Sprint.
N

E
Scrum define tres responsabilidades específicas dentro del equipo de Scrum:
F

• Los desarrolladores (Developers)

R

• El propietario del producto (Product Owner)

S

• Scrum Master
M

32
Desarrolladores (Developers)

Los desarrolladores son las personas del equipo Scrum que se comprometen a crear cualquier
aspecto de un Incremento útil (funcional) en cada Sprint.

Habilidades de los Desarrolladores

Las habilidades específicas que necesitan los Developers suelen ser amplias y variarán según el
ámbito (dominio) de trabajo.

Responsabilidad de los Desarrolladores

• Crear un plan para el Sprint, el Sprint Backlog
• Inculcar calidad al adherirse a una Definición de Terminado
• Adaptar su plan cada día hacia el Objetivo del Sprint
• Responsabilizarse mutuamente como profesionales

T
 R

33
Características de Agile Teams

Product Owner

• El Product Owner (PO) representa la voz del cliente, y es el encargado de maximizar el valor del
producto
®

• Un PO siempre debe mantener la visión de las partes interesadas

C

• El debe entender y apoyar las necesidades e intereses de todos los Stakeholders

M

A
C
Características de Product Owner
I

E
El Product Owner no es un comité, es una persona.
C

34
Responsabilidades de un Product Owner
• Maximizar el valor del producto
• Gestión efectiva del Product Backlog
• El Product Owner puede delegar
• El Product Owner sigue siendo el responsable aunque delegue

La gestión efectiva del Product Backlog que incluye:

• Desarrollar y comunicar explícitamente el Objetivo del Producto

• Crear y comunicar claramente los elementos del Product Backlog
• Ordenar los elementos del Product Backlog (Decidir)
• Asegurarse de que el Product Backlog sea transparente, visible y se entienda
 ®

P
M

El Product Owner puede representar las necesidades de muchos interesados en el Product Backlog. N

Para ajustar el contenido u orden del Product Backlog se requiere convencer (negociar con criterio) S

con el Product Owner. F

Para que los Product Owners tengan éxito, toda la organización debe respetar sus decisiones. E

Sus decisiones son visibles en el contenido y el orden del Product Backlog, y a través del Incremento
M

inspeccionable en la revisión de Sprint (Sprint Review). U

35
Scrum Master
El Scrum Master es responsable de establecer Scrum como se define en la Guía de Scrum.

El Scrum Master ayuda a todos a comprender la teoría y la práctica de Scrum, tanto dentro del
Scrum Team como de la organización.

El Scrum Master es responsable de lograr la efectividad del Scrum Team.

Apoya al Scrum Team en la mejora de sus prácticas, dentro del marco de trabajo de

Scrum.
 Los Scrum Masters son verdaderos líderes que sirven al Scrum Team y a la organización en general.
®

P
Scrum Master sirve al Scrum Team de varias maneras:
M

• Guiar (Coaching) a los miembros del equipo en ser autogestionados y multifuncionales

S

• Ayudar al Scrum Team a enfocarse en crear Incrementos de alto valor que cumplan con la Definición
T

I
de Terminado
F

• Procurar (Promover) la eliminación de impedimentos para el progreso del Scrum Team

R

• Asegurarse de que todos los eventos de Scrum se lleven a cabo y sean positivos, productivos y se
C

N
mantengan dentro de los límites de tiempo recomendados (timebox)
O

E
El Scrum Master sirve al Product Owner de varias maneras:
F

• Ayuda a encontrar técnicas para una definición efectiva del objetivo de producto y gestión del
R

R
Product Backlog
E

• Ayuda al equipo Scrum a entender la necesidad de elementos del Product Backlog claros y concisos
S

• Ayuda a establecer un planeamiento de producto empírico para un ambiente complejo

M

• Facilita la colaboración de las partes interesadas según se requiera o necesite

U

36
El Scrum Master sirve a la organización de varias maneras:
• Liderar, capacitar y guiar a la organización en su adopción de Scrum
• Planificar y asesorar implementaciones de Scrum dentro de la organización
• Ayudar a los empleados y los interesados a comprender y aplicar un enfoque empírico para el
trabajo complejo
• Eliminar las barreras entre los interesados y los Scrum Teams

Stakeholders S

Una persona, grupo u organización que afecta S

o puede verse afectado por las acciones de una F

organización. R

R
 C

37

Eventos de Scrum

38
Eventos Scrum
• Los Sprints
• Sprint Planning (Planificación del Sprint)
• Daily Scrum (Scrum Diario)
• Sprint Review (Revisión del Sprint)
• Sprint Retrospective (Retrospectiva del Sprint)
 El Sprint
El Sprint es un contenedor para todos los eventos.

Product Backlog

Refinement
M

39
Eventos de Scrum
Cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar los artefactos de Scrum.

Estos eventos están diseñados específicamente para habilitar (permitir) la transparencia requerida
(necesaria).
 Si no se realizan los eventos según lo prescrito, se pierden oportunidades para inspeccionar y adaptarse.

Los tres pilares de Scrum

Los eventos se utilizan en Scrum para crear regularidad y minimizar la necesidad de reuniones no
definidas en Scrum.

Lo óptimo es que todos los eventos se celebren al mismo tiempo y en el mismo lugar para reducir la
complejidad.

40
El Sprint

Los Sprints son el corazón de Scrum, donde las ideas se convierten en valor.

Son eventos de duración fija de un mes o menos para crear consistencia.

 ®

Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior. M

41
Todo el trabajo necesario para alcanzar el objetivo del producto, incluyendo la Planificación (Sprint
Planning), Daily Scrums, Revisión del Sprint (Sprint Review ) y la Retrospectiva (Sprint
Retrospective),
ocurren dentro del
Sprints.
 Product Backlog
Refinement

Durante el Sprint:

• No se realizan cambios que pongan en peligro el Objetivo del Sprint

• La calidad no disminuye
• El Product Backlog se refina según sea necesario
• El alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende más

Los Sprints permiten la previsibilidad al garantizar la inspección y adaptación del progreso hacia un
Objetivo del Producto al menos cada mes calendario.
®

P
Los tres pilares de Scrum
M

R
E

42
Cuando el horizonte de un Sprint es demasiado largo, el Objetivo del Sprint puede volverse
inválido, la complejidad puede crecer y el riesgo puede aumentar.

Se pueden emplear Sprints más cortos para generar más ciclos de aprendizaje y limitar el riesgo de
costo y esfuerzo a un período de tiempo menor.

Cada Sprint puede considerarse un proyecto corto.

Existen varias prácticas para pronosticar el progreso, como gráficos de burn-downs, burn-ups, o
flujos acumulativos.

Si bien han demostrado ser útiles, estos no sustituyen la importancia del empirismo. En entornos
complejos, se desconoce lo que sucederá. Solo lo que ya ha sucedido se puede utilizar para la toma
de decisiones con vistas a futuro.

Un Sprint podría cancelarse si el Objetivo del Sprint se vuelve obsoleto.

Solo el Product Owner tiene la autoridad para cancelar el Sprint.

E
 T

43
Sprint Planning-Planificación de Sprint
La Sprint Planning inicia el Sprint al establecer el trabajo que se realizará para el Sprint.

El Scrum Team crea este plan resultante mediante trabajo colaborativo.

T
S

44
El Product Owner se asegura de que los asistentes estén preparados para discutir los elementos
más importantes del Product Backlog y cómo se relacionan con el Objetivo del Producto.

El Scrum Team también puede invitar a otras personas a asistir a la Sprint Planning para brindar
(proporcionar) asesoramiento.

La planificación del Sprint aborda los siguientes temas:

Tema Uno: ¿Por qué este Sprint es valioso?

Tema dos: ¿Qué se puede hacer en este Sprint? ®

Tema tres: ¿Cómo se realizará el trabajo elegido? T

R
 P

45
Tema Uno: ¿Por qué este Sprint es valioso?
• El Product Owner propone cómo el producto podría Incrementar su valor y utilidad en el Sprint
actual
• A continuación, todo el Scrum Team colabora para definir un objetivo de Sprint que comunique por
qué el Sprint es valioso para las partes interesadas
• El Objetivo del Sprint debe completarse (finalizarse) antes de que termine la Sprint Planning

Tema
dos: ¿Qué se puede hacer en este Sprint?
• A través de una conversación (discussion en Inglés) con el propietario del producto (Product
Owner), los desarrolladores seleccionan los elementos del Product Backlog para incluir en el Sprint
actual • El equipo de Scrum puede refinar estos elementos durante este proceso, lo que aumenta la
comprensión y confianza
• Seleccionar cuánto se puede completar dentro de un Sprint puede ser un desafío • Cuanto más
sepan los Developers sobre su desempeño pasado, su capacidad actual (upcoming capacity en Inglés) y su
Definición de Terminado, más confiados estarán en sus pronósticos para el ®

C
Sprint
P

T
Planeación del Sprint
RE

C
• Diferentes tipos de importación de
LA Backlog • Post-its digitales
• Post-its digitales
N

• Plantilas pre-diseñadas • Software de

• Plantillas pre-diseñadas • Tags
OI

S simulación de tableros de Scrum

Refinamiento de Backlog
S
• Compartir pantalla Backlog
Refinement
E

F
• Software de simulación de

tableros de Scrum
O

R
P

Fuente: https://miro.com/blog/resources/visual-collaboration-agile-development
M

U
guide/product-backlog/
R

46
Tema tres: ¿Cómo se realizará el trabajo elegido?
• Para cada elemento del Product Backlog seleccionado, los Developers planifican el trabajo
necesario para crear un Incremento que cumpla con la Definición de Terminado
• Normalmente esto se hace descomponiendo los elementos del Product Backlog en elementos de
trabajo más pequeños de un día o menos
• La forma de hacerlo queda a criterio exclusivo de los Developers. Nadie más les dice cómo
convertir los elementos del Product Backlog en Incrementos de valor

Sprint Backlog
El Objetivo del Sprint (Sprint Goal), los elementos del Product Backlog seleccionados para el Sprint,
más el plan para entregarlos se denominan juntos Sprint Backlog.
®

E
 F

47

La Sprint Planning tiene un límite de

tiempo de
máximo ocho horas (timeboxed) para un
Sprint de
un mes.

Para Sprints más cortos, el evento suele

ser de
menor duración.

Daily Scrum (Scrum Diario)

El propósito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el
Sprint Backlog según sea necesario, ajustando el próximo trabajo planeado.

El Daily Scrum es un evento de 15 minutos (máximo) para los desarrolladores del equipo de

Scrum. El Daily Scrum no es la única vez que los desarrolladores pueden ajustar su plan.

Frecuentemente se reúnen durante todo el día para debatir (discusiones) de forma más detalladas
sobre la adaptación o volver a planificar del resto del trabajo del Sprint.

P
Los tres pilares de Scrum
M

L
A

48
Para reducir la complejidad, se lleva a cabo a la misma hora y en el mismo lugar todos los días
hábiles del Sprint.

Si el Product Owner o Scrum Master están trabajando activamente en elementos del Sprint
Backlog, participan como Developers.

Los Developers pueden seleccionar la estructura y las técnicas que deseen, siempre que su Daily
Scrum se centre en el progreso hacia el Objetivo del Sprint y produzca un plan viable para el
siguiente día de trabajo.

Esto crea enfoque y mejora la autogestión.

Las Daily Scrums mejoran la comunicación, identifican impedimentos, promueven la toma rápida de
decisiones y, en consecuencia, eliminan la necesidad de otras reuniones.

El Scrum diario no es el único momento en el que los desarrolladores pueden ajustar su plan. A menudo
se reúnen durante el día para discusiones más detalladas sobre cómo adaptar o volver a planificar el
®

resto del trabajo del Sprint. C

Aspectos Adicionales - Daily Scrum (Scrum Diario) E

F
 I

• El equipo se reúne para comunicar y entender

N

los estados S

• Esencial para conocer el progreso continuo y

F

evitar bloqueos R

• No tiene como objetivo reportar progreso

E

49
Revision del Sprint (Sprint Review)
El propósito de la Sprint Review es inspeccionar el resultado del Sprint y determinar futuras adaptaciones.

El Scrum Team presenta los resultados de su trabajo a los interesados clave y se discute el progreso
hacia el Objetivo del Producto.

El Scrum Team y los interesados revisan lo que se logró en el Sprint y lo que ha cambiado en su
entorno. Con base en esta información, los asistentes colaboran sobre qué hacer a continuación.

El Product Backlog también se puede ajustar para satisfacer nuevas oportunidades. La Sprint

Review es una sesión de trabajo y el Scrum Team debe evitar limitarla a una presentación.

La Sprint Review es el penúltimo evento del Sprint y tiene un límite de tiempo de máximo cuatro
horas (timeboxed) para un Sprint de un mes.

Para Sprints más cortos, el evento suele ser de menor duración.

 Los tres pilares de Scrum

res de Scrum
C

I
T

50
La Retrospectiva del Sprint (Sprint Retrospective)

El propósito de la Sprint Retrospective es planificar formas de aumentar la calidad y la efectividad.

El Scrum Team inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones,
los procesos, las herramientas y su Definición de Terminado.

Los elementos inspeccionados suelen variar según el ámbito del trabajo.

Se identifican los supuestos que los llevaron por mal camino y se exploran sus orígenes.

El Scrum Team analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se
resolvieron (o no) esos problemas.

El Scrum Team identifica los cambios más útiles para mejorar su efectividad.

Las mejoras más impactantes se abordan lo antes posible.

Incluso se pueden agregar al Sprint Backlog para el próximo Sprint.

La Sprint Retrospective concluye el Sprint.

Tiene un tiempo limitado a máximo tres horas para un Sprint de un mes.

Para Sprints más cortos, el evento suele ser de menor duración.

Los tres pilares de Scrum ®C

T
 R

51
Técnicas para Conducir una Retrospectiva

• El barco de vela (The

sailboat)
• Las 4L Technique
• La Estrella de Mar
(Starfish)
• Mad-Sad-Glad
• Start-Stops-Continue

Recomendado:

https://www.mural.co/templates/
retrospective

https://www.smartsheet.com/
content/retrospective-templates

Las 5 Etapas de una Retrospectiva

C
P

52

Artefactos de Scrum

M
 U

53
Artefactos de Scrum

• Los artefactos de Scrum representan trabajo o valor

• Están diseñados para maximizar la transparencia de la información clave
• Por lo tanto, todas las personas que los inspeccionan tienen la misma base de adaptación

Los tres pilares de Scrum

Cada artefacto contiene un compromiso para garantizar que proporcione información que mejore la
transparencia y el enfoque frente al cual se pueda medir el progreso:

• Para el Product Backlog, es el Objetivo del Producto

• Para el Sprint Backlog, es el Objetivo del Sprint
• Para el Incremento es la Definición de Terminado

N
Estos compromisos existen
O

S
para reforzar el empirismo y
E

R
los valores de Scrum para el
P

R
E
Scrum Team y sus
T

M
interesados.
M

54
Product Backlog

El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el
producto. Es la única fuente del trabajo realizado por el Scrum Team.

Copyright® 2012, Kenneth S. Rubin and Innolution LLC, All Rights Reserved.
Los elementos del Product Backlog que el Scrum Team puede dar por Terminados dentro de un
Sprint se consideran preparados para ser seleccionados en un evento de Sprint Planning.
• Plantillas pre-diseñadas tableros de Scrum
• Tags
Refinamiento de Backlog
Planeación del Sprint
• Diferentes tipos de
importación de Backlog • Post-its digitales ®

• Plantilas pre-diseñadas •
CP

• Post-its digitales M

Software de simulación de S

E
Backlog • Compartir pantalla
T

Refinement

• Software de
O

simulación de tableros S

A
E

C
F

de Scrum O

I P

I R

T E

R T

E S

C A

M
L

M
N

U
 R S

55

Suelen adquirir este grado de

transparencia tras las actividades
de refinamiento.
El refinamiento del Product
Backlog es el acto de dividir y
definir aún más los elementos del
Product Backlog en elementos
más pequeños y precisos.
Esta es una actividad continua
para agregar detalles, como una
descripción, orden y tamaño.
Los atributos suelen variar según
el ámbito del trabajo.

Los Developers que realizarán el trabajo son responsables del dimensionamiento.

El Product Owner puede influir en los Developers ayudándolos a entender y seleccionar sus
mejores alternativas.

Compromiso: Objetivo del Producto

El Objetivo del Producto describe un estado futuro del producto que puede servir como un
objetivo para que el Scrum Team planifique.

El Objetivo del Producto está en el Product Backlog.

El resto del Product Backlog emerge para definir "qué" cumplirá con el Objetivo del Producto.

Un producto es un vehículo para entregar valor. Tiene un límite claro, personas interesadas
®
conocidas, usuarios o clientes bien definidos.
C

M
Un producto puede ser un servicio, un producto físico o algo más abstracto.
S

C
El Objetivo del Producto es el objetivo a largo plazo del Scrum Team.
I

R
E
Ellos deben cumplir (o abandonar) un objetivo antes de asumir el siguiente.
C

56
Sprint Backlog

El Sprint Backlog se compone de:

1. El Objetivo del Sprint (por qué)
2. El conjunto de elementos del Product Backlog seleccionados para el Sprint
(qué) 3. El plan de acción para entregar el Incremento (cómo)

El Sprint Backlog es un plan realizado por y para los Developers.

Es una imagen muy visible y en tiempo real del trabajo que los Developers planean realizar durante
el Sprint para lograr el Objetivo del Sprint.

R
 E

57

El Sprint Backlog se actualiza a lo largo

del Sprint a medida que se aprende más.

Debe tener suficientes detalles para que

puedan inspeccionar su progreso en la
Daily Scrum.

Compromiso: Objetivo del Sprint

El Objetivo del Sprint es el único propósito del
Sprint.

Si bien el Objetivo del Sprint es un

compromiso de los Developers,
proporciona flexibilidad en términos del
trabajo exacto necesario para lograrlo.

El Objetivo del Sprint también crea

coherencia y enfoque, lo que alienta al
®
Scrum Team a trabajar
C

en conjunto en lugar de en iniciativas

P
separadas.
M

S
E

A
El Objetivo del Sprint se crea durante el evento
C

F
Sprint Planning y se agrega al Sprint Backlog.
I

L
Los Developers que trabajan durante el Sprint,
A

N
tienen en mente el Objetivo del Sprint.
O

F
Si el trabajo resulta ser diferente de lo que
O

R
esperaban, colaboran con el Product Owner para
P

E
negociar el alcance del Sprint Backlog dentro del
T

A
Sprint sin afectar el Objetivo del Sprint.
M

58
Incremento
• Un Incremento es un peldaño concreto hacia el Objetivo del Producto
• Cada Incremento se suma a todos los Incrementos anteriores y se verifica minuciosamente, lo que
garantiza que todos los Incrementos funcionen juntos
• Para proporcionar valor, el Incremento debe ser utilizable
• Se pueden crear múltiples Incrementos dentro de un Sprint
• La suma de los Incrementos se presenta en la Sprint Review apoyando así el
empirismo • Se puede entregar un Incremento a los interesados antes del final del
Sprint
• La Sprint Review nunca debe considerarse una puerta para liberar valor
• El trabajo no puede considerarse parte de un Incremento a menos que cumpla con la Definición de
Terminado
 Compromiso: Definición de Terminado
• La Definición de Terminado es una descripción formal del estado del Incremento cuando cumple
con las medidas de calidad requeridas para el producto
• Incremento
• Un incremento nace en el momento en que un elemento del Product Backlog cumple con la
Definición de Terminado ®

• La Definición de Terminado crea transparencia. (Brinda entendimiento de qué trabajo se terminó) M

• No se publican ni presentan en el Sprint Review elementos del Product Backlog que no cumplen con
E

la Definición de Terminado A

• Los elementos del Product Backlog que no cumplen con la definición de terminado vuelven al
F

Product Backlog para ser considerados en el futuro E

• La Definición de Terminado para un Incremento, puede ser parte de los estándares de la organización.
L

• Si no es un estándar organizacional, el Scrum Team debe crear una Definición de Terminado

N

apropiada para el producto S

Los tres pilares de Scrum M

59
• Todos los Scrum Teams deben seguir la Definición de Terminado
• Los Developers deben adherirse a la Definición de Terminado
• Si hay varios Scrum Teams trabajando juntos en un producto, deben definir y cumplir mutuamente
la misma Definición de Terminado

Prácticas Ágiles
®

M
Fuente: Agile Adoption Report 2021
M

U
https://certiprof.com/pages/certiprof-agile-adoption-report-2021
R

60

Glosario Agile

I
 F

61

Ventajas de Time-Boxing
Time-Boxing es una práctica crítica en Scrum y debe aplicarse con cuidado. Un Time-Boxing
arbitrario puede llevar a la desmotivación del equipo y puede tener como consecuencia la creación
®
de un entorno opresivo, por lo que Time-Boxing debe ser utilizado de manera apropiada.
C

S
Beneficios:
E
T

• Procesos de desarrollo eficiente

A

• Menos gastos generales

F

• Alta velocidad para los equipos

R

• Ayuda a gestionar eficazmente la planificación y ejecución de proyectos

L

62
Conceptos Claves

Épicas
Es una historia de usuario grande que no puede
entregarse como se define en una sola iteración
o es lo suficientemente larga como para
dividirse
en historias de usuario más pequeñas.

User Stories
En consulta con el cliente o propietario del
producto, el equipo divide el trabajo a realizar
en incrementos funcionales llamados "historias
de usuario". Se espera que cada historia de
usuario produzca, una vez implementada,
una contribución al valor del producto en
general, independientemente del orden de
implementación; La fórmula de INVEST captura
estos y otros supuestos sobre la naturaleza de
las
historias de los usuarios.

Task Board
Es un tablero de tareas que se divide en tres columnas con la etiqueta "Tareas pendientes", "En
curso" y "Listo". Se utilizan notas adhesivas o fichas para cada tarea en la que el equipo está
trabajando y se colocan en las columnas que reflejan el estado actual de cada una.
 ®

Fuente: https://www.agilealliance.org/agile101/agile-glossary R

63
INVEST
El acrónimo INVEST ayuda a recordar un conjunto de criterios o lista de verificación ampliamente
aceptados para evaluar la calidad de una historia de usuario. Si la historia no cumple con uno de
estos criterios, es posible que el equipo desee volver a redactarla o incluso considerar una
reescritura (lo que a menudo se traduce en romper físicamente la tarjeta de la historia anterior y
escribir una nueva).

Una buena historia de usuario debería ser:

• “I” ndependent / Independiente (de todas las demás)
• “N” egotiable / Negociable (no es un contrato específico para funciones)
• “V” aluable (o vertical)
• “E” stimable (para una Buena aproximación)
• “S” mall / Pequeña (como para que encaje dentro de una iteración)
• “T” estable / Comprobable (en principio, incluso si aún no hay una prueba para

ello)Nivel de Detalle
®

64
¿Cómo está conformada una característica dada de un Invest
producto de software: clientes,
una User Story?
usuarios, desarrolladores y
Según la fórmula de Ron Jeffries, evaluadores; esta conversación es
una historia de usuario debe estar en gran parte verbal pero a
conformada por las 3 C’s: • Card menudo complementada por
(Tarjeta): Una ficha física (a documentación.
menudo • Confirmación: Se han alcanzado
una nota Post-It), que da forma los objetivos en torno a los cuales
tangible y duradera a lo que de giraba la conversación.
otro modo solo sería una
abstracción. Fuente:
• Conversación: Que tiene lugar en https://www.agilealliance.org/glos
diferentes momentos y lugares sary/ three-cs
durante un proyecto entre las
distintas personas interesadas por Características: Modelo
 ST
Comprobable
Se puede probar y verificar

Sucinta | Pequeña
®

CP

Se puede construir en una S

ET

iteración junto a otras

historias
Estimable CI

E
FI

El equipo se siente seguro al RE

estimar el esfuerzo requerido

C

LA

Negociable
N

OI

SS
EF

N V Valuable | de Valor
Necesaria y de valor para el
producto y los consumidores
A

Se puede reemplazar por R

otra de diferente prioridad

R

Independiente T

I S

No requiere de otra M

R
 C

65
Task
En Scrum se puede definir como el trabajo
técnico que realizan los Desarrolladores para
completar un ítem del Product Backlog.

La mayoría de las tareas se definen como

pequeñas, lo que representa no más de unas
pocas horas de un día.

¿Cómo está conformada una Task?

Características modelo SMART:

S: Specific (Especifico)
M: Measurable (Medible)
A: Achievable (Alcanzable)
R: Relevant (Relevante)
T: Timely (Tiempo)

Estimación Planning Póker

Esta es una de las técnicas más reconocidas
en Scrum, ya que es muy sencilla, divertida y
®
eficaz, donde los desarrolladores estiman.
C

M
Fue definido y nombrado por primera vez por
S

James Grenning en 2002 y más tarde

E
popularizado
T

C
por Mike Cohn.
I

Un enfoque lúdico de la estimación, utilizado

E
por
C

A
muchos equipos ágiles.
N

S
El equipo se reúne en presencia del cliente o
E

O
propietario del producto.
R

E
Alrededor de la mesa, cada miembro del equipo
T

A
sostiene un juego de cartas, con valores numéricos
M

apropiados para la estimación de puntos de una

M
U

R
historia de usuario.
C

66
Kanban
El Método Kanban es un medio para diseñar,
gestionar y mejorar los sistemas de flujo para el
trabajo del conocimiento. El método también
permite a las organizaciones comenzar
con su
flujo de trabajo existente e impulsar un
cambio
evolutivo.

Pueden hacer esto visualizando su flujo

de
trabajo, limitar el trabajo en progreso
(WIP) y
dejar de comenzar y comenzar a terminar.

El método Kanban recibe su nombre del uso de

Kanban - mecanismos de señalización visual para
controlar el trabajo en curso para productos de
trabajo intangibles.

PMV
Un producto mínimo viable (PMV, MVP por sus siglas en inglés) es un concepto de Lean Startup que
enfatiza el impacto del aprendizaje en el desarrollo de nuevos productos.

Eric Ries, definió un PMV como la versión de un nuevo producto que permite a un equipo recopilar
la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo.

Este aprendizaje validado viene en forma de si sus clientes realmente comprarán su producto.

Velocidad ®

Al final de cada iteración, el equipo suma las estimaciones de esfuerzo asociadas con las historias de M

usuario que se completaron durante esa iteración. E

C
 I

Conociendo la velocidad, el equipo puede calcular (o revisar) una estimación de cuánto tiempo tardará T

en completarse el proyecto, basándose en las estimaciones asociadas con las historias de usuario C

restantes y asumiendo que la velocidad en las iteraciones restantes seguirá siendo aproximadamente A

la misma. O

Por lo general, se trata de una predicción precisa, aunque rara vez lo es. O

67
Scrum de Scrums

Una técnica para escalar Scrum a grupos grandes (más de una docena de personas), que consiste en
dividir los grupos en equipos ágiles de 5-10.

Cada scrum diario dentro de un sub-equipo termina designando a un miembro como "embajador"
para participar en una reunión diaria con embajadores de otros equipos, llamada Scrum de Scrums.

El Scrum de Scrums procede de otra manera como una reunión diaria normal, con embajadores
informando finalizaciones, próximos pasos e impedimentos en nombre de los equipos que
representan.

Se espera que la resolución de impedimentos se concentre en los desafíos de coordinación entre los
equipos; Las soluciones pueden implicar acordar interfaces entre equipos, negociar límites de
responsabilidad, etc.

Scrum of Scrum hará un seguimiento de estos elementos a través de una acumulación propia, donde
cada elemento contribuye a mejorar la coordinación entre equipos.

®
C

68
Examen SMPC®
Examen de certificación.

Formato: Selección múltiple

Preguntas: 40
Puntaje de aprobación: 32/40 u 80%
Duración: 60 minutos
Libro abierto: No
Entrega: Este examen está disponible en línea
Supervisado: será a discreción del entrenador/Auto supervisión está disponible
Dos intentos incluidos

SMPC® is a (registered) Trade Mark of CertiProf, LLC. All rights reserved

Insignia
 ®

69