Scrum,

Agilidad en
losproyectos
“SCRUM es el arte de balancear limites
con libertad, para poder ser creativos y
productivos a la vez”
Alan Cymet
Scrum
360
 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.
 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
 Cambio de Paradigma con Scrum

Scrum fomenta los: Eres trabajador de

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

Eres trabajador de conocimiento

porque no te consideras un
“recurso”
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.
 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: [Link]
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.
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.
Principios
VII. El software funcionando es la medida de
progreso.
[Link] 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
 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.
 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.
 ¿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.
 ¿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.
¿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.
 Proceso iterativo

1 2 3
 Proceso Incremental

1 2 3
Iterativo e incremental
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

1 4

2 ?

3
 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.
 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.
 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.
 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.
Valores 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).
Ciclo de Vida de Scrum
Roles… El Cerdo y Pollo
 Roles

 Scrum Team
Entender los roles y responsabilidades  Scrum Core Roles
definidos en un proyecto de Scrum es  Comprometidos
muy importante para asegurar la exitosa
implementación de Scrum.  Stakeholder
 Implicado
 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
 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.
Resposabilidades del Product Owner
Responsabilidades del Product Owner
Caracteristicas de un Product Owner
 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.
 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.
 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.
 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.
 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.
 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.
 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.
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.
Ejemplos
 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.
 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.

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
 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:
 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.
 ¿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.
 Sprint Goal
Meta del Sprint
 ¿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 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.
Actividad
Planning
Póker
 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
se vuelven a reunir inmediatamente del Daily para tener discusiones
impedimentos detalladas para adaptar, o replanificar el resto del trabajo.
hallados?
Las 5 Etapas de una Retrospectiva
 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, es seres humanos adultos puede
lo que realmente necesitan las parecer de sentido común, pero no
organizaciones” es una práctica común”