Scrum,

Agilidad en
los proyectos
“SCRUM es el arte de balancear limites
con libertad, para poder ser creativos y
productivos a la vez”
Alan Cymet
Scrum
360
 Presentación – Personal Maps

https://management30.com/practice/personal-maps/
5

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.
6

Triple Restricción

Calidad Restricciones
Alcance Intrínseca Costo, Tiempo, alcance

Costo Tiempo Valor

Calidad Extrínseca

Gestión de Proyectos Tradicional Gestión de Proyectos Ágiles

7

Cambio de Paradigma con Scrum

Scrum fomenta los: Eres trabajador de conocimiento

¿TRABAJADORES DE
CONOCIMIENTO?
Pero en la actualidad seguimos el
mismo modelo mental de antaño:
“El paradigma industrial”
porque “vales” por lo que sabes
Eres trabajador de conocimiento por
tu capacidad de innovación
Eres trabajador de conocimiento
porque no te consideras un
“recurso”
8

Tipos de Proyectos

En el eje horizontal tenemos la

experiencia, nuestro conocimiento
sobre una herramienta, en el eje
vertical se plasma la claridad de
los requerimientos.
9

Limites que tan importante son!!

A partir del caos todo es posible, queremos crear, pero debemos ser productivos.

“La Agilidad lo que hace es canalizar el caos, pero

dentro del canal seguimos teniendo caos, que nos
permite probar, innovar, equivocarnos, este canal
el que nos permita arribar al destino que nos
interesa alcanzar”

SCRUM ES EL ARTE DE BALANCEAR

LIMITES CON LIBERTAD.
 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 a las practicas
que estaban surgiendo como
alternativa a las metodologías
formales.
El manifiesto Ágil está
conformado por 12 principios
asociados a 4 aspectos o pilares.

REF: http://www.agilemanifesto.org/iso/es/
12

Aspectos o Pilares del Manifiesto

Los individuos y su interacción está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.

Aunque hay valor en los elementos de la derecha,

valoramos más los de la izquierda.

1. Individuos e interacciones sobre procesos y herramientas: Aunque los procesos y las

herramientas ayudan a completar con éxito un proyecto, son las personas que se
dedican, participan las que determinar qué procesos y herramientas se han de utilizar e
implementan un proyecto. Lo principal en cualquier proyecto son, por lo tanto, los
individuos, por lo que el énfasis debe estar en ellos y sus interacciones, en lugar de poner
énfasis en procesos e herramientas complicados.

2. Software de buen rendimiento sobre la documentación detallada: Aunque la

documentación es necesaria y útil para cualquier proyecto, muchos equipos se centran
en la recopilación y el registro de las descripciones cualitativas y cuantitativas de los
entregables, cuando el valor real que se le entrega al cliente es en forma de un software
de buen rendimiento. Por lo tanto, el enfoque Agile se encuentra en la entrega de un
software de buen funcionamiento en incrementos a lo largo del ciclo de vida del
producto en lugar de la documentación detallada.

3. Colaboración con el cliente sobre la negociación del contrato: Tradicionalmente, los

clientes han sido vistos como participantes exteriores que están envueltos
principalmente al inicio y al final del ciclo de vida del producto y cuyas relaciones se
basaban en contratos y el cumplimiento de éstos. Agile cree en un enfoque de valor
compartido en el que los clientes son vistos como colaboradores. El equipo de desarrollo
 y el cliente trabajan juntos para evolucionar y desarrollar el proyecto.

4. Responder al cambio en vez de seguir un plan: En el mercado actual en el que los

requisitos del cliente, las tecnologías disponibles, y los patrones de negocio están
cambiando constantemente, es esencial abordar el desarrollo de productos de una
manera adaptativa que permita la incorporación de cambios y los ciclos de vida de
desarrollo de producto de forma rápida, en lugar de enfatizar el concepto de seguir
planes que fueron creados quizás con datos obsoletos
 Principios
I. La mayor prioridad es satisfacer al cliente a
través de la entrega temprana y continua de
software útil.
II. Bienvenidos los cambios a los
requerimientos, incluso los tardíos
III. Liberar frecuentemente software funcionando,
desde un par de semanas a un par de meses,
con preferencia por los periodos más cortos.
IV. Los responsables del negocio y los
desarrolladores deben trabajar juntos
diariamente durante el proyecto.
V. Construir los proyectos alrededor de
individuos motivados. Proporcionar el
ambiente y el soporte que necesiten, y confiar
en que conseguirán realizar el trabajo.
VI. La conversación directa es el método más
eficiente y efectivo de transmitir información,
tanto al equipo como dentro de éste.

I. La mayor prioridad es satisfacer al cliente a través de la entrega temprana y

continua de software útil.
II. Bienvenidos los cambios a los requerimientos, incluso los tardíos
III. Liberar frecuentemente software funcionando, desde un par de semanas a un
par de meses, con preferencia por los periodos más cortos.
IV. Los responsables del negocio y los desarrolladores deben trabajar juntos
diariamente durante el proyecto.
V. Construir los proyectos alrededor de individuos motivados. Proporcionar el
ambiente y el soporte que necesiten, y confiar en que conseguirán realizar el
trabajo.
VI. 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
VII. El software funcionando es la medida de
progreso.
VIII.Los procesos ágiles promueven el
desarrollo sostenible
IX. La atención continua a la excelencia
técnica y al buen diseño incrementan la
agilidad
X. La simplicidad –el arte de maximizar la
cantidad de trabajo no hecho- es esencial.
XI. Las mejores arquitecturas, requerimientos
y diseños emergen de los equipos auto-
organizados.
XII. En intervalos regulares, el equipo
reflexiona sobre cómo volverse más
efectivo, entonces afina y ajusta su
comportamiento como corresponde

VII. El software funcionando es la medida de progreso.

VIII. Los procesos ágiles promueven el desarrollo sostenible
IX. La atención continua a la excelencia técnica y al buen diseño incrementan la
agilidad
X. La simplicidad –el arte de maximizar la cantidad de trabajo no hecho- es
esencial.
XI. Las mejores arquitecturas, requerimientos y diseños emergen de los equipos
auto-organizados.
XII. En intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo,
entonces afina y ajusta su comportamiento como corresponde
15

Declaración de interdependencia DOI

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 a el 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.

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 interacciones
frecuentes, donde también son responsables por el trabajo.
3. Asumimos que habrán 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.
16

Los 6 valores

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 efectividad y la fiabilidad mediante estrategias, procesos y
prácticas especificas para cada situación.

Incrementamos el retorno de la inversión (ROI), al enfocarnos en el flujo continuo

de valor: Habla de dar valor al cliente de forma más continua posible. Mejor
iteraciones de 2 semanas que de 3. Mejor aportaciones diarias que cada 2 semanas.
Lo que necesita de forma más rápida posible desde el momento que lo necesita.

Ofrecemos resultados fiables mediante la participación del cliente donde también

son responsables por el trabajo: El cliente debe formar parte activa del resultado.
Cuando más participe en la definición de producto y en su revisión frecuente mejor
adaptado estará a sus necesidades.

Asumimos que habrá incertidumbre y las superamos a través de iteraciones,

anticipación y adaptación: El mundo es caótico por naturaleza. Lo que es cierto por
la mañana deja de serlo por la tarde. Los procedimientos de trabajo tiene que ser
flexibles y con ciclos cortos para poder seguir dando valor en estas condiciones.

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: Los desarrolladores son los que crean. Cárgalos de estrés en un
entorno de trabajo restringido y obtendrás resultados mediocres. Déjalos que
disfruten con lo que hacen y dales los medios oportunos y crearán grandezas.
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:
No hay equipo más eficiente que aquel que está motivado y se le dan las
herramientas para que ellos mismos hagan su trabajo más rápido y con mejor calidad.

Mejoramos la efectividad y la fiabilidad mediante estrategias, procesos y prácticas

especificas para cada situación: Existen muchas metodologías pero no hay una sola
que funcione para todos los entornos. Hay que probar, medir y adaptar hasta
encontrar el sistema que mejor funcione (mientras funcione).
 ¿Que es Agilidad?

“Agilidad es la capacidad de crear y responder al

cambio con el fin de obtener ganancias en un
entorno empresarial turbulento”

“la agilidad es la capacidad de Equilibrar la

flexibilidad y estabilidad.
19

¿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.

El gran interés por el agilísimo

Los rápidos cambios en la tecnología, las demandas y expectativas del mercado han creado
grandes desafíos en relación a los productos y servicios en desarrollo que usan los modelos
tradicionales de gestión de proyectos.

La agilidad abrió el camino para la conceptualización e implementación de métodos y valores

ágiles en muchas organizaciones. Las practicas de desarrollo Agile atienden las deficiencias
asociadas con los modelos tradicionales de gestión de proyectos para satisfacer las crecientes
demandas ambientales y expectativas que las organizaciones encaran. Dado a que los
modelos tradicionales de gestión de proyectos en general hacen hincapié en una amplia
planificación por adelantada y que se ajustan al plan una vez que se establece, tales modelos
no tuvieron éxito al encarar la realidad de los frecuentes cambios ambientales.

Agile se basa en la planificación de adaptación y en el desarrollo y la entrega iterativa, se

centra principalmente en que las personas hagan el trabajo con eficacia. Aunque las
metodologías adaptivas e incrementales han existido desde la década de 1950, sólo las
metodologías que se ajustan a el Manifiesto Ágil son generalmente consideradas
verdaderamente como "Ágil".
21

Por que metodologías Agiles?

• El 80% de todos los proyectos emplearán

Métodos Ágiles en los próximos años.
(Gartner)

• Proyectos que usan metodologías Agiles

son mas exitosos que los proyectos que
usan metodologías en cascada.
(Standish Group 2010)
Gestión de Proyectos tradicional

Ventajas: Orden Lógico

Desventaja: Asume Predictibilidad
 Percepción del Agilidad a Nivel Mundial

Anexo A00o1
24
25

Barreras de la Agilidad
26

Beneficios de Scrum
Top 5 Técnicas
Herramientas de Gestión
29

¿Que es Scrum?

Scrum es una 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.

¿Qué es Scrum?

Scrum es una de las metodología agiles más populares, “es una metodología 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 garantiza transparencia en la comunicación y crea un ambiente de

responsabilidad colectiva y de progreso continuo. Scrum, está estructurado de tal
manera que es compatible con los productos y el desarrollo de servicio en todo tipo
de industria y en cualquier tipo de proyecto, independiente de su complejidad. Una
fortaleza clave de Scrum radica en el uso de equipos multi-funcionales, auto-
organizados, y con poder de dividir su trabajo en ciclos de trabajo cortos y
concentrados llamados Sprint.
 Proceso iterativo

1 2 3

El ciclo de vida iterativo, se revisa y mejora el producto, en cada iteración se mejora la

calidad del producto, esto no implica añadir funcionalidades al producto pero si
revisión y mejorar.
Re factorizar (Refactoring): Transformación del Software preservado su
comportamiento.
 Proceso Incremental

1 2 3

El ciclo de vida incremental se desarrolla por partes el producto, para después

integrar a mediad que se completa.
 Iterativo e incremental

Ciclo de vida iterativo e incremental

Al final de cada Sprint o Iteración se consigue una versión mas estable del producto,
con calidad y añadiendo además mas funcionalidades con respecto a las versiones
anteriores.
Los Sprint se pueden conocer como mini proyectos, en todas los sprint se repite un
“proceso” de trabajo similar (planeación, construcción, sincronización, entrega y
retrospectiva), con el objetivo de proporcionar un resultado completo para el
producto final pero siempre teniendo encuenta que el Stakeholder debe obtener
beneficios del proyecto de forma incremental.
En cada Sprint el equipo evoluciona el producto a partir de los resultados
completados en las iteraciones anteriores, añadiendo nuevos objetivos, requisitos o
mejorando los que ya fueron completados.
Mínimo producto viables (MVP)

“Es la versión de un nuevo producto que

permite a un equipo recolectar la máxima
cantidad de APRENDIZAJE validado sobre
clientes al menor coste.” Eric Ries

“Un producto con el MÍNIMO de

CARACTERÍSTICAS necesarias para lograr un
objetivo específico y que los clientes estén
dispuestos a pagar de alguna forma con un
recurso escaso.” Brant Cooper
 MVP

• Un MVP permite aprender sobre los clientes.

• Un MVP permite aprender y cambiar de dirección si
es necesario.
MVP
36

Control de Proceso Empírico

Empirismo

El empirismo asegura que el conocimiento procede de la experiencia y de tomar

decisiones basándose en lo que se conoce.

Scrum se base en la observacion y la experimentacion, mas que en la planeacion

inicial detallada (no se quiere pretender definir que nos basemos en ensayo y error).
 Transparencia

Los aspectos significativos del proyecto deben ser visibles para aquellos que
son responsables del resultado.
La transparencia requiere que dichos aspectos sean definidos por un estándar
común, de tal modo que los observadores compartan un entendimiento común
de lo que se está viendo.
Donde vemos reflejada la transparencia:

• En la declaración de la visión del proyecto que puede ser visto por todos los
Stakeholders y el Scrum Team
• El Product Backlog que pueden ser visto por todos, tanto dentro como fuera del
Scrum Team
• Clara visibilidad sobre el progreso del equipo a través del uso de un Scrumboard,
Burndown Chart y otros radiadores de información
• Durante el Daily Scrum en el que todos los Development Team informan lo que
han hecho el día anterior, lo que van a hacer hoy, y cualquier problema que les
impida completar sus tareas en el Sprint actual
• Sprint Review en el que el Development Team le muestra los entregables al
Product Owner y a los Stakeholders
 Inspección

Se deben inspeccionar frecuentemente los artefactos de Scrum y el progreso

hacia un objetivo, para detectar variaciones. Su inspección no debe ser tan
frecuente como para que interfiera en el trabajo. Las inspecciones son más
beneficiosas cuando se realizan de forma diligente por inspectores expertos, en el
mismo lugar de trabajo.
Donde se ve la inspección

• El uso de un Scrum board y otros radiadores de información que muestran el

progreso del Development Team en completar las tareas del Sprint actual.
• La retroalimentación del cliente y otros Stakeholders durante la creación de las
Epic, la Prioritized Product Backlog.
• inspección y la aprobación de los entregables por el Product Owner y el cliente en
la ceremonia del Sprint Review.
 Adaptación

La Adaptación sucede cuando el Equipo Principal de Scrum y los Stakeholders

aprenden a través de la transparencia y la inspección y luego se adaptan al
hacer mejoras en el trabajo ya en progreso.
Donde se ve reflejada la adpatacion:

• En Daily Scrum, los miembros del Development Team discuten abiertamente los
impedimentos para completar sus tareas y buscar la ayuda de otros miembros del
equipo. Los miembros con más experiencia en el Development Team sirven como
mentores a aquellos quienes tienen relativamente menos experiencia y
conocimiento del proyecto o de tecnología.
• La identificación de los riesgos se lleva a cabo y se reitera a lo largo del proyecto.
• En la Retrospect, los participantes documentan las lecciones aprendidas y realizan
revisiones en busca de oportunidades para mejorar los procesos y abordar las
ineficiencias.
43

Valores de Scrum

Para trabajar con Scrum se necesita una base firme de valores que sirven como
“lineamentos” para el trabajo en equipo

Foco: Porque nos enfocamos en solo una cosa a la vez, trabajamos bien juntos y
producimos un resultado excelente. De este modo logramos entregar ítems valiosos
Coraje: porque no estamos solos, nos sentimos apoyados y tenemos más recursos a
nuestra disposición, esto nos da el coraje para enfrentar desafíos más grandes.
Apertura: durante el trabajo en conjunto expresamos cotidianamente como nos va y
que problema encontramos. Aprendemos que es bueno manifestar las
preocupaciones, para que estas puedan ser tomadas en cuenta.
Compromiso: porque tenemos gran control sobre nuestro destino, ¡¡nos
comprometemos con nuestro destino¡¡.
Respecto: a medida que trabajamos juntos compartiendo éxitos y fracasos, llegamos
a respetarnos los unos a los otros y a ayudamos mutuamente al convertirnos en
merecedores de respeto.
Beneficios de SCRUM
Beneficios de Scrum
 CRONOLOGÍA Historia

El concepto de Scrum tiene su origen en

un estudio de 1986 sobre los nuevos
procesos de desarrollo utilizados en
productos exitosos en Japón y los
Estados Unidos: cámaras de fotos de
Canon, fotocopiadoras de Xerox,
automóviles de Honda, ordenadores de
HP y otros.

Estos equipos seguían patrones de

ejecución de proyecto muy similares. En
este estudio se comparaba la forma de
trabajo de estos equipos altamente
productivos y multidisciplinares con la
colaboración entre los jugadores de
Rugby y su formación de Scrum (melé en
español).

A mediados de la década de los 80, Hirotaka Takeuchi y Ikujiro Nonaka definieron una
estrategia de desarrollo de producto flexible e incluyente en la que el equipo de
desarrollo trabaja como una unidad para alcanzar un objetivo común. Estos
describieron un enfoque innovador para el desarrollo de productos que ellos llaman
un enfoque holístico o "rugby", "donde un equipo intenta llegar hasta el final como
una unidad, pasando el balón hacia atrás y adelante. Takeuchi y Nonaka propusieron
que el desarrollo de productos no debe ser como una carrera de relevos secuencial,
sino que debería ser análogo al del juego de rugby en el que el equipo trabaja en
conjunto, pasando el balón hacia atrás y hacia adelante a medida que se mueve como
una unidad por el campo.

Ken Schwaber y Jeff Sutherland elaboraron sobre el concepto de Scrum y su

aplicabilidad al desarrollo de software, desde entonces, varios practicantes, expertos
y autores de Scrum ha seguido perfeccionando la conceptualización y metodología de
Scrum. En los últimos años, Scrum ha aumentado en popularidad y ahora es la
metodología de desarrollo de proyectos preferida por muchas organizaciones a nivel
mundial.

Estos equipos seguían patrones de ejecución de proyecto muy similares. En este

estudio se comparaba la forma de trabajo de estos equipos altamente productivos y
multidisciplinares con la colaboración entre los jugadores de Rugby y su formación de
Scrum (melé en español).
47

Ciclo de Vida de Scrum

48

Roles… El Cerdo y Pollo

 Roles

✓ Scrum Team
Entender los roles y responsabilidades ✓ Scrum Core Roles
definidos en un proyecto de Scrum es muy ✓ Comprometidos
importante para asegurar la exitosa
implementación de Scrum. ✓ Stakeholder
✓ Implicado
50

Scrum Team – Scrum Core Roles

Son aquellos papeles que obligatoriamente se requieren para producir el

producto o servicios del proyecto.

Estos son tres:

✓ Scrum Master
✓ Development Team
✓ Product Owner

Roles

Son aquellos papeles que obligatoriamente se requieren para producir el producto o

servicios del proyecto.
Las personas a quienes se les asignan los roles principales están plenamente
comprometidas con el proyecto y son las responsables del éxito de cada iteración del
proyecto y del proyecto en su totalidad.

Estos son tres:

• Product Owner
• Scrum Master
• Development Team

Juntos se conocen como el equipo central o principal de Scrum (Scrum Core Team), es
importante tener en cuenta que, de estos tres roles, ningún papel tiene autoridad
sobre los otros.
51

Product Owner

El Product Owner representa la voz del cliente, y es

el encargado de maximizar el valor del producto.
Un PO siempre debe mantener una visión dual.

1. El debe entender y apoyar las necesidades e

intereses de todos los Stakeholders,
2. Comprende las necesidades y el funcionamiento
del Develpment Team.

Es la persona responsable de lograr el máximo valor empresarial para el proyecto. Él también

es responsable de la articulación de requisitos del cliente y de mantener la justificación del
negocio para el proyecto, este representa los intereses de la comunidad de Stakeholders al
Develpment Team, es responsable de asegurar una comunicación clara sobre el producto y
los requisitos funcionales y definir los criterios de aceptación y se asegurar que se cumplan.

El Product Owner siempre debe mantener una visión dual él debe entender y apoyar las
necesidades e intereses de todos los Stakeholders, mientras que comprende las necesidades
y el funcionamiento del Development Team.

El Product Owner es el responsable de asegurar que el Develop Team ofrezca valor.

El Product Owner representa la voz del cliente (voice of the customer-VOC).

52

Resposabilidades del Product Owner

53

Responsabilidades del Product Owner

54

Caracteristicas de un Product Owner

55

Scrum Master

Es un líder servicial, un facilitar, coach su

responsabilidad es asegurar que Scrum sea
entendido y adoptado.
Esta al servicio del Scrum Team, para asegurar
que se este siguiendo con los procesos Scrum
en un ambiente propicio para completar el
proyecto con éxito, y esto incluye Eliminar los
“impedimentos” que encuentra en el equipo.

El Scrum Master es el Servant Learder quien modera y facilita las interacciones del equipo
como entrenador del equipo y motivador.

Es un facilitador que asegura que el Scrum Team esté dotado de un ambiente propicio para
completar el proyecto con éxito. este guía, facilita y les enseña las prácticas de Scrum a todos
los involucrados en el proyecto; elimina los “impedimentos” que encuentra el Development
Team; y asegura que se estén siguiendo los procesos de Scrum.

Tenga en cuenta que el papel del Scrum Master es muy diferente a la función desempeñada
por el director de proyectos en un modelo de cascada tradicional de gestión de proyectos. El
Scrum Master sólo funciona como un facilitador y el esta en el mismo nivel jerárquico que
cualquier otra persona en el Scrum Team, cualquier persona del Scrum Team que aprenda a
facilitar proyectos de Scrum puede convertirse en el Scrum Master de un proyecto o Sprint.
57
58
59
60

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 (Deliverables)
del proyecto.
Solo los miembros del Development participan en
la creación del incremento.

Es importante que el Development Team posea todas las habilidades esenciales

necesarias para llevar a cabo el trabajo del proyecto. También es necesario contar con
un alto nivel de colaboración para maximizar la productividad, por lo que se requiere
una mínima coordinación para hacer las cosas.
61

Tamaño del Development Team

El tamaño óptimo de un Development Team es de tres a nueve

miembros, lo suficientemente grande para asegurar habilidades
adecuadas, pero lo suficientemente pequeño como para colaborar
fácilmente.

El tamaño óptimo de un Development Team es de tres a nueve miembros, lo

suficientemente grande para asegurar habilidades adecuadas, pero lo
suficientemente pequeño como para colaborar fácilmente.

Un beneficio clave de un equipo de tres a nueve miembros es que la comunicación y

la gestión suelen ser simples y requieren un mínimo esfuerzo.

Una desventaja importante es que los equipos más pequeños se ven afectados más
significativamente por la pérdida de un miembro del equipo en comparación a los
equipos más grandes, así esta pérdida sea por un corto tiempo.
62
63
65

Stakeholders

Es un término colectivo que incluye a los clientes, usuarios y

patrocinadores, que con frecuencia interactúan con el Equipo Principal
de Scrum (Scrum Core Team), para proporcionar entradas (inputs) y
facilitar la creación del producto del proyecto, servicios, o cualquier otro
resultado.
66

Stakeholder se divide en:

Cliente: Es el que adquiere el producto del proyecto, servicio o cualquier otro resultado.

Usuarios: Son aquellos que utilizan directamente el producto del proyecto, servicio o
cualquier otro resultado. También en algunas industrias se conocen como clientes o usuarios
pero en realialidad pueden ser lo mismo.

Patrocinador: Es aquel que provee recursos y apoyo para el proyecto, el patrocinador

tambien es el Stakeholder, a quien todos le deben rendir cuentas al final.
67
68

Conceptos Claves en Scrum

Épicas: Es una historia de usuario que es demasiado grande para construir en un sprint, a menudo
este término se utiliza para describir una gran historia de usuario que tendrá que ser dividido en
historias más pequeñas.

User Stories: Es una representación de un requisito del usuario en forma escrita de una o dos
frases, utilizando el lenguaje común del usuario.

Task: Es una representación de el requisito que esta en lenguaje del usuario, pero de una forma
técnica donde esta definido como se va a trabajar y quien van a participar.
69
 Como esta conformada una User Storie

Una historia de usuario debe estar conformada por las 3C: Características:
Modelo INVEST.

Card (tarjeta): Conversación: el Confirmación: sirve

Descripción escrita PO y el DT aclaran para determinar lo que
de lo que necesita el los detalles. se espera.
usuario.

Características: modelo invest.

Independencia: una historia debería ser independiente de otra, esta facilita la

planificación, priorización y estimación
Negociables: la User Stories es tan solo una descripción corta que no incluye detalles,
los detalles se añaden mediante la conversación
Valiosa: cada User Stories debe ser valorada por los Stakeholders
Estimable: el Scrum Team necesita poder estimar una User Stories, las User Stories
demasiado grande o incorrectas, no se pueden estimar
Pequeña: una buena User Stories debe ser pequeña en esfuerzo, debería ser
realizable en menos de una semana
Verificable: una User Stories necesita poder probarse que se ha completado con éxito
Estructura de User Storie
 Task-Tarea

Unidad de trabajo gestionada por los Development. 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 las User Stories son creadas
en lenguaje de usuario”
Como esta conformado una Task

ID:

Responsable:

Descripción:

Estimación:
 Artefactos

Los artefactos en Scrum son herramientas que propone Scrum para mantener organizado un
proyecto, estos son 4:
 Product Backlog

Es uno de los artefactos más esenciales de Scrum, es una lista ordenada de las ideas
para el producto, todo el trabajo que realiza el Development Team proviene del Product
Backlog.
El Product Owner es el responsable Product Backlog, incluyendo el contenido,
disponibilidad y ordenación, aunque puede y debería recibir ayuda para construirlo y
mantenerlo actualizado.

Es uno de los artefactos más esenciales de Scrum, es una lista ordenada de los
requerimientos, ideas para el producto, es la única fuente de requerimiento para
cualquier cambio a realizar, Se trata de una lista de todas las características,
funciones, tecnologías, mejoras y correcciones de errores que constituyen los
cambios que se harán al producto para futuras versiones. Todo el trabajo que realiza
el Scrum Team proviene del Product Backlog.

El Product Owner es responsable de mantener el Product Backlog aunque puede y

debería recibir ayuda para construirlo y mantenerlo actualizado

El Product Backlog nunca se acaba, y el Product Backlog usado en la planificación del

proyecto, es simplemente una estimación inicial de los requisitos. El Product Backlog
se desarrolla paralelamente a medida que el producto y el ambiente en el cual se
trabaja evoluciona. El Product Backlog debe ser dinámico.
77

Ejemplos
78

Definición de DoD
Definición de Terminado

Son los acuerdos del Product Owner con los Stakeholders que contiene todas las condiciones que
deben de cumplir los ítems del Product Backlog para considerar un Sprint completo o finalizado.

Definición de Done
Imaginemos una pareja que acaba de volver del trabajo. El marido decide cocinar
fideos, mientras la mujer ordena la ropa. La mujer pregunta desde la habitación si la
comida está lista el marido responde que no, que en cinco minutos al cabo de un rato
la mujer insiste y el marido orgulloso responde que sí, que la cena está lista.
La mujer se dirige rápidamente a la mesa y encuentra, papeles desordenados y un
vaso medio vacío le pregunta al esposo qué pasa, ni si quiera está hecha la mesa !El
marido ,sorprendido, le contesta que los fideos están listos, lo que significa que la
cena está lista. Ahora resta servirlos en platos, limpiar la mesa ,etc., etc. ¿Quién Tiene
razón? ¡Ambos! ¿Cuál es el problema? Que ambos tienen distintos criterios de hecho.
¿La consecuencia? No solamente el enojo de ambos, si no que las decisiones se
tomaron según el propio criterio de hecho.
 Refinamiento Product Backlog

Es el acto de añadir detalle, estimaciones y orden a los elementos

del Product Backlog. Se trata de un proceso continuo, en el cual el
Product Owner y el Development Team colaboran acerca de los
detalles de los elementos de la Lista de Producto.

El Scrum Team decide Este usualmente consume

cómo y cuándo se hace
el refinamiento.
no más del
10%
de la capacidad del
Equipo de Desarrollo.
 Sprint Backlog

Es la lista de tareas del Product Backlog refinados que han

sido elegidos para ser desarrollados en el Sprint actual.
Generado el Sprint Backlog, comienza el Sprint y el
Development Team implementa el nuevo Incremento de
Producto definido por el Sprint Backlog.

Este se ve representado por medio de las tableros de Scrum.

El Sprint Backlog es una lista de tareas que el Equipo realiza para convertir el
elemento seleccionado del Product Backlog en incremento. El Development Team
modifica el Sprint Backlog a lo largo de todo el Sprint. A medida que se va trabajando
o se terminan tareas, se actualizan las horas de trabajo estimado restante para cada
tarea. Sólo el Development Team puede cambiar su Sprint Backlog durante un Sprint.
81

Ejemplo
 Burn-Down Chart (Product, Sprint)

Un diagrama Burn-Down o diagrama de quemados, es una representación gráfica del trabajo por
hacer en un proyecto o muestra el esfuerzo restante durante un periodo determinado de tiempo.
A este radicado de información se le puede dar dos usos:

Product Burn- Sprint Burn-

Down: Down:
Visión global del Visión concreta para
proyecto, se realiza a cada Sprint, se
partir del Product realiza a partir del
Backlog. Sprint Backlog.
Grafica Burn-Down

En el eje X: la fecha del Sprint

En el eje Y: el esfuerzo
La línea entre ejes: es la velocidad ideal

Grafico Ideal
Este diagrama indica un gran compromiso del equipo para organizarse
y trabajar en equipo. El Scrum master ayuda al Development Team en
los bloqueos del sprint, el Development Team no está demasiado
saturado en tareas y ha terminado sus labores a tiempo, en este caso,
no es necesario ninguna acción correctiva.

Gran equipo
EL grafico muestra el progreso de equipos experimentos. El equipo
cumplió con la meta en el tiempo estipulado, y tienen la posibilidad de
completar algún trabajo adicional.

Buen equipo
El grafico indica que el equipo fue capaz de completar su compromiso
a tiempo. Adaptaron el alcance o trabajaron más duro para completar
el sprint. El equipo debe discutir un cambio de plan, ya que se
evidencia que el progreso ha ido disminuyendo desde el comienzo del
sprint.

.
Es muy tarde
Este diagrama muestra que no se ha completado el
compromiso. El equipo no adapto el alcance al nivel
apropiado, en tal situación la capacidad del próximo sprint
debería ser reducida.

Demasiado temprano
El grafico muestra que el equipo termino el trabajo antes
de lo esperado. Las historias fueron posiblemente
sobreestimadas, tampoco se estimó correctamente la
velocidad del equipo. El scrum master debe ser más
proactivo en conseguir que el equipo fije la estimación
correcta o asegurarse de que las historias adicionales
estén listas para ser agregadas.

Vamos a tomar un descanso

En este grafica se evidencia que existe un problema con el
progreso, el equipo se compromete a menos de lo que son
capaces de completar. El scrum master debería identificar
este problema y pedir al product owner que proporcione
más historias de usuario, incluso si son sobreestimadas el
equipo debe continuar con las historias del próximo sprint.

La dirección está llegando

en la gráfica se indica que el equipo probablemente esta
haciendo algún trabajo, pero talvez no actualiza su
progreso en consecuencia. El scrum master debe entrenar
al equipo sobre porque es necesario seguir el progreso.

Hacer sus deberes

En el grafico se visualiza que el equipo no es funcional en
muchos niveles. El scrum master no ha entrenado al
equipo para seguir el progreso diario. El product owner
tampoco se preocupa por el progreso del desarrollo. El
equipo debe reiniciar desde cero mediante la formación y
hacer una retrospectiva para averiguar porque esta
sucediendo.
 Incremento del producto

Final de cada Sprint se produce un Incremento de

Producto utilizable. Éste debe contar con una calidad lo
suficientemente alta como para ser entregado a usuarios
finales.
El Incremento de Producto debe cumplir con la Definición
de hecho actual del Equipo Scrum y cada parte del mismo
debe ser aceptable para el Product Owner.
 Eventos de Scrum
“Ceremonias o Reuniones”

Para que cualquier proyecto tenga éxito, la comunicación es importante.

Los equipos de Scrum emplean una serie de reuniones clave para estructurar el trabajo del equipo:
Un Sprint es una iteracion que tiene una duracion de una a cuatro semanas durante
el cual el Scrum Master guía, facilita y protege al Scrum Team de impedimentos tanto
internos como externos durante el proceso de creacion de entregables. Esto ayuda a
evitar el arrastramiento, o lentitud, de la visión que podría afectar la meta del Sprint.

Durante este tiempo, el Development Team trabaja para convertir las necesidades del
Prioritized Product Backlog en funcionalidades de productos fáciles de enviar.
88

Cancelación de Sprint

Un Sprint puede ser cancelado antes de que el

bloque de tiempo llegue a su fin, siempre y
cuando el objetivo del Sprint llegara a quedar
obsoleto o no tiene sentido seguir con el Sprint.
Solo el PO tiene la autoridad para cancelar el
Sprint.

Un Sprint puede ser cancelado antes de que el bloque de tiempo llegue a su fin. Solo
el Product Owner tiene la autoridad para cancelar el Sprint, aunque puede hacerlo
bajo la influencia de los interesados, del Development Team o del Scrum Master.

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 dadas las
circunstancias. Pero debido a la corta duración de los Sprints, rara vez la cancelación
tiene sentido.

Cuando se cancela un Sprint, se revisan todos los PBI del Product Backlog que se
hayan completado y “Terminado”. Si una parte del trabajo es potencialmente
entregable, el Dueño de Producto normalmente lo acepta. Todos los PBI no
completados se vuelven a estimar y se vuelven a introducir en el Product Backlog.

Las cancelaciones de Sprint consumen recursos, ya que todos deben reagruparse en

Sprint Planning Meeting para empezar otro Sprint. Las cancelaciones de Sprint son a
menudo traumáticas para todo el Scrum Team y son muy poco comunes.
Esta reunión es atendida por el Product Owner, Scrum Master y el Development
Team, tiene una duracion de ocho (8) horas por un sprint de un mes

Durante la planificación del Sprint (Sprint Planning Meeting), el Product Owner

describe las características de mayor prioridad para el equipo, el Product Owner
viene preparado para la reunión con el Product Backlog organizado y ordenado. Estos
pueden ser en forma de historias de usuario, o simplemente una lista de requisitos.
En ausencia del Product Owner o del Product Backlog, el Scrum Master debe
construir un Product Backlog antes de la reunión y sustituir al Producto Owner,
también es responsabilidad que el Scrum Master se asegure de que el evento se lleve
a cabo y que los asistentes entiendan su propósito, este le enseña al Scrum Team a
mantenerse dentro del bloque de tiempo.

El Sprint Planning Meeting se divide en dos partes:

• ¿Qué puede ser terminado en este Sprint? ¿Cuál es el objetivo?

• ¿Cómo se conseguirá completar el trabajo seleccionado? ¿Cuál es la estimación?
 ¿Qué puede ser terminado?

Esta pregunta nos ayuda para que el Scrum Team trabaje para proyectar la funcionalidad que se
desarrollara durante el Sprint, donde se define objetivo del Sprint (Sprint Goal).
El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del
Development Team.

Definición de Objetivo del Sprint

El objetivo es la primera parte, o las primeras 4 horas, El Scrum Team trabaja para
proyectar la funcionalidad que se desarrollará durante el Sprint, el Development
Team selecciona aquellos elementos del Product Backlog (PBI) que cree que puede
comprometerse a transformar en un incremento potencialmente entregable, el
número de elementos seleccionados del Product Backlog para el Sprint depende
únicamente del Development Team. Durante esta parte de la reunión, no es raro que
el equipo hable y aclare ciertos aspectos con el Product Owner, haciendo preguntas
para alejar la ambigüedad

El Development Team demostrará esta funcionalidad al Product Owner y a los

Stakeholders en el Sprint Review.
91

Sprint Goal
Meta del Sprint

La Meta del Sprint resume el resultado deseado de un Sprint. Proporciona un objetivo

común, e indica por qué vale la pena dar inicio un “desarrollo”.

Como regla general, cada sprint debe tener un objetivo común. Esto asegura que
todo los involucrados se mueve en la misma dirección. Una vez que el objetivo ha
sido seleccionado, el Development Team lo implementara.

Beneficios del Sprint Goal:

✓ Facilita la estimación
✓ Genera enfoque y facilita el trabajo en equipo
✓ Ayuda a obtener una retroalimentación relevante
✓ Hace mas fácil analizar las observaciones
✓ Soporte la comunicación con los Stakeholder
 ¿Cómo se conseguirá completar el trabajo
seleccionado?

Una vez determinado cual es Sprint Goal y

seleccionado los PBI para cumplirlo, los Development
deciden técnicamente como construirán el
incremento del producto, esto hace referencia a la
creación de las Task por parte del Development Team.

Estimación del Trabajo

Una vez que se ha establecido el Sprint Goal y seleccionado los elementos del
Product Backlog para el Sprint, el Development Team decide cómo construirá esta
funcionalidad para formar un Incremento de producto.

Durante la segunda parte de la reunión de planificación del sprint, el equipo decide

cómo se construirá la obra. En esta reunión, el equipo comenzará a descomponer los
elementos del Product Backlog en las tareas de trabajo y la estimación, una de las
técnicas para hacer la estimación que algunos equipos utilizan es el “juego" llamado
"Planning Poker", esta labor es exclusivamente del Development, nadie más tiene
permiso para hacer nada que no sea observar o preguntar para buscar más
información.

Al final de la reunión de planificación de Sprint el equipo habrá desarrollado el Sprint

Backlog, Burn Down chart, estimaciones de tareas y asignaciones que dará comienzo
al trabajo al Development Team para desarrollar la funcionalidad, el Development
Team debería ser capaz de explicar al Product Owner y al Scrum Master cómo
pretende trabajar como un equipo auto organizado para lograr el Objetivo del Sprint
y crear el Incremento esperado.
 Estimación Planning Póker

Esta es una de la técnicas mas reconocida en Scrum, ya que es muy sencilla, divertida y eficaz, donde
los Development estima como grupo el esfuerzo a realizar en el Sprint.

Planning Póker es una técnica de estimación empírica, donde un grupo de expertos

discuten y evalúan el esfuerzo requerido para cada “Actividad” del proyecto.

Consiste en crear una reunión de trabajo con el Scrum Team. Se requiere de un

moderador que dirigirá la actividad (Product Owner). Primero se expone el proyecto
que se va a desarrollar. Luego se determinan las actividades requeridas para ejecutar
el proyecto, y entonces para cada una de las actividades los distintos miembros del
Development Team realizan una estimación empírica y se conjuntan y discuten los
resultados con el fin de cerrar la brecha y converger en un valor estimado para cada
actividad. La información obtenida con la estimación de cada tarea se utiliza para
realizar el plan general del proyecto y conocer el esfuerzo total.

Para esta situación de planificación se utiliza mucho la famosa escala Fibonacci (0, 1,
2, 3, 5, 8, ect.) o también se utiliza la actividad de tamaño de camisetas (XS, S, M, L,
XL), entre más grande es la historia a estimar, menos certeza y precisión tenemos en
la misma, el valor 0 indica que una historia de usuario es muy simple y que puede ser
realizado con un esfuerzo mínimo, el signo de infinito indica que la historia es tan
compleja que no hay manera de saber cuánto se puede tardar en realizar, el signo de
interrogación indica que no es nada clara lo que se va a estimar y por último se
encuentra un signo de un Café que lo que hace referencia es hay que darse un
momento para “respirar”.
 Actividad
Planning
Póker

Antes de empezar con el Planning póker, hay que definir qué unidad se va a utilizar
para medir, esta puede ser horas, días ideales, puntos funcionales, esfuerzo o
cualquier otra métrica, para nuestro ejemplo utilizaremos una métrica llamada
puntos de historia.

1 punto de historia = 1 jornada laboral en dedicación exclusiva

Entonces si una historia de usuario tiene 3 puntos esto significa que un miembro del
equipo se dedica 3 jornadas de trabajo para realizar el trabajo.

Cuando se estima en puntos de historia, lo que se intenta es dar un valor del

TAMAÑO de la historia. ¿Y qué implica Tamaño? Es dimensionar la historia de usuario
desde 3 ángulos distintos:

• Complejidad: No es lo mismo implementar un acta en un formulario que,

por ejemplo, un algoritmo de inteligencia artificial para un juego
• Esfuerzo: ¿Es una tarea que tengo que repetir en muchos sitios? ¿Me va a
llevar mucho tiempo aunque sea una cosa fácil?
• Riesgo: ¿Estamos trabajando con una tecnología desconocida? ¿Tiene la
gente del equipo experiencia en el negocio?
Los puntos de historia (que de ahora en adelante lo abreviaremos PH) son relativos
no absolutos, si a una historia le asignamos 1PH y a otra 3PH esto indica que una es el
triple de la otra nada más, la relatividad también se aplica entre los equipos, es decir
que 3 PH para un equipo no tiene que significar lo misma para el otro.
95

Esto es una reunión diaria de corta duración, Time-boxed a 15 minutos. Los miembros del
equipo se reúnen para informar sobre cómo marcha el proyecto.
respondiendo a las siguientes tres preguntas:

• ¿Qué terminé ayer?

• ¿Qué voy a terminar hoy?
• ¿Qué obstáculos, impedimentos (si los hay), estoy enfrentando en la actualidad?
• Esta ceremonia es como una reunión de sincronización.

Al centrarse en lo que cada persona llevo a cabo ayer y cumplirá hoy, le permite al equipo
obtener una excelente comprensión de que trabajo se ha hecho, y el trabajo que queda por
realizar. La reunión de Scrum diario no es una reunión de actualización de estado en el que
un jefe está recogiendo información sobre quién está detrás de lo programado. Más bien, se
trata de un encuentro en que los miembros del equipo se comprometen entre sí.

Cualquier obstáculo que se plantean en la reunión de Scrum diario se vuelve responsabilidad

del Scrum Master que debe resolver lo más rápido posible, en casos en que el Scrum Master
no puede eliminar estos impedimentos directamente el mismo (por ejemplo, por lo general
las cuestiones más técnicas), tiene la responsabilidad de asegurarse de que alguien en el
equipo resuelva rápidamente el impedimento.
La reunión de Scrum diario no se utiliza como una reunión de resolución de problemas, las
cuestiones que se plantean son tomadas fuera de línea y generalmente son tratadas por el
subgrupo responsable inmediatamente después de la reunión.
 Rompiendo Paradigmas

¿Cuál es el • El Scrum Master se asegura que los Development realicen la

reunión, pero el Development Team es el responsable de dirigir el
papel del
Scrum Diario, el Scrum Master enseña para que esta reunión no
Scrum Master? exceda el Time-Boxing estipulado.

¿Qué pasa con los • En esta ceremonia no se soluciona impedimentos, los Development
impedimentos se vuelven a reunir inmediatamente del Daily para tener discusiones
hallados? detalladas para adaptar, o replanificar el resto del trabajo.
97

Los participantes en el Sprint Review Meeting incluyen típicamente al Scrum Team y

al Stakeholder, tiene una duración de cuatro (4) horas por un Sprint de un mes.
El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes
entiendan su propósito, este enseña a todos a mantener el evento dentro del bloque
de tiempo fijado.

El Sprint Review se evalúan los entregables en contra del objetivo del Sprint
determinado durante la reunión del Sprint Planning Meeting, se inspecciona el
Incremento y adapta el Product Backlog si fuera necesario.

Cabe aclarar que trata de una reunión informal, no una reunión de seguimiento y la
presentación del Incremento tiene como objetivo facilitar la retroalimentación de
información y fomentar la colaboración.

El Sprint Review es valioso para el Development Team, ya que proporciona una

oportunidad para que el Developement Team pueda mostrar sus trabajos
directamente y obtener el reconocimiento de los grupos de interés. La reunión
contribuye a elevar la moral Development Team y mantener al equipo motivado para
tratar de producir cada vez mayores volúmenes de trabajo de calidad.
La Revisión del Sprint brinda a todos los presentes una vista panorámica del
Incremento de Producto. Bajo esta perspectiva, es común actualizar el Product
Backlog como parte de la Revisión del Sprint.
98

Consejos para la celebración de una revisión del sprint ágil

Una de las reglas de Scrum es pasar no más de una hora en una reunión de revisión
del sprint para cada semana del Sprint.

Las directrices para un Sprint Review:

• No hay diapositivas de PowerPoint, se consulta el Sprint Backlog y la lista de User

Story completadas.
• El Product Owner presenta el Sprint Goal, y las nuevas Necesidades incluidas.
• Todo el Scrum Team debe participar en la reunión.
• Cualquiera que esté interesado en la reunión podrá asistir. Los Stakeholder en el
proyecto, el director general todos podrían teóricamente estar en el Sprint Review
Meeting.
• El Development Team demuestra lo que se completó durante el sprint.
Normalmente, el Development Team presenta nuevas características.
• La demostración debe estar lo más cerca posible al entorno de producción.
• El Product Owner puede provocar una discusión sobre lo que viene a continuación
en función de las características que acabamos de presentar y los nuevos
elementos que se han añadido al Product Backlog durante el sprint actual.
99

El propósito de la Retrospectiva del Sprint es reflexionar cómo fue el último Sprint en

cuanto a personas, relaciones, procesos y herramientas, e Identificar las posibles
mejoras; y crear un plan para implementar las mismas.
La retrospectiva del sprint suele ser lo último que se realice en un Sprint. El Scrum
Master, el Product Owner y el Development Team debe participar.
El Sprint Review se centra en “que” está construyendo el Equipo, la Sprint
Retrospective se centra en el “como”. La motivación para realizar esta reunión es
lograr la mejora continua del proceso de desarrollo.

Para reflexionar: “El leñador y el hacha”

“Cuenta la historia, que había una vez un leñador que trabajaba en una maderera,
donde el sueldo era bueno, las condiciones mejores aun. Salió al bosque a talar y en
un solo día corto dieciocho arboles, por tal motivo recibió una gran felicitación de
capataz, animado por estas felicitaciones se propuesto mejorar su marca para el
próximo día, así que esa noche se acostó temprano.
A la mañana siguiente a pesar de todo su empeño solo consiguió contar quince
arboles –Debo estar cansado –pensó, y decidió acostarse con la puesta del sol, al día
siguiente el resultado no fueron quince si no diez arboles talados, y al día siguiente
fueron siete y al siguiente cuatro, muy preocupado e inquieto por lo que dirá el
capataz el leñador fue a contarle la novedad y a jurarle que se estaba esforzando
hasta los limites del desfallecimiento.
El capataz le pregunta -¿Cuándo afilaste tu hacha por ultima vez? -¿Afilarla? No he
tenido tiempo para afilar he estado demasiado ocupado talando arboles”.
“A veces una sola pregunta nos hace reflexionar sobre lo que estamos haciendo y
como lo estamos haciendo”.
 Las 5 Etapas de una Retrospectiva

Preparación del escenario:

El inicio de la retrospectiva ocurre con la "Preparación del escenario” en esta etapa se
deberá:
• Armar la agenda y las actividades para cada etapa de la retrospectiva
• Llevar y coordinar la charla
• Controlar el tiempo
• Cerrar y documentar
Se debe especificar un objetivo de la retrospectiva ya que esta marcará el enfoque
con el que se encarará el resto de la reunión. Una vez hecho esto, se deberá
presentar el objetivo de la retrospectiva. El objetivo lo determina quién guiará la
retrospectiva, con consultas previas al equipo.
Recolección de Datos:
Esta es la etapa donde el equipo hablara sobre hechos, sin juzgarlos. La idea es llegar
a un acuerdo sobre los eventos que ocurrieron durante la iteración, y tener así una
base común sobre la cual reflexionar luego y sacar conclusiones.
En esta etapa, los miembros del equipo deberán presentar hechos que ocurrieron
durante la iteración, eventos que consideren relevantes. Por ejemplo, se pueden
presentar:
• historias terminadas o no terminadas
• impedimentos
• decisiones que se tomaron
• emociones de los miembros
101

Reflexionar
Aquí es donde comienzan a aparecer las ideas, los posibles caminos a recorrer.
Durante la reflexión el equipo analiza los hechos y busca responderse dos preguntas
básicas:
• ¿por qué pasó lo que pasó?
• ¿cómo mejorar?
El equipo empieza a tener ideas sobre cómo poder seguir avanzando, no perdiendo
de vista las consecuencias que cree generarán los cambios.
Es aquí donde se empieza a comprender cómo los eventos, comportamientos y
circunstancias afectan al trabajo del equipo Development.
Decidir qué Hacer
Siempre hay que fomentar que el equipo busque acciones para solucionar sus
problemas.
Este es un momento crucial en la retrospectiva, y representa el compromiso del
equipo para actuar a futuro. El equipo deberá armar un plan de acción para concretar
alguno de los experimentos planteados en la reflexión.
Las acciones que el equipo decida tomar deben poder llevarse adelante por ellos
mismos: esperar que otras personas actúen por el equipo es un camino seguro a la
frustración.
Es importante evitar las retrospectivas de "hacer nada", porque pierden justamente
el sentido de la reunión: uno de los grandes impedimentos para mejora es que
pensemos que todo es perfecto o en su defecto que no tiene solución, pero también
es perder la iniciativa por aprender cosas mejores.
Cerrar la retrospectiva
Durante la retrospectiva el equipo trabajó mucho, realizó varias actividades y genera
un compromiso y plan de acción para el próximo sprint. Debemos guardar todo el
trabajo hecho durante la retrospectiva. Por ejemplo:
• registrar lo expuesto y sus soluciones
• sacar fotos de las actividades
•sacar fotos al pizarrón
Lo esencial del cierre es que todos los miembros del equipo se retiren con acciones
concretas y experimentos para aplicar durante la próxima iteración.
 Técnica del Barco

Técnicas para
Retrospectiva
Técnicas para
Retrospectiva

Técnica de la Estrella de Mar

 “La prueba definitiva para el agilísimo
es poder mantener a todos los
Stakeholders felices”

“Nunca olvides que mejores “Tratar a los empleados como

principios, no mejores prácticas, seres humanos adultos puede
es lo que realmente necesitan las parecer de sentido común, pero no
organizaciones” es una práctica común”