CURSO AGILE

Acuerdos de Trabajo

¿Qué son?
¿Para qué sirven?
¿Cuándo los usamos?
 Presentación y Logística

Bienvenida
• Preséntese en el siguiente formato:
• Nombre
• Empresa
• Papel y fondo
• Expectativas de este curso
 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.
Transformación Digital
 Transformación Digital

La transformación digital es la profunda transformación de las actividades, procesos,

competencias y modelos empresariales y organizativos para aprovechar al máximo los
cambios y oportunidades de una combinación de tecnologías digitales y su impacto
acelerado en la sociedad de forma estratégica y priorizada, con presente y futuro.
Transformación Digital
Transformación Digital
Bases de una transformación digital
Nivel de madurez transfor m a c ió n d i gi ta l
In t ro d u cc ió n
 V
VOLATIL U COMPLEJO

C
A
INCIERTO AMBIGUO
 • Cambios inestables
• Retos inesperados
• Duración desconocida
• No necesariamente es difícil de entender
VOLATIL
 •Muchas partes o variables
Interconectadas e interdependientes
• Las relaciones no están del todo claro
• Ausencia de conexión clara entre causas y efectos
• No existen precedentes
COMPLEJO
 • Incapacidad de predecir el futuro
• Que es impreciso, borroso o desconocido
• Falta de conocimiento seguro y claro de algo
• No hay suficiente información

INCIERTO
 • Las relaciones causales son completamente difusas
• No existen precedentes
• Falta claridad acerca del significadodel evento
• Que puede entenderse o interpretarse de diversas maneras

AMBIGUO
Marco Cynefin
Sondeo Análisis
Ensayos Expertos
Nuevos Practicas Buenas Practicas

Desordenado

Acción
Categorización
Respuesta
Mejores Prácticas
Rápida
 ¿Por qué metodologías
ágiles?

El 80% de todos los proyectos

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

Casi tres cuartas partes (71%) de las

organizaciones informan que utilizan
enfoques ágiles a veces, a menudo o
siempre. (Fuente: Project Management
Institute)
Gestión de Proyectos
tradicional
Propuesta de valor de la
Agilidad
•Se construye y entrega
todo o nada, todo
documentado
•Una fase no se
empieza sin terminar la
otra

•Entregando para el
feedback, entregar producto
es la prioridad
Iterativo e Incremental
 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.

REF: http://agilemanifesto.org/iso/es/manifesto.html
 Logo
Partner

Individuos e interacciones
Sobre procesos y herramientas

Software funcionando
Sobre documentación extensiva

Respuesta ante el cambio

Sobre seguir un plan
Colaboración con el cliente
Sobre negociación contractual
 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.
 Principios detrás del
• La mayor prioridad es satisfacer al cliente a través de la Manifiesto Ágil
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
sostenible.
• La atención continua a la excelencia técnica y al buen
diseño incrementan la agilidad.
• La simplicidad - el arte de maximizar la cantidad de
trabajo no hecho - es esencial.
• Las mejores arquitecturas, requerimientos y diseños
emergen de los equipos auto-organizados.
• En intervalos regulares, el equipo reflexiona sobre
cómo volverse más efectivo, entonces afina y ajusta su
comportamiento como corresponde.
 ¿Qué es agilidad?

ASD
“Agilidad es la capacidad de crear y
responder al cambio con el fin de obtener
ganancias en un entorno empresarial
turbulento”

DSDM
Crystal “La agilidad es la capacidad de equilibrar
la flexibilidad y estabilidad”
Waterfall vs Agile
Waterfall Agile
Estructurado Flexible
Proceso secuencial Altamente colaborativo / paralelizable
Mejor en proyectos en que el Aplica para los proyectos que están
cambio no es frecuente cambiando continuamente
Necesita requerimientos claros Se espera que los requerimientos
antes de comenzar cambien
Baja incertidumbre, procesos Alta incertidumbre, siempre diferente
repetibles

http://slides.com/mstrione/el-elefante-agile-3#/3
Agile como cultura
Definición
Agilidad

La agilidad/agile es un “mindset”.
Un camino de continua exploración, adaptación, aprendizaje y
mejora, que a partir del desarrollo evolutivo e incremental busca
obtener el producto, servicio o resultado más adecuado de la mejor
manera posible, basado en la colaboración, la confianza y la
motivación de las personas involucradas.

Adaptado de una definición de

Mauro Strione
 Calidad Agil

La calidad se refiere a si un producto funciona y si satisface las necesidades

de los interesados del proyecto. La calidad es una parte inherente de la
gestión ágil de proyectos.

Los principios del manifiesto Agile enfatizan la creación de un entorno en el

que los equipos ágiles puedan producir una funcionalidad valiosa y
funcional. Los enfoques ágiles fomentan la calidad en el sentido de que los
productos funcionan correctamente y satisfacen las necesidades de las
partes interesadas del proyecto.
 Lean

Lean es una filosofía y un enfoque que hace hincapié en la eliminación de

residuos o de no valor añadido trabajo a través de un enfoque en la mejora
continua para agilizar las operaciones. Está centrado en el cliente y enfatiza el
concepto de eliminar cualquier actividad que no agregue valor a la creación o
entrega de un producto o servicio. Lean se centra en ofrecer una mayor
calidad, reducir el tiempo de ciclo y reducir los costos.
 Work-in-Progress (WIP)

La abreviatura WIP significa “Work In Progress” o “trabajo en proceso” en

español. En pocas palabras, WIP es la cantidad de tareas en las que un
equipo está trabajando actualmente. Delimita la capacidad de los flujos de
trabajo de sus equipos en cualquier momento.
 Integración Continua

La integración continua es un modelo informático propuesto inicialmente

por Martin Fowler que consiste en hacer integraciones automáticas de un
proyecto lo más a menudo posible para así poder detectar fallos cuanto
antes. Entendemos por integración la compilación y ejecución de pruebas de
todo un proyecto.
 Stakeholders se dividen en:

Cliente: El cliente es la persona o la organización que adquiere el producto del

proyecto, servicio o cualquier otro resultado.

Usuarios: El usuario es el individuo o la organización que utiliza directamente el

producto del proyecto, servicio, o cualquier otro resultado; también, en algunas
industrias el cliente y los usuarios puede ser lo mismo.

Patrocinador: El patrocinador es la persona o la organización que provee recursos y

apoyo para el proyecto, el patrocinador también es el Stakeholder a quien todos le
deben rendir cuentas al final.
 Participación del usuario

La participación activa del usuario es el primer principio del desarrollo ágil por que:

• Los requisitos se priorizan de manera apropiada en función de las necesidades del

usuario y del mercado
• Los requisitos se pueden aclarar a diario con todo el equipo del proyecto
• A medida que se entregan las iteraciones del producto, el producto cumple con las
expectativas del usuario
• El usuario / empresa ve el compromiso del equipo.
• Los desarrolladores son responsables, compartiendo el progreso abiertamente con
el usuario / negocio
 Retroalimentacion del usuario

La retraoalimentacion o comentarios de los clientes son una idea de lo que funciona

bien con su producto o servicio y lo que se debe hacer para mejorar la experiencia. Es
posible que tenga la mejor experiencia en la industria en la que opera su empresa,
pero su conocimiento profesional nunca será más valioso para el desempeño del
negocio que las percepciones de los clientes. Sus opiniones le ayudan a garantizar que
el producto final realmente cumpla con sus expectativas, resuelva sus problemas y
satisfaga sus necesidades.
 Logo Planificación Ágil
Partner
 Logo Planificación Ágil
Partner

La planificación ágil toma como base el control empírico de la construcción de producto

(inspección y adaptación), por lo cual:

Plantea un faseado basado en objetivo del producto (desarrollo iterativo e incremental)

priorizados balanceando beneficios de negocio respecto a sus costes de desarrollo.

Realiza un faseado muy intenso (de 2 a 4 semanas) con demostraciones al cliente de ese
incremento de producto, de manera que se facilita el realizar cambios que consigan el
máximo alineamiento con sus expectativas y se cree un espacio natural para la
replanificación estratégica de los objetivos todavía no abordados.
 Estimación Ágil

La principal premisa en que se basa la estimación ágil es el conocimiento, la

experiencia del propio equipo (frente a otros métodos de estimación que se
basan en la experiencia de otros equipos, es decir, en la estadística).

El trabajo podría ser de tamaño o esfuerzo estimado variables

 Estimación Planning Póker

Esta es una de las técnicas más

reconocidas en marcos agiles, ya
que es muy sencilla, divertida y
eficaz, donde el equipo estima
como grupo el esfuerzo a realizar
en el Sprint.
 Estatus del proyecto

El estatus del avance del proyecto se basa en las siguientes premisas:

• Cumplimiento de los criterios de aceptación definidos en las historias de

usuario
• Cumplimiento de la definición de terminado, esta definición se utiliza para
evaluar cuando se ha completado el trabajo sobre el Incremento de
producto
• Demo de la funcionalidad desarrollada
TAI Digital
Game
Ball Point Game
Instrucciones
 ¿Cómo debemos ver a la
agilidad?

En cualquier tipo de disciplina de ges+ón, ser ágil es una cualidad, por lo tanto
esto debe ser una meta que se debe tratar de alcanzar.

La ges+ón de proyectos Agile especialmente, implica la adaptabilidad durante la

creación de un producto, servicio o cualquier otro resultado.
 ¿Qué es Scrum?

Scrum (n): Un marco de trabajo por el cual las

personas pueden abordar problemas complejos
adapta+vos, a la vez que entregar productos del
máximo valor posible produc+va y
crea+vamente.

Scrum es:
• Ligero
• Fácil de Entender
• Di?cil de dominar
 Usos de Scrum

Scrum fue desarrollado inicialmente para ges+onar y desarrollar productos. Desde

principios de los años 90.

Scrum se ha usado para desarrollar soLware, hardware, soLware embebido, redes

de funciones interac+vas, vehículos autónomos, escuelas, gobiernos, mercadeo,
también para ges+onar la operación de organizaciones y casi todo lo que usamos en
nuestra vida diaria, como individuo y como sociedad.

Scrum demostró ser especialmente efec+vo en la transferencia itera+va e

incremental de conocimiento. Scrum se usa ahora ampliamente para productos,
servicios y ges+ón de la organización matriz
Teoría de Scrum
 Itera=vo e Incremental
Scrum se basa en la teoría de control de procesos empírica o empirismo.
El empirismo asegura que el conocimiento procede de la experiencia y de tomar
decisiones basándose en lo que se conoce.
Scrum emplea un enfoque itera+vo e incremental para op+mizar la predic+bilidad y
el control del riesgo.
Tres pilares de Scrum

• Transparencia
• Inspección
• Adaptación
 Transparencia

Los aspectos significa+vos del

proceso 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án viendo
 Inspección
Los usuarios de Scrum deben
inspeccionar frecuentemente los
artefactos de Scrum y el progreso
hacia un obje+vo para detectar
variaciones indeseadas.
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

Uno de los tres pilares del

control del proceso empírico;
la retroalimentación se usa
para hacer un ajuste al
producto de trabajo que se
está desarrollando o al
proceso por el cual se está
desarrollando.
Valores de Scrum Los Valores de Scrum

CORAJE
Los miembros del Equipo Scrum
FOCO aprenden y exploran estos valores a
COMPROMISO
medida que trabajan en los eventos,
roles y artefactos de Scrum.
RESPETO

APERTURA
Roles
 Roles

Un conjunto cohesivo de
responsabilidades que pueden
ser cumplidas por una o más
personas.
Los tres roles de Scrum son
Propietario del producto, Scrum
Master y equipo de desarrollo.
 Scrum Team
El Equipo Scrum consiste en un Dueño de Producto (Product
Owner), el Equipo de Desarrollo (Development Team) y un
Scrum Master.
Los Equipos Scrum son autoorganizados y multifuncionales.
El modelo de equipo en Scrum está diseñado para optimizar
la flexibilidad, la creatividad y la productividad.
El equipo de Scrum ha demostrado ser cada vez más efectivo
para todos los usos anteriores y cualquier trabajo complejo.
Los Equipos Scrum entregan productos de forma iterativa e
incremental, maximizando las oportunidades de obtener
retroalimentación. Las entregas incrementales de producto
“Terminado” aseguran que siempre estará disponible una
versión potencialmente útil y funcional del producto.
 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 una visión

dual.
• El debe entender y apoyar las necesidades
e intereses de todos los Stakeholders.
• Comprende las necesidades y el
funcionamiento del Development Team.
 Responsabilidades del Product Owner
Determinar las
ac=vidades generales
de inicio de un
proyecto

Ayudar en la
definición de la
visión del proyecto

Asegurar los recursos

financieros del
proyecto

Centrarse en la
creación de valor y
en la generación
del ROI
 Responsabilidades del Product Owner

Evaluar la viabilidad y
garantizar la entrega del
producto o servicio

Representar al
usuario o al cliente

Ayudar en la elección
del Scrum Master y de
los miembros del
Development Team

Responsable por la
administración del
Product Backlog
 Responsabilidades del Product Owner

Ayudar a crear y a
aprobar los User Story

Explicar los User

Story al
Development Team

Definir los criterios de

aceptación

Participar en la
retrospectiva del
Sprint y el proyecto
 Responsabilidades del Product Owner

Conocimiento del
negocio

Excelentes
habilidades de
comunicación

Conocimiento de
procesos de Scrum

Accesible
 Caracteris=cas del Product Owner

Habilidades de
negociación

Decisivo

Proac=vo

Orientado
a las
metas
 Scrum Master
El Scrum Master es responsable de promover y
apoyar Scrum como se define en la Guía de Scrum.

Los Scrum Masters hacen esto ayudando a todos a

entender la teoría, prác+cas, reglas y valores de
Scrum.

El Scrum Master es un líder que está al servicio del

Equipo Scrum. El Scrum Master ayuda a las
personas externas al Equipo Scrum a entender qué
interacciones con el Equipo Scrum pueden ser ú+les
y cuáles no.

El Scrum Master ayuda a todos a modificar estas

interacciones para maximizar el valor creado por el
Equipo Scrum.
 Responsabilidades del Scrum
Asegura que los Master con el Product Owner
obje=vos, el alcance y el
dominio del producto
sean atendidos por todos
en el Equipo Scrum

Facilitar técnicas
para gestioar el
Product Backlog de
manera eficiente

Fomenta la necesidad
de contar con
elementos de la lista
de productos claros y
concisos

Entender la
planificación del
producto en un
entorno empírico
 Responsabilidades del Scrum
Master con el Product Owner

Asegurar que el dueño

del producto conozca
como ordenar la lista de
producto para maximizar
valor
Explica cómo
realizar un
levantamiento de
requerimientos
ágiles

Entender y prac=car la
agilidad
 Responsabilidades del Scrum
Master con la organización
Lidera y guía a la Mo=va cambios que
organización en la incrementen la
adopción de Scrum produc=vidad del
Scrum Team (PO y DT)

Planifica la
implementación de
Scrum en la
organización

Ayuda al Scrum Team

Trabaja de la mano de
(PO y DT) y
otros Scrum Master
Stakeholders a
para incrementar la
entender y llevar a
efec=vidad de Scrum
cabo Scrum
 Responsabilides del Scrum Master con
el Development Team

Guía al equipo en ser

auto – organizado y
mul=funcional

Asegura que el
Scrum Board
permanezca
actualizado

Ayuda al Development
Team para crear
productos de alto
valor
 Responsabilides del Scrum Master con
el Development Team

Elimina Impedimentos
para el progreso de la
construcción

Facilitar los eventos

de Scrum según se
requiera o necesite

Asiste al Development
Team en el desarrollo
del Sprint Backlog y el
Sprint Burdown Chart
 Development Team
El Equipo de Desarrollo consiste en los
profesionales que realizan el trabajo de entregar
un Incremento de producto “Terminado” que
potencialmente se pueda poner en producción
al final de cada Sprint.
Un Incremento “Terminado” es obligatorio en la
Revisión del Sprint.
Solo los miembros del Equipo de Desarrollo
par+cipan en la creación del Incremento.
La organización es la encargada de estructurar y
empoderar a los Equipos de Desarrollo para que
estos organicen y ges+onen su propio trabajo. La
sinergia resultante op+miza la eficiencia y
efec+vidad del Equipo de Desarrollo.
Tamaño del Development Team
El tamaño óptimo del Equipo de Desarrollo es lo
suficientemente pequeño como para permanecer ágil
y lo suficientemente grande como para completar una
cantidad de trabajo significativa.

Tener menos de tres miembros en el Equipo de

Desarrollo reduce la interacción y resulta en ganancias
de productividad más pequeñas.

Los Equipos de Desarrollo más pequeños podrían

encontrar limitaciones en cuanto a las habilidades
necesarias durante un Sprint, haciendo que el Equipo
de Desarrollo no pudiese entregar un Incremento que
potencialmente se pueda poner en producción.

Tener más de nueve miembros en el equipo requiere

demasiada coordinación.
 Responsabilidades del
Asegurar una comprensión Development Team
clara de los requerimientos

Es=mar los User Stories

aprobados

Crear entregables de alta

calidad

Desarrollar la lista de tareas basadas

en las User Stories aprobadas

Calcular el esfuerzo para las

tareas identificadas
 Responsabilidades del
Desarrollar el Sprint Backlog Development Team
y el Sprint Burdown Chart

Crear los entregables

Iden=ficar el riesgo y
ejecutar acciones su
mi=gación

Iden=ficar oportunidades de mejora

Participar en la
retrospectiva del proyecto y
Sprint
 Caracterís=cas
Development Team
Conocimiento de Scrum

Expertos Técnicos

Colaboración

Auto
Organización

Altamente Motivados
 Caracterís=cas
Development Team
Buen miembro de
equipo
los requerimientos

Proac=vos

Independientes

Responsables

Intui=vos

Orientados a los
Objetivos
 Stakeholders

Una persona, grupo u

organización que afecta o
puede verse afectado por las
acciones de una organización.
Conceptos Claves en Scrum
 Logo
Partner
Ciclo Scrum
 Logo
Partner

Product Sprint
Backlog Backlog
 Conceptos Claves en Scrum

Épicas: Es una historia de usuario que es demasiado

grande para caber en un sprint. A menudo, este
término se u+liza 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,
u+lizando el lenguaje común del usuario.
Task: Es una representación del requisito que está en
lenguaje del usuario, pero de una forma técnica
donde está definido cómo se va a trabajar y quién van
a par+cipar.
Nivel de detalle
 ¿Cómo está conformada
una User Story?
Una historia de usuario debe estar
conformada por las 3C: Caracterís+cas: modelo INVEST.
• Independencia
Card (tarjeta): Descripción escrita de lo • Negociables
que necesita el usuario. • Valiosa
Convesación: El PO y el DT aclaran los • Es+mable
detalles.
• Pequeña
Confirmación: Sirve para determinar lo
• Verificable
que se espera.
 Las 3C

Card Conversation Confirmation

 Task

El trabajo técnico que realiza un equipo de

desarrollo para completar un ítem de
retraso acumulado del producto.
La mayoría de las tareas se definen como
pequeñas, lo que representa no más de
unas pocas horas a un día más o menos de
trabajo.
 ¿Cómo está conformada
una Task?

Caracterís+cas modelo SMART:

S: Specific (Especifico)
M: Measurable (Medible)
A: Achievable (Alcanzable)
R: Relevant (Relevante)
T: Time-boxed (Tiempo-caja)
Son los acuerdos del PO con los Stakeholders que contiene todas las
condiciones que deben de cumplir los ítems del Product Backlog para
considerar un Sprint completado o finalizado.
Definición de Done
 Ventajas de Time-Boxing

Time-boxing es una prác+ca crí+ca en Scrum y debe aplicarse con cuidado.

Un Time-boxing arbitrario puede llevar a la desmo+vación del equipo y puede tener como
consecuencia la creación de un entorno opresivo, por lo que Time-boxing debe ser u+lizado
de manera apropiada.

Beneficios:
• Procesos de desarrollo eficiente.
• Menos gastos generales.
• Alta velocidad para los equipos.
• Ayuda a ges+onar eficazmente la planificación y ejecución de proyectos.
 Logo ¿Dónde se u=lizan los Time-Boxing?
Partner
 Eventos formales

Scrum prescribe cuatro eventos

formales, contenidos dentro del Sprint,
TIME-BOX
SCRUM EVENT (FOR 1-MONTH PARTICIPANTES para la inspección y adaptación:
SPRINT)

SPRINT PLANNING 8 HORAS • Planificación del Sprint (Sprint

Planning)
DAILY SCRUM 15 MINUTOS • Scrum Diario (Daily Scrum)
• Revisión del Sprint (Sprint Review)
SPRINT REVIEW 4 HORAS
• Retrospec+va del Sprint (Sprint
SPRINT
Retrospec+ve)
3 HORAS
RETROSPECTIVE
 Logo Sprint
Partner
 Logo Sprint
Partner
Sprint

Duración
1 a 4 semanas

Definición
Es el Corazón de Scrum, en el cual se crea el incremento del
producto “terminado”, cada sprint puede considerarse un
Proyecto con un horizonte no mayor de un mes

Acción
Sprint con=ene y consiste en:
• Sprint Planning Mee=ng
• Daily Standup Mee=ng
• Sprint Review Mee=ng
• Sprint Retrospec=ve Mee=ng
 Eventos de Scrum

Para que cualquier proyecto tenga éxito,

la comunicación es importante. Los
equipos Scrum emplean una serie de
reuniones clave para estructurar el
trabajo del equipo:

• Daily Standup Mee+ng

• Sprint Planning Mee+ng
• Sprint Review Mee+ng
• Sprint Retrospec+ve
 Logo Daily Standup Mee=ng
Partner
 Reunión diaria (Daily
Sprint)
• Punto de inspección y adaptación en Scrum.
Máx. 15 minutos.
• El equipo se reúne para comunicar y entender el
estados.
• Esencial para conocer el progreso con+nuo y
evitar bloqueos.
• No +ene como obje+vo reportar progreso al
Scrum Master Product Owner o cualquier otro
stakeholder.
• El Product Owner podrá par+cipar siempre y
cuando su par+cipación sea pasiva.
• El Scrum Master se asegura de que el Equipo de
Desarrollo mantenga Ia reunión, pero el Equipo
de Desarrollo es el responsable de dirigir el
Scrum Diario.
 Logo Sprint Planning Mee=ng
Partner
Duración
8 Horas por
un Sprint de
un mes

Sprint
Definición
El trabajo a realizar durante Planning
el sprint se planifica en esta Mee=ng
ceremonia, este plan se crea
con la colaboración de todo
el Scrum team. Al finalizar la
reunión de planificación,
Develoment Team debería
ser capaz de explicar al PO y
SM como lograr el obje=vo Acción
del Sprint como un equipo En esta ceremonia se formulan
auto-organizado 2 preguntas:
• ¿Qué puede ser terminado
en este Sprint?
• ¿Cómo se conseguirá
completar el trabajo
seleccionado?
El resultado de estas preguntas
es definir el Sprint Goal, Sprint
Backlog, es=mación de
esfuerzo
 ¿Qué puede ser terminado?

Esta pregunta nos ayuda para que el

Development Team (DT) trabaje para
proyectar la funcionalidad que se
desarrollará durante el Sprint, donde se
define obje+vo del Sprint (Sprint Goal).

El número de elementos del Product

Backlog seleccionados para el Sprint
depende únicamente del Development
Team (DT).
 Sprint Goal

El Obje+vo del Sprint es una meta establecida para el Sprint que puede lograrse
mediante la implementación de la Lista de Producto.

El obje+vo del Sprint brinda al equipo de desarrollo cierta flexibilidad con

respecto a la funcionalidad implementada en el Sprint.

El obje+vo del Sprint puede representar otro nexo de unión que haga que el
Equipo de Desarrollo trabaje en conjunto y no en inicia+vas separadas
 ¿Cómo se conseguirá completar el trabajo
seleccionado?

Una vez que se ha establecido el objetivo y

seleccionado los elementos de la Lista de
Producto para el Sprint, el Equipo de
Desarrollo decide cómo construirá esta
funcionalidad para formar un Incremento
de producto “Terminado” durante el
Sprint.

Los elementos de la Lista de Producto Sprint

seleccionados para este Sprint, más el plan
para terminarlos, recibe el nombre de Lista Backlog
de Pendientes del Sprint (Sprint Backlog).
Sprint Review Mee=ng
 Sprint Review Mee=ng
Los asistentes son el Equipo Scrum y los
interesados clave invitados por el Dueño de
Producto.
El Dueño de Producto explica qué elementos de
la Lista de Producto se han “Terminado” y
cuales no se han “Terminado”
El Equipo de Desarrollo habla acerca de qué
estuvo bien durante el Sprint, qué problemas
aparecieron y cómo fueron resueltos esos
problemas.
El Equipo de Desarrollo hace una demostración
del trabajo que ha “Terminado” y responde
preguntas acerca del Incremento.
 Sprint Review Mee=ng
• El Dueño de Producto habla acerca de la Lista de Producto
en su estado actual. Proyecta obje+vos probables y fechas
de entrega en el +empo basándose en el progreso obtenido
hasta la fecha (si fuera necesario).

• El grupo completo colabora acerca de qué hacer a

con+nuación, de modo que la Revisión del Sprint
proporcione información de entrada valiosa para Reuniones
de Planificación de Sprints subsiguiente.

• Revisión de cómo el mercado o el uso potencial del

producto podría haber cambiado lo que es de más valor
para hacer a con+nuación.

• Revisión de la línea de +empo, presupuesto, capacidades

potenciales y mercado para las próximas entregas de
funcionalidad o capacidad prevista del producto.
 Sprint Retrospective

La Retrospec+va de Sprint es una

oportunidad para el Equipo Scrum de
inspeccionarse a sí mismo y de crear un
plan de mejoras que sean abordadas
durante el siguiente Sprint.
La Retrospec+va de Sprint +ene lugar
después de la Revisión de Sprint y antes
de la siguiente Planificación de Sprint.

Se trata de una reunión de, a lo sumo,

tres horas para Sprints de un mes
 Sprint Retrospec=ve
El propósito de la Retrospec+va de Sprint
es:
• Inspeccionar cómo fue el úl+mo Sprint
en cuanto a personas, relaciones,
procesos y herramientas.
• Iden+ficar y ordenar los elementos
más importantes que salieron bien y
las posibles mejoras.
• Crear un plan para implementar las
mejoras a la forma en la que el Equipo
Scrum desempeña su trabajo.
 Artefactos
Los artefactos de Scrum representan trabajo o valor
en diversas formas que son ú+les para proporcionar
transparencia y oportunidades para la inspección y
adaptación.
Los artefactos definidos por Scrum están diseñados
específicamente para maximizar la transparencia de
la información clave, necesaria para asegurar que
todos tengan el mismo entendimiento del artefacto.

• Product Backlog
• Sprint Backlog
• Incremento del producto
 Product Backlog

La Lista de Producto es una lista ordenada de todo lo que se

conoce que es necesario en el producto.
Es la única fuente de requisitos para cualquier cambio a
realizarse en el producto. El Dueño de Producto (Product
Owner) es el responsable de la Lista de Producto, incluyendo
su contenido, disponibilidad y ordenación.
La Lista de Producto es dinámica; cambia constantemente para
iden+ficar lo que el producto necesita para ser adecuado,
compe++vo y ú+l Product
Backlog
La Lista de Producto enumera todas las caracterís+cas,
funcionalidades, requisitos, mejoras y correcciones que
cons+tuyen cambios a realizarse sobre el producto para
entregas futuras.
 Refinamiento del Product
Backlog
El refinamiento (refinement) de la Lista de Producto es el
acto de añadir detalle, es+maciones y orden a los
elementos de la Lista de Producto.
Durante el refinamiento de la Lista de Producto, se
examinan y revisan sus elementos.
El Equipo Scrum decide cómo y cuándo se hace el
refinamiento.
Este usualmente consume no más del 10% de la capacidad
del Equipo de Desarrollo. Sin embargo, los elementos de la
Lista de Producto pueden actualizarse en cualquier
momento por el Dueño de Producto o a criterio suyo.
 Sprint Backlog

La Lista de Pendientes del Sprint es el conjunto de

elementos de la Lista de Producto seleccionados para el
Sprint, más un plan para entregar el Incremento de
producto y conseguir el Obje+vo del Sprint.
La Lista de Pendientes del Sprint es una predicción
hecha por el Equipo de Desarrollo acerca de qué
funcionalidad formará parte del próximo Incremento y
del trabajo necesario para entregar esa funcionalidad en
un Incremento “Terminado”.
Product Sprint
La Lista de Pendientes del Sprint hace visible todo el Backlog Backlog
trabajo que el Equipo de Desarrollo iden+fica como
necesario para alcanzar el Obje+vo del Sprint.
 Incremento
El Incremento es la suma de todos los elementos de la Lista de Producto completados durante un Sprint y el
valor de los incrementos de todos los Sprints anteriores.
Al final de un Sprint el nuevo Incremento debe estar “Terminado”.

Un incremento es un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo al final del
Sprint.

El incremento debe estar en condiciones de utilizarse sin importar si el Dueño de Producto decide liberarlo o no.
Seguimiento del Progreso Hacia los Obje+vos
Seguimiento del Progreso del Sprint
Seguimiento