Scrum Fundamental y Scrum Master

Certificated
 PRESENTACIÓN

• Nombre
• Profesión
• Empresa donde trabaja
• Cargo Actual
• Experiencia en:
• Marco de referencia Scrum
• Expectativas del curso
Resúmen del curso
A medida que se utiliza Scrum, se
pueden encontrar, aplicar y diseñar
patrones, procesos y enfoques que se
ajusten al marco de trabajo Scrum.
En este curso, aprenderemos dentro
de muchas cosas a identificar las
tareas que debe cumplir cada
integrante del proyecto y en especial
el Scrum Master, analizando el rol y
sus compromisos con todo el equipo
a lo largo del ciclo de vida de un
proyecto Scrum.
Contenido del curso
Agile
Apoyo del Scrum Master en los eventos de Scrum
✓ El enfoque de dirección de proyectos de Ágil
✓ La filosofía de dirección de proyectos de Ágil ✓ El Sprint
✓ Breve historia de Ágil ✓ Reunión de Planificación de Sprint (Sprint Planning
✓ Ejemplos de principios y prácticas de Ágil Meeting)
✓ Definición de pensamiento Agile ✓ Scrum Diario (Daily Scrum)
✓ Creando mentalidad agile ✓ Revisión de Sprint (Sprint Review)
✓ Cascada vs Agile
✓ El manifiesto Agile ✓ Retrospectiva de Sprint (Sprint Retrospective)
✓ El manifiesto Agile - Principios Artefactos de Scrum
Scrum ✓ Lista de Producto (Product Backlog)
✓ Contexto ✓ Refinamiento de la Lista de Producto (Product Backlog
✓ Teoría de Scrum Refinement)
Roles y Responsabilidades ✓ Lista de Pendientes del Sprint (Sprint Backlog)
✓ Equipo Scrum ✓ Incremento (Incremt)
Rol del Scrum Master
✓ Definición de “Terminado” (Definition of “Done”)
✓ Características
✓ Responsabilidades y compromisos
✓ Coaching del equipo
Contenido del curso
Estimación, planificación y seguimiento en un contexto Monitoreo de progreso
Ágil ✓ BurnUp Chart
✓ Historias de usuario ✓ Burndown Chart
✓ Épicas
✓ Ventajas que aportan las historias de usuario
✓ Información en una historia de usuario
✓ Recomendación de atributos
✓ Criterios de aceptación
✓ Calidad en las historias de usuario
✓ Priorización de historias de usuario
✓ Técnica MoSCoW para priorización del Product Backlog
✓ Estimación ágil utilizando planning poker
✓ ¿Cómo jugar?
✓ Conceptos de tamaño y velocidad
✓ Utilizando un tablero de tareas
Agile
El enfoque de dirección de proyectos de Ágil
La filosofía de dirección de proyectos de Ágil
Es muy importante tener en cuenta que Ágil no es una metodología,
sino un enfoque que puede utilizar varias metodologías.

Ágil usa modelos de organización basados en las personas, la

colaboración y los valores compartidos. El Manifiesto de Ágil describe
los principios primarios de la filosofía Ágil.

Estos son planificación gradual, entrega iterativa e incremental,

respuesta al cambio flexible y rápida, y comunicación abierta entre
equipos, interesados y clientes.

Algunos ejemplos de marco de referencia y metodologías de Ágil son

SCRUM y XP. Lean y Desarrollo Guiado por las Pruebas (TDD).
Breve historia de Ágil

Las frustraciones de aplicar métodos secuenciales de

dirección de proyectos resultaron en el surgimiento de Ágil.

Un grupo de destacados desarrolladores de software se

reunieron en Snowbird, Utah, EE.UU., en 2001 para discutir
estos desafíos. Finalmente, crearon el Manifiesto de Ágil.

Lo que la industria del software necesitaba era una mayor

agilidad: nuevos métodos que permitieran realizar cambios
sin afectar significativamente los costos ni los cronogramas
de producción.
Breve historia de Ágil

Dividir la producción en componentes (llamados

iteraciones) que pudieran ser desarrollados y probados en
forma simple y rápida, permitió hacer modificaciones sin
tener que esperar a que esté terminado el producto final.

Actualmente, los métodos de Ágil se utilizan en diversas

industrias además del desarrollo de software, como la de
telecomunicaciones, la industria aeroespacial y la
construcción, además de combinarse con enfoques más
tradicionales y lineales de dirección de proyectos.
Ejemplos de principios y prácticas de Ágil

Los siguientes ejemplos ayudan a ilustrar la aplicación de los principios y

las prácticas de Ágil:

❖ Retorno de inversión temprano y mensurable a través de la entrega

definida e iterativa de incrementos del producto
❖ Alta visibilidad del progreso del proyecto, que permite identificar y
resolver o supervisar los problemas en forma temprana
❖ Participación continua del cliente a lo largo del ciclo de desarrollo del
producto
❖ Mayor autonomía para que el responsable del negocio tome las
decisiones necesarias para alcanzar las metas
❖ Adaptación a necesidades cambiantes del negocio, lo que da una
mayor influencia sobre los cambios de requerimientos
❖ Menos derroches en el producto y en el proceso
 Mentalidad Ágil

"Ser" ágil Haciendo ágil

La forma correcta de Una forma ineficaz de
implementar ágil implementar ágil.

Ser ágil comienza con la Hacer ágil implica el uso de

internalización de la mentalidad prácticas ágiles sin adoptar la
ágil, luego usa esa comprensión mentalidad ágil que nos
para seleccionar e implementar permite comprender cómo
las prácticas correctas, seleccionar el equilibrio
adaptándolas a diferentes correcto de prácticas y
situaciones según sea necesario adaptarlas adecuadamente.
 Cascada vs Agile

Metodologías Tradicionales Metodologías Agiles

❖ Basadas en normas provenientes de estándares seguidos por el ❖ Basadas en heurísticas provenientes de prácticas de producción
entorno de desarrollo de código

❖ Cierta resistencia a los cambios ❖ Especialmente preparados para cambios durante el proyecto

❖ Impuestas externamente ❖ Impuestas internamente (por el equipo)

❖ Proceso mucho más controlado, con numerosas políticas/normas ❖ Proceso menos controlado, con pocos principios.

❖ El cliente interactúa con el equipo de desarrollo mediante

❖ El cliente es parte del equipo de desarrollo
reuniones

❖ Más artefactos ❖ Pocos artefactos

❖ Más roles ❖ Pocos roles

❖ Grupos grandes y posiblemente distribuidos ❖ Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio

❖ La arquitectura del software es esencial y se expresa mediante

❖ Menos énfasis en la arquitectura del software
modelos

❖ Existe un contrato prefijado ❖ No existe contrato tradicional o al menos es bastante flexible

 Valores del Manifiesto Ágil
Colaboración con
Individuos e el cliente sobre
interacciones sobre negociación
procesos y herramientas contractual Esto es, aunque
valoramos los
elementos de la
3 derecha,
1 valoramos más los de la
2 4 izquierda.
Más información:
https://agilemanifesto.org/

Software
funcionando sobre Respuesta ante el
cambio sobre
documentación
seguir un plan
extensiva
 Valores del Manifiesto Ágil
Valor 1: Individuos e Interacciones sobre Procesos y Herramientas
Individuos e
interacciones sobre El mensaje aquí es que, si bien los procesos y las herramientas
procesos y probablemente sean necesarios en nuestros proyectos, deberíamos
herramientas tratar de centrar la atención del equipo en las personas e
interacciones involucradas.

1
Esto se debe a que los proyectos son emprendidos por personas, no
herramientas, y los problemas son resueltos por personas, no procesos.
Del mismo modo, los proyectos son aceptados por personas, el
alcance es debatido por personas y la definición de un proyecto
"hecho" con éxito es negociada por personas.
Enfocarse temprano en el desarrollo de los individuos involucrados en
el proyecto y enfatizar las interacciones productivas y efectivas ayuda
a establecer un proyecto para el éxito.
 Valores del Manifiesto Ágil
Este valor habla de la necesidad de entregar. Este valor nos recuerda
que debemos centrarnos en el propósito o el valor comercial que
Individuos e intentamos entregar, en lugar del papeleo.
interacciones sobre
procesos y herramientas El enfoque ágil de la documentación es "lo suficiente, justo a tiempo, y
algunas veces, simplemente porque”. Esta frase es una taquigrafía para
recordarnos tres conceptos importantes:

1 La documentación ágil debe ser " apenas suficiente ", lo suficiente para
cubrir nuestras necesidades. Esto mantiene la mayoría de nuestros
2 esfuerzos enfocados en el sistema emergente.

La documentación ágil se realiza " justo a tiempo ", también conocida

como el" último momento responsable ", por lo que no tenemos que
Software gastar tiempo adicional para mantenerla actualizada a medida que
cambian nuestros requisitos y diseños.
funcionando sobre
Finalmente," solo porque “ nos recuerda que a veces, cuando se
documentación requiere o solicita documentación, es más fácil y preferible que
completa enfrentar las consecuencias de no hacerla.
 Valores del Manifiesto Ágil
Colaboración con el
Individuos e cliente sobre
interacciones sobre negociación contractual
procesos y herramientas
Valor 3: Colaboración del cliente sobre la negociación del contrato

Este valor nos recuerda a ser flexibles y serviciales, en lugar de ser fijos y poco cooperativos.
Es similar a la dilución entre "tener razón" y "hacer lo correcto". Podríamos construir el
producto exactamente como se especificó originalmente, pero si las preferencias o
3 prioridades del cliente cambian, sería mejor ser flexible y trabajar hacia la nueva meta, en
1 lugar de la meta que se estableció originalmente.

2 Es notoriamente difícil definir una vista inicial e invariable de lo que se debe construir. Este
desafío se deriva de la naturaleza dinámica de los productos de conocimiento,
especialmente los sistemas de software; el software es intangible y difícil de referencia, las
compañías rara vez construyen los mismos sistemas dos veces, las necesidades
comerciales cambian rápidamente y la tecnología cambia rápidamente.

Software En lugar de someter al cliente a un proceso de gestión de cambios que en realidad es más
un proceso de supresión de cambios, debemos reconocer desde el principio que las cosas
funcionando sobre van a cambiar, y tendremos que trabajar con el cliente durante todo el proyecto para
llegar a un acuerdo compartido de la definición de "hecho". Esto requiere una relación
documentación más confiable y modelos de contrato más flexibles de lo que solemos ver en los proyectos,
pero, como el valor anterior, mueve el énfasis de las actividades que no agregan valor
completa (como discutir sobre el alcance) al trabajo productivo.
 Valores del Manifiesto Ágil
Colaboración con En los proyectos de trabajo de conocimiento,
Individuos e el cliente sobre
sabemos que nuestros planes iniciales son
inadecuados, ya que se basan en información
interacciones sobre negociación
insuficiente sobre lo que se necesitará para
completar el proyecto.
procesos y herramientas contractual
Por lo tanto, en lugar de invertir esfuerzos para
intentar que el proyecto vuelva a estar en línea
con nuestro plan original, queremos gastar más
de nuestro esfuerzo y energía respondiendo a los
3 cambios que surgirán inevitablemente.
1
2 4 La intención de este valor es ampliar la cantidad
de personas que pueden participar fácilmente en
el proceso de planificación ajustando los planes y
discutiendo el impacto de los cambios.

Software
funcionando sobre Respuesta ante el
cambio sobre
documentación
seguir un plan
completa
 Principios del manifiesto Agile
9. Prestamos
1.Satisfacemos al 5. Permanecemos atención continua
cliente motivados a la excelencia
técnica

2. Aprovechamos los 6. Conversamos cara

10. Lo hacemos simple
cambios a cara

3. Entregamos productos 7. Medimos los

11. Somos
funcionales y productos
autoorganizados
frecuentemente funcionando

8. Mantenemos un 12. Mejoramos

4. Trabajamos
ritmo constante de continuamente
juntos
forma indefinida
•Scrum
Ciclo de vida Agile Scrum
Recolección de Planificación de Revisión y
Construcción
requisitos retrospectiva del
Sprint del Sprint sprint
 Contexto SCRUM
Scrum es:
Scrum se basa en la teoría de control de
Ligero procesos empírica o empirismo.

Fácil de entender Scrum emplea un enfoque iterativo e

incremental para optimizar la
predictibilidad y el control del riesgo.

El empirismo asegura que el

Extremadamente difícil conocimiento procede de la
de llegar a dominar experiencia y de tomar decisiones
basándose en lo que se conoce.
 Teoría de Scrum - Pilares
Tres pilares soportan toda la implementación del control de procesos
empírico: transparencia, inspección y adaptación

PILARES

Los aspectos significativos del proceso deben ser visibles

Transparencia para aquellos que son responsables del resultado.

Los usuarios de Scrum deben inspeccionar

frecuentemente los artefactos de Scrum y el progreso
Inspección hacia un objetivo, para detectar variaciones

Si un inspector determina que uno o más aspectos de un

proceso se desvían de límites aceptables, y que el
Adaptación producto resultante no será aceptable, el proceso o el
material que está siendo procesado deben ser ajustados.
• Roles y
Responsabilidades
Equipo Scrum
Equipo de Desarrollo
Dueño del producto
Scrum Master (Development Team)
(Product Owner)

Los Equipos Scrum son autoorganizados y multifuncionales

Entregan productos de forma iterativa e incremental,
maximizando las oportunidades de obtener retroalimentación
El Dueño de Producto (Product Owner)
El Dueño de Producto es la única persona responsable de gestionar la Lista Dueño del producto
del Producto (Product Backlog). La gestión de la Lista del Producto incluye: (Product Owner)

Expresar claramente los elementos de la Lista del Producto; Ordenar

los elementos en la Lista del Producto para alcanzar los objetivos y
misiones de la mejor manera posible

Optimizar el valor del trabajo desempeñado por el Equipo de

Desarrollo

Asegurar que la Lista del Producto es visible, transparente y clara

para todos, y que muestra aquello en lo que el equipo trabajará a
continuación

El Dueño de Producto es el responsable

de maximizar el valor del producto y del
Asegurar que el Equipo de Desarrollo entiende los elementos de la
trabajo del Equipo de Desarrollo.
Lista del Producto al nivel necesario.
El Equipo de Desarrollo (Development Team)

El Equipo de Desarrollo consiste en los

profesionales que desempeñan el trabajo de
entregar un Incremento de producto “Terminado”,
que potencialmente se pueda poner en
producción, al final de cada Sprint

Son estructurados y empoderados por la

organización para organizar y gestionar su
propio trabajo
Equipo de Desarrollo
(Development Team)
El Scrum Master
Scrum Master
Responsable de asegurar que Scrum es entendido y
adoptado

Es un líder que está al servicio del Equipo Scrum

Ayuda a las personas externas al Equipo Scrum a

entender qué interacciones con el Equipo Scrum
pueden ser de ayuda y cuáles no

Ayuda a todos a modificar estas interacciones para

maximizar el valor creado por el Equipo Scrum.
Rol del Scrum
Master
Características

✓ Entrenador: Asegura Ayuda a alcanzar su máximo

que Scrum es nivel de productividad posible
entendido y adoptado
✓ Facilitador: es un líder
que está al servicio del
Equipo Scrum
✓ Interlocutor: El Scrum
“Un socio facilitador del
Master ayuda a las
personas externas al aprendizaje, que acompaña al
Equipo Scrum a otro en una búsqueda de su
entender qué capacidad de aprender para
interacciones con el generar nuevas respuestas”
Equipo Scrum pueden Scrum Master
ser de ayuda y cuáles
no
Responsabilidades principales
Proteger al equipo de desarrollo
Velar por el correcto empleo y
de distracciones y trabas externas
evolución de Scrum
al proyecto

Facilitar el uso de Scrum a medida

que avanza el tiempo. Esto incluye la Detectar, monitorear y facilitar la
responsabilidad de que todos asistan remoción de los impedimentos que
a tiempo a las daily meetings, puedan surgir con respecto al
reviews y retrospectivas proyecto

Asegurar que el equipo de desarrollo Asegurar la cooperación y

sea multifuncional y eficiente comunicación dentro del equipo

Incentivar y motivar al Scrum Team, creando un clima de trabajo

colaborativo y fomentar la autogestión del equipo.
Aptitudes principales

✓ Contar con amplios ✓ Analítico y observador : El

✓ Amplia capacidad para la poder de observación será
conocimientos de los
resolución de problemas: fundamental a la hora de
valores y principios del
facilidad para resolver los detectar los impedimentos
agilismo, así como de las
impedimentos detectados que el Scrum Team deba
pautas organizativas y
es una característica clave. enfrentar
prácticas de Scrum

►Have few words – often only half a line

✓ Amplia vocación de servicio: debe ser
servicial al Scrum Team.
✓ Saber incentivar y motivar
El Servicio del Scrum Master al Dueño de
Producto
Ayudar al Equipo Entender la
Encontrar técnicas
Scrum a entender
para gestionar la planificación
la necesidad de
Lista de Producto
contar con del producto
de manera en un
elementos de Lista
efectiva. entorno
de Producto claros
y concisos. empírico.

Entender y
practicar la
agilidad.
Asegurar que el
Dueño de Producto Facilitar los eventos
Dueño del producto conozca cómo
Scrum Master de Scrum según se
(Product Owner) ordenar la Lista de
Producto para requiera o
maximizar el valor. necesite.
El Servicio del Scrum Master al Equipo de Desarrollo

Guiar al Equipo de Ayudar al Equipo Eliminar

Desarrollo en ser de Desarrollo a impedimentos para
autoorganizado y crear productos de el progreso del
Equipo de Desarrollo multifuncional. alto valor. Equipo de
(Development Team) Scrum Master Desarrollo.

Guiar al Equipo
de Desarrollo en
el entorno de
Facilitar los organizaciones en
eventos de las que Scrum
Scrum según se aún no ha sido
adoptado y
requiera o entendido por
necesite. completo
El Servicio del Scrum Master a la Organización

Liderar y guiar a Planificar las Ayudar a los

la organización implementaciones empleados e
en la adopción de Scrum en la interesados a
organización. entender y
de Scrum.
llevar a cabo
Scrum y el
desarrollo
Scrum Master Organización empírico de
producto.

Motivar cambios Trabajar con otros

que Scrum Masters
incrementen la para incrementar
productividad la efectividad de
del Equipo la aplicación de
Scrum. Scrum en la
organización.
Coaching del equipo
“El coaching de Scrum se
define como el trabajo
realizado en una o más
organizaciones durante el
cual el coach actúa
como mentor o
facilitador de esos
equipos para mejorar su
entendimiento y
aplicación de Scrum a fin
de obtener su objetivos”
 Coaching del equipo
Un coach guía a los individuos que conforman una
organización de las siguientes formas:
El rol de Scrum
Master debe liderar
► Consejo y consultoría para mejorar y la adopción y
acelerar el proceso de definición del
autodescubrimiento proceso tanto para
el equipo Scrum
► Facilitación de la adopción,
como para el resto
implementación y aprendizaje de Scrum de la organización.
► Liderazgo ágil, basado en un estilo de
liderazgo servil
► Desarrollo organizacional que mejore las
habilidades, recursos y creatividad
existentes en el cliente
Apoyo del Scrum Master
en los eventos de Scrum
Ciclo de vida Agile Scrum
Recolección de Planificación de Revisión y
Construcción
requisitos retrospectiva del
Sprint del Sprint sprint
 Eventos de Scrum
Existen eventos predefinidos con el fin de crear
regularidad y minimizar la necesidad de reuniones
no definidas en Scrum.

❖ El Sprint es un contenedor para todos los demás eventos.

❖ Cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar los artefactos Scrum.
❖ Estos eventos están diseñados específicamente para habilitar la transparencia requerida.
❖ No operar cualquier evento según lo prescrito resulta en la pérdida de oportunidades para
inspeccionar y adaptarse.
❖ Los eventos se utilizan en Scrum para crear regularidad y minimizar la necesidad de reuniones no
definidas en Scrum.

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

Es el corazón de Scrum

Time-box: Máximo un mes o

menos durante el cual se crea
un incremento de producto
“Terminado”, utilizable y
potencialmente desplegable Scrum Master

Sprint Planning Meeting • Facilita los eventos

Daily Scrums
Trabajo de desarrollo
Sprint Review
Sprint Retrospective
• Elimina impedimentos
• Conoce el grado de motivación
• Enseña al equipo a autogestionarse
Eventos de Scrum - El Sprint

Contienen y consisten en:

✓ Reunión de Planificación del
Es el corazón de Scrum Sprint (Sprint Planning Meeting)
✓ Scrums Diarios (Daily Scrums)
✓ Trabajo de desarrollo
✓ Revisión del Sprint (Sprint
Review)
✓ Retrospectiva del Sprint (Sprint
Time-box: Máximo un mes o menos Retrospective).
durante el cual se crea un incremento
de producto “Terminado”, utilizable y
potencialmente desplegable
Eventos de Scrum - Durante el Sprint

No se realizan cambios Los objetivos de calidad El alcance puede ser

que puedan afectar al no disminuyen. clarificado y
Objetivo del Sprint (Sprint renegociado entre el
Goal) Dueño de Producto y el
Equipo de Desarrollo a
medida que se va
aprendiendo más.
Durante el Sprint…
No se realizan cambios que pongan en peligro el Objetivo del
Sprint;
❖ La calidad no disminuye;
❖ El Product Backlog se refina según sea necesario; y,
❖ El alcance se puede aclarar y renegociar con el Product Owner
a medida que se aprende más.
❖ Los Sprints permiten la previsibilidad al garantizar la
inspección y adaptación del progreso hacia un Objetivo del
Producto al menos cada mes calendario.
❖ Cuando el horizonte de un Sprint es demasiado largo, el
Objetivo del Sprint puede volverse inválido, la complejidad
puede crecer y el riesgo puede aumentar.
❖ Se pueden emplear Sprints más cortos para generar más ciclos
de aprendizaje y limitar el riesgo de costo y esfuerzo a un
período de tiempo menor. Cada Sprint puede considerarse un
proyecto corto.
Durante el Sprint…
❖ Existen varias prácticas para pronosticar el
progreso, como el trabajo pendiente
(burn‐downs), trabajo completado (burn‐ups) o
flujos acumulativos (cumulative flows).
❖ Si bien han demostrado su utilidad, no
reemplazan la importancia del empirismo.
❖ En entornos complejos, se desconoce lo que
sucederá.
❖ Solo lo que ya ha sucedido se puede utilizar para
la toma de decisiones con miras al futuro.
❖ Un Sprint podría cancelarse si el Objetivo del
Sprint se vuelve obsoleto.
❖ Solo el Product Owner tiene la autoridad para
cancelar el Sprint.
Reunión de Planificación de Sprint
(Sprint Planning Meeting)
El trabajo a realizar durante
el Sprint se planifica en la
Reunión de Planificación de
Sprint
Participantes:
Equipo Scrum completo
Time-box: Máximo ocho
horas
❖Se asegura de que el
evento se lleve a cabo
❖enseña al Equipo Scrum a
mantenerse dentro del
bloque de tiempo
❖Asiste al Equipo Scrum en
estimar el esfuerzo necesario
para completar las tareas
acordadas para el Sprint
❖Asiste al Equipo Scrum en el
desarrollo del Sprint backlog
y gestiona el Burndown
chart del Sprint
Scrum Master
Sprint Planning
❖En un proyecto Scrum, cada sprint comienza
con Sprint Planning Meeting.
❖El objetivo principal solo debería ser planificar
el sprint.
❖Asegúrese de que todos los miembros del
equipo asistan a la reunión, incluidos el Product
Owner, Scrum Master y el Scrum Team.
❖También puede incluir recursos a tiempo parcial
para esta reunión.
❖Esto brinda una oportunidad importante para
que el equipo Scrum seleccione cuánto trabajo
pueden hacer en el próximo sprint.
Sprint Planning
❖ El Sprint Planning Meeting Basado, se divide en ocho horas
para un Sprint de un mes y se divide en dos partes: Definición
de objetivos y Estimación de tareas.

❖ 1. Definición del objetivo: durante la primera mitad de la

reunión, el Product Owner explica las Historias de usuario de
mayor prioridad o los requisitos en el Prioritized Product
Backlog al Scrum Team. El equipo Scrum, en colaboración con el
propietario del producto, define el objetivo del Sprint.

❖ 2. Estimación de tareas: durante la segunda mitad de la

reunión, el equipo Scrum decide "cómo" completar los
elementos priorizados del backlog de productos seleccionados
para cumplir con la meta del Sprint.
Sprint Planning
❖ La Sprint Planning inicia el Sprint al establecer
el trabajo que se realizará para el Sprint.
❖ El Scrum Team crea este plan resultante
mediante trabajo colaborativo.
❖ El Product Owner se asegura de que los
asistentes estén preparados para discutir los
elementos más importantes del Product
Backlog y cómo se relacionan con el Objetivo
del Producto.
❖ El Scrum Team también puede invitar a otras
personas a asistir a la Sprint Planning para
brindar asesoramiento..
Sprint Planning
❖ La Sprint Planning aborda los siguientes temas:

❖ Tema uno: ¿Por qué es valioso este Sprint?

❖ El Product Owner propone cómo el producto
podría Incrementar su valor y utilidad en el Sprint
actual.
❖ Luego, todo el Scrum Team colabora para definir
un Objetivo del Sprint que comunica por qué el
Sprint es valioso para los interesados.
❖ El Objetivo del Sprint debe completarse antes de
que termine la Sprint Planning.
Sprint Planning
❖ Tema dos: ¿Qué se puede hacer en este Sprint?
❖ A través de una conversación con el Product Owner,
los Developers seleccionan elementos del Product
Backlog para incluirlos en el Sprint actual.
❖ El Scrum Team puede refinar estos elementos durante
esteproceso, lo que aumenta la comprensión y la
confianza.
❖ Seleccionar cuánto se puede completar dentro de un
Sprint puede ser un desafío.
❖ Sin embargo, cuanto más sepan los Developers sobre
su desempeño pasado, su capacidad actual y su
Definición de Terminado, más confiados estarán en
sus pronósticos para el Sprint.
Sprint Planning
❖ Tema tres: ¿Cómo se realizará el trabajo elegido?

❖ Para cada elemento del Product Backlog

seleccionado, los Developers planifican el trabajo
necesario para crear un Increment que cumpla con la
Definición de Terminado.
❖ A menudo, esto se hace descomponiendo los
elementos del Product Backlog en elementos de
trabajo más pequeños de un día o menos.
❖ La forma de hacerlo queda a criterio exclusivo de los
Developers.
❖ Nadie más les dice cómo convertir los elementos del
Product Backlog en Increments de valor.
❖ El Objetivo del Sprint, los elementos del Product
Backlog seleccionados para el Sprint, más el plan para
entregarlos se denominan juntos Sprint Backlog.
Scrum Diario (Daily Scrum)
Es una reunión para que el Equipo de
Desarrollo sincronice sus actividades y
cree un plan para las siguientes 24 horas

Time-box: 15 minutos
Scrum Master

Misma hora y en el mismo • Se asegura de que el evento se lleve a

lugar todos los días cabo
• enseña al Equipo Scrum a mantenerse
Preguntas dentro del bloque de tiempo
¿Qué hice ayer? • Actualiza el tablero de tareas (Scrum
¿Qué haré hoy? Taskboard)
¿Veo algún • Actualiza la lista de impedimentos
impedimento?
Scrum Diario (Daily Scrum)
❖ Si el Product Owner o Scrum Master
están trabajando activamente en
elementos del Sprint Backlog, participan
como Developers.
❖ Los Developers pueden seleccionar la
estructura y las técnicas que deseen,
siempre que su Daily Scrum se centre en
el progreso hacia el Objetivo del Sprint y
produzca un plan viable para el siguiente
día de trabajo.
❖ Esto crea enfoque y mejora la
autogestión.
Scrum Diario (Daily Scrum)
❖ Una parte integral del proceso Scrum es la reunión diaria de
Scrum, que es un ritual regular que se practica todas las
mañanas.
❖ El equipo se reúne cada día laborable aproximadamente a la
misma hora para discutir el estado del proyecto.
❖ Los sinónimos de la reunión Daily Scrum incluyen "Daily Stand
up", "Daily Scrum" y "Scrum Meeting", entre otros.
❖ La reunión es una reunión informal de todos los miembros del
equipo que se reúnen en un círculo.
❖ El objetivo mismo de esta reunión es asegurar una mejor
coordinación entre los miembros del equipo que trabajan hacia
el objetivo final.
❖ La reunión de Scrum no debe confundirse con la reunión de
estado, una reunión para proporcionar actualizaciones de
estado a la gerencia u otras partes interesadas.
❖ Se agradece la participación activa de cada miembro del equipo
junto con un alto grado de sinceridad.
Scrum Diario (Daily Scrum)
❖ Las Daily Scrums mejoran la comunicación,
identifican impedimentos, promueven la
toma rápida de decisiones y, en
consecuencia, eliminan la necesidad de
otras reuniones.
❖ La Daily Scrum no es el único momento en
el que los Developers pueden ajustar su
plan.
❖ A menudo se reúnen durante el día para
discusiones más detalladas sobre cómo
adaptar o volver a planificar el resto del
trabajo del Sprint.
Revisión de Sprint (Sprint Review)
Sirve para inspeccionar el
Incremento y adaptar la
Lista de Producto si fuese
necesario
Time-box: 4 horas
Tiene como objetivo facilitar
la retroalimentación de
información y fomentar la
colaboración.
Scrum Master
• Se asegura de que el evento se lleve a
cabo
• enseña al Equipo Scrum a mantenerse
dentro del bloque de tiempo
• Facilita la presentación de los
Entregables por el Equipo Scrum para
la aprobación del Product Owner
Revisión de Sprint (Sprint Review)
❖ El Sprint Review es uno de los cinco eventos de Scrum, y
ocurre en el final del Sprint, para inspeccionar el
incremento y adaptar el Product Backlog en caso de que
sea necesario.
❖ Es una gran oportunidad para poder recibir feedback
sobre el desarrollo del producto.
❖ Es una reunión informal, y el objetivo principal del Sprint
Review es brindar transparencia tanto al equipo como al
cliente
❖ Tiene una duración de 4 horas para Sprints de 4 semanas.
Para Sprints más cortos, esta reunión tenderá a ser más
corta.
❖ Este evento es organizado por el Product Owner, y es
necesaria la presencia de todo el equipo de Scrum.
❖ El rol del Scrum Master es asegurar que el evento ocurre y
que cumple los tiempos establecidos, además de asegurar
una colaboración de todo el equipo.
Revisión de Sprint (Sprint Review)
❖ El propósito de la Sprint Review es inspeccionar
el resultado del Sprint y determinar futuras
adaptaciones.
❖ El Scrum Team presenta los resultados de su
trabajo a los interesados clave y se discute el
progreso hacia el Objetivo del Producto.
❖ Durante el evento, el Scrum Team y los
interesados revisan lo que se logró en el Sprint y
lo que ha cambiado en su entorno.
❖ Con base en esta información, los asistentes
colaboran sobre qué hacer a continuación.
❖ El Product Backlog también se puede ajustar para
satisfacer nuevas oportunidades.
❖ La Sprint Review es una sesión de trabajo y el
Scrum Team debe evitar limitarla a una
presentación.
Revisión de Sprint (Sprint Review)
CARACTERÍSTICAS DEL SPRINT REVIEW
❖ El Product Owner se encarga de organizar e invitar al evento
tanto al cliente como a todo el equipo Scrum.
❖ El Product Owner explica qué items del Product Backlog han
sido finalizados, y cuáles no. Es importante tener en cuenta
que las tareas terminadas deben respetar el Definition of
Done.
❖ El equipo de desarrollo se encarga de hacer la demostración
del incremento terminado durante el Sprint.
❖ El equipo de desarrollo, principalmente, responderá a
cuestiones relacionadas con el incremento. La normal es que
la mayoría de las preguntas sean técnicas.
❖ El Product Owner comenta sobre el estado del Product
Backlog.
❖ Se realiza una review del proyecto, y sobre qué es lo siguiente
que se hará. En base a esto, el Product Owner se encarga de
reorganizar el Product Backlog en caso de que surgiera
feedback por parte del cliente.
❖ Se hace una review sobre tiempos, presupuesto y alcance del
proyecto para futuros Sprints.
Revisión de Sprint (Sprint Review)
❖ ¿Qué se obtiene como resultado?
❖ El resultado del Sprint Review es un
Product Backlog revisado y organizado,
que probablemente definirá los items a
realizar en el siguiente Sprint.
❖ Conseguimos además un mejor
alineamiento con negocio con entrega
continua y reducir desviaciones.

❖ Además, confirmaremos el incremento

de producto, por el feedback que nos
dará el cliente.
Retrospectiva de Sprint
(Sprint Retrospective)
Es una oportunidad para el
Equipo Scrum de
inspeccionarse a sí mismo y
crear un plan de mejoras que
sean abordadas durante el
siguiente Sprint.

Time-box: 3 horas
Scrum Master

• Se asegura de que el evento se lleve a cabo

Tiene lugar después de la
Revisión de Sprint y antes de
la siguiente Reunión de
Planificación de Sprint
• enseña al Equipo Scrum a mantenerse dentro del
bloque de tiempo
• Se asegura que exista un ambiente ideal para el
Equipo Scrum del proyecto en los sucesivos Sprints
Retrospectiva de Sprint (Sprint Retrospective)

❖ Sprint Retrospective es una reunión

convocada por el Scrum Master en la que el
equipo habla sobre el sprint anterior y decide
cómo hacer que el siguiente sprint sea
productivo.
❖ Esta reunión difiere de una reunión de
Revisión de Sprint.
❖ En la reunión de revisión de Sprint, el equipo
analiza en qué está trabajando actualmente,
mientras que la reunión retrospectiva habla
sobre cómo están trabajando.
Retrospectiva de Sprint (Sprint Retrospective)

❖ El propósito de la Sprint Retrospective es planificar formas

de aumentar la calidad y la efectividad.
❖ El Scrum Team inspecciona cómo fue el último Sprint con
respecto a las personas, las interacciones, los procesos, las
herramientas y su Definición de Terminado.
❖ Los elementos inspeccionados suelen variar según el
ámbito del trabajo.
❖ Se identifican los supuestos que los llevaron por mal
camino y se exploran sus orígenes.
❖ El Scrum Team analiza qué salió bien durante el Sprint, qué
problemas encontró y cómo se resolvieron (o no) esos
problemas.
❖ El Scrum Team identifica los cambios más útiles para
mejorar su efectividad.
❖ Las mejoras más impactantes se abordan lo antes posible.
❖ Incluso se pueden agregar al Sprint Backlog para el
próximo Sprint.
• Artefactos de Scrum
Artefactos de Scrum
Es responsabilidad del Scrum Los artefactos de Scrum
Master garantizar la transparencia de representan trabajo o
los artefactos a través de: valor en diversas formas
• La inspección de los propios que son útiles para
artefactos, proporcionar
• el reconocimiento de patrones, transparencia y
oportunidades para la
• La escucha activa de todo lo que inspección y adaptación.
se dice
• La detección de diferencias entre
los resultados esperados y los reales
Scrum Master

Product Backlog Sprint Backlog Increment

Lista de Producto (Product Backlog)
Características:
❖ Es una lista ordenada de todo lo que podría ser necesario en el
producto (características, funcionalidades, requisitos, mejoras etc)
❖ Es la única fuente de requisitos para cualquier cambio a realizarse en
el producto.
❖ Evoluciona a medida de que el producto y el entorno en el que se
usará también lo hacen
❖ Es un artefacto vivo.
❖ El Dueño de Producto (Product Owner) es el responsable de la Lista
de Producto
Refinamiento (refinement) de la Lista de
Producto

Los elementos de la Lista

de Producto que
pueden ser
“Terminados” por el
Acto de añadir detalle, Equipo de Desarrollo en El Equipo de Desarrollo
El Equipo Scrum decide
estimaciones y orden a un Sprint son es el responsable de
cómo y cuándo se hace
los elementos de la Lista considerados proporcionar todas las
el refinamiento
de Producto “preparados” o estimaciones.
“accionables” para ser
seleccionados en una
reunión de Planificación
de Sprint.
Lista de Pendientes del Sprint (Sprint Backlog))

Elementos
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 Objetivo del Sprint
Visibilidad
La Lista de Pendientes del Sprint
hace visible todo el trabajo que el
Equipo de Desarrollo identifica
como necesario para alcanzar el
Objetivo del Sprint.
Incremento

Es la suma de todos los

elementos de la Lista de Al final de un
Producto completados
Sprint, el nuevo
durante un Sprint y el
valor de los incrementos Incremento debe
de todos los Sprints estar “Terminado”
anteriores
Definición de “Terminado” (Definition of Done)

Todo el mundo debe La definición de “Terminado”

entender lo que significa garantiza la transparencia y la
“Terminado” calidad

Los Equipos Scrum deben

Los miembros del Equipo deben
tener un entendimiento definir en conjunto la
compartido de lo que significa definición de “Terminado”
que el trabajo esté completado,
para asegurar la transparencia
Estimación,
Planificación Y
Seguimiento
en Un
Contexto Ágil
Ciclo de vida Agile Scrum
Recolección de Planificación de Revisión y
Construcción
requisitos retrospectiva del
Sprint del Sprint sprint
Historias de usuario

¿Qué es una historia de usuario?

► Son utilizadas en los métodos ágiles para la Ayuda y asesora
especificación de requisitos al Product Owner
► Son una descripción breve de una a encontrar
funcionalidad tal y como la percibe el nuevas técnicas
usuario de estimación y
priorización
► Describen lo que el cliente o el usuario
quiere que se implemente y se escriben
con una o dos frases utilizando el lenguaje
común del usuario
Scrum Master
Ventajas que aportan las historias de usuario
Al ser muy cortas,
Necesitan poco Mantienen una
representan relación cercana
requisitos del mantenimiento. con el cliente.
modelo de negocio
que pueden
implementarse
rápidamente días o
semanas

Permiten dividir Permiten

los proyectos estimar
en pequeñas fácilmente Son ideales para
entregas. el esfuerzo proyectos con
de requisitos
desarrollo. volátiles o no
muy claros.
Épicas
✓ Es una súper historia de
usuario que se distingue
por su gran tamaño
✓ Tienen una alta
granularidad
✓ El equipo la descompone
en historias de usuario con
un tamaño más
adecuado para ser
gestionadas
Información en una historia de usuario

Es preferible no
adoptar
formatos rígidos

Los resultados de
scrum y agilidad
no dependen de
las formas, sino
de la adaptación
de sus principios
 Estimación: Esfuerzo
Prioridad: permite
ID: identificador de la necesario en tiempo
Descripción: descripción determinar el orden en
historia de usuario, único ideal de
sintetizada de la historia el que las historias de
para la funcionalidad o implementación de la
de usuario. usuario deben de ser
trabajo historia de usuario. story
implementadas
points

Descripción: Debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se

quiere? y ¿Cuál es el beneficio?
Como [rol del usuario], quiero [objetivo], para poder

Ejemplo: Como usuario registrado quiero poner artículos en el carrito de

compras para armar mi pedido
Criterios de aceptación

Uno de ellos es el método SMART en el

que se han de cumplir en lo máximo
Los criterios de aceptación ayudan al
equipo de desarrollo a entender el posible los siguientes criterios:
funcionamiento del producto, de manera
que estimarán mejor el tamaño de la
historia de usuario. Specific (Específicos)
Measurable (Medibles)
Achievable (Alcanzables)
Relevant (Relevantes)
Time-boxed (Limitados en el
Existen diversos métodos tiempo)
para medir la calidad de los
criterios de aceptación.
Calidad En Las Historias De Usuario
Para asegurar la calidad en la escritura de historias de usuario se
sugiere el método INVEST
El método sirve para comprobar la calidad de una historia de
usuario revisando que cumpla una serie de características:
• I - Independent (independiente): debe ser autónomo
• N - Negotiable (negociable): puede ser cambiado o reescrito
• V - Valuable (valiosa): entregar valor al usuario final.
• E - Estimable (estimable): siempre se puede estimar
• S - Small (pequeña): no debe ser tan grande que sea
imposible planificar o priorizar con un nivel de certeza
• T - Testable (comprobable): debe ser medible con un
resultado esperado conocido
Priorización de historias de usuario
Los items del backlog de producto,
deben guardar un orden de prioridad,
cuya base se apoye en:
Asegura que el Dueño de
✓ Beneficios de implementar una Producto conozca cómo
funcionalidad ordenar la Lista de Producto
✓ Pérdida o costo que demande para maximizar el valor
posponer la implementación de una
funcionalidad
✓ Riesgos de implementarla
✓ Coherencia con los intereses del
negocio
✓ Valor diferencial con respecto a Scrum Master
productos de la competencia.
Técnica MoSCoW para priorización del Product Backlog

(es necesario): se debe tener la funcionalidad implementada en la solución, sino

M - MUST HAVE esta fallará o la solución no puede ser considerada un éxito.

(es recomendable): se debería tener la funcionalidad implementada en la solución ya

que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si no
S - SHOULD HAVE
existe pero debería de haber causas justificadas para no implementarla

(podría implementarse): es deseable, por tanto sería conveniente tener esta

C - COULD HAVE funcionalidad implementada en la solución, dependerá de las posibilidades de los
tiempos y el presupuesto del proyecto.

(no lo queremos): se trata de una funcionalidad de muy baja prioridad o descartada en

W - WON'T HAVE ese momento, pero que en futuro pueda ser relevante. Posteriormente, cuando cobre
importancia, puede pasar a alguno de los estados anteriores.
 Estimación ágil
utilizando planning
poker
El Punto Historia O Story Point
La medida que utilizamos es el punto historia o story
point. Un punto historia es mezcla de:

✓ Complejidad: Una historia que es más compleja El Scrum Master

que otra tendrá más puntos historia. podrá ser quien
✓ Esfuerzo: Quizás una historia no tiene complejidad actúa de
pero si requiere esfuerzo (ejemplo: Crear Web moderador del
Services de integración para varias aplicaciones), juego
también tendrá más puntos historia que otra más
corta.
✓ Incertidumbre o riesgo: Es la probabilidad de que
algo no esperado aparezca en la historia de Scrum Master
usuario, siempre por falta de información previa.
Estimación ágil utilizando planning poker

La baraja de Scrum Poker, cuenta

además con dos cartas adicionales:

Una taza de café, que significa

“Hagamos una pausa”

Un signo de interrogación, que

puede significar “No estoy
seguro del esfuerzo que
demanda” o también “No
entendí muy bien los
requerimientos”.
Estimación ágil utilizando planning poker
✓ Baraja de cartas numeradas siguiendo
la serie de Fibonacci.
✓ Serie de Fibonacci: Se compone de
una serie lógica donde cada número
es la suma de los dos anteriores:

A menor número, menor esfuerzo

demanda una Historia de Usuario. Y
cuanto más elevado es el valor, mayor
esfuerzo.
Fuente imagen: http://store.mountaingoatsoftware.com/products/planning-poker-cards
¿Cómo jugar?
✓ Cada integrante del Equipo posee en sus manos una
baraja de cartas con los números correspondientes a la
sucesión de Fibonacci
✓ El Product Owner presenta una historia de usuario para ser
estimada. El Scrum
✓ Todos los participantes proceden a realizar su estimación Master
en forma secreta, sin influenciar al resto del Equipo,
poniendo su carta elegida boca abajo sobre la mesa. podrá ser
✓ Una vez que todos los integrantes han estimado, se dan
vuelta las cartas y se discuten principalmente los extremos.
quien actúa
✓ Al finalizar la discusión se levantan las cartas y se vuelve a de
estimar, esta vez con mayor información que la que se
tenía previamente. moderador
✓ Las rondas siguen hasta que se logra consenso en el Equipo del juego
y luego se continúa desde el punto número uno con una Scrum Master
nueva historia de usuario
Conceptos de tamaño y velocidad

La velocidad
es la cantidad
de story
points que
se completan
por iteración En dos o tres-
iteraciones(Sprint)
, se podrá estimar
la velocidad del
equipo y por lo
tanto el tamaño y
duración del
proyecto.
Velocidad del equipo
La velocidad del equipo en Story Point o puntos historia.

Por ejemplo: un equipo de 3 personas hace en

promedio 52 Story Point en un Sprint de 4 semanas. Con
esta velocidad el equipo puede tomar historias de
usuario que sumen máximo 52 Story Point.

Luego, se realiza el Tasking, aquí se define el número de

horas por cada tarea a realizar de la Historia de Usuario,
el número de horas debe ser par y una tarea no debe
superar las 8 horas.
Equipo de Desarrollo
Una vez realizado el Tasking se realiza el tiempo de
(Development Team)
dedicación del recurso humano. Ver ejemplo
 Los tableros de tareas
Su objetivo principal es favorecen la
gestionar de manera comunicación directa
general como se van
completando tareas del equipo al actualizar
la información en
reuniones frente a ellas
Se basa en un tablero
dividido en columnas las además de compartir la
cuales representan el visibilidad de la
estado por el que una tarea
puede pasar
evolución del proyecto
con todos los implicados
Consta de tres columnas: El Scrum Master
Pendiente, En progreso y
Terminado facilita la gestión
del tablero de
tareas
 La exposición de las tareas
facilita la detección temprana
de problemas al monitorizar
continuamente la evolución del
proyecto.

La actualización de la
información just-in-time, ayuda a
identificar en un primer
momento los posibles
impedimentos, problemas y
riesgos.
Utilizando un tablero de tareas
Columnas utilizadas
✓ Pendiente
✓ En Progreso
✓ Hecho
Cada columna
visualiza el estado de
las actividades y las
filas representan los
diferentes tipos de
actividades
• Monitoreo del Progreso
Monitoreo de progreso - Gráfico de
producto(BurnUp)
Es una herramienta de
planificación del propietario del
producto, que muestra visualmente
la evolución previsible del
producto.

Proyecta en el tiempo su
construcción, con base a la
velocidad del equipo

(En el eje Y del gráfico se registra

el tiempo medido en Sprints o en
tiempo real y en el eje X el
esfuerzo estimado para construir
las diferentes historias de la lista
de producto
Monitoreo de progreso (Burndown Chart)
La gráfica Burn Down representa el
trabajo pendiente de realizar a lo largo
del tiempo, es decir, la velocidad a la
que se están completando los objetivos

Lo actualiza el equipo en el scrum,

para comprobar si el ritmo de avance
es el previsto, o se puede ver
comprometida la entrega del sprint.

La estrategia ágil para el seguimiento

del proyecto se basa en:
Medir el trabajo que falta, no el
realizado.
Seguimiento cercano del avance
Monitoreo de progreso (Burndown Chart)
❖Día a día cada miembro del equipo
actualiza en la Lista de Pendientes del
Sprint el tiempo que le queda a las
tareas que va desarrollando, hasta que
se terminan quedando a cero el
tiempo pendiente.
❖Con esta información se actualiza el
gráfico poniendo cada día el esfuerzo
pendiente total de todas las tareas que
aún no se han terminado (en el eje Y
del gráfico se registra el trabajo que
aún falta por realizar y en el eje X se
detallan los días del Sprint)