Curso de formación y certificación

SCRUM PRODUCT OWNER

 Valores

Misión
Compromiso con el éxito Enfoque a valor y trabajo Facilitar el entendimiento y la aplicación del
de nuestros clientes. en equipo. conocimiento para el éxito de las personas y
organizaciones.

Visión 2025
Transparencia,
Aprendizaje, mejora e
confidencialidad y honestidad Ayudar a 10 millones de personas a
innovación continua.
en todo. mejorar sus resultados en proyectos y
transformación organizacional.
 Agilizando Mentes, Que mejoren vidas.
Ingeniero Industrial y
Maestro en Coaching Directivo.
Experto en prácticas ágiles, mejora de procesos,
innovación, administración proyectos y
transformación organizacional.
• Más de 23 certificaciones y estudios de posgrado
internacionales.
• Más de 17 años de experiencia en Pymes y Corporativos
transnacionales.
• Más de 6,000 profesionales, líderes y directores formados
exitosamente.
• Fundador de KzI-Kaizenia – Miembro del PMI.
• Creador de la certificación internacional Agile Coach y
cocreador de Innovación Management (con Certiprof).

Project Management
Professional PMP

Expert Scrum Master &

SAFe SA

Certified Professional in
Agile Coaching
www.diegoochoa.com
AGENDA
WORK IN
TO DO DONE
PROCESS

S1
S1

S3
S2

S4 S5

S6
 Objetivo del curso

Identificar, definir, validar y priorizar soluciones de

gran valor para el área u organización con la que
colabores como Scrum Product Owner.
 Estrategia para lograrlo

✓ Repaso de materiales
✓ Ánimos de pensar y aplicar
✓ Sin miedo a fallar
✓ Probar, aprender y mejorar
✓ Compartir con los Coaches. Certificarse
✓ Participación activa.
✓ Apertura a desaprender.
Aplicar y ▪ Repasar los materiales de estudio.
▪ Realizar las pruebas.
✓ Realizar las practicas.
✓ Esfuerzo de atención.
aprender ▪ Presentar y acreditar examen:
• 40 preguntas 60 minutos.
✓ Apertura a la tecnología • 80% de calificación para acreditar.
• 30 días a partir de concluir las

Sesiones
sesiones virtuales

Virtuales
Certificación

• El acceso al examen de certificación se les envía por correo el día

siguiente de la última sesión virtual.

• A partir de ese momento cuentan con 30 días para realizar y aprobar el

examen.

• Cuentan con 2 intentos para aprobar el examen, ambos intentos deben

realizarse dentro de los 30 días naturales posteriores al término de las
sesiones virtuales.

• El examen consta de 40 preguntas de opción múltiple

• Porcentaje mínimo de aciertos para aprobación:80% (32 de 40)

• Tiempo: 60 minutos

• Una vez obtenido el certificado digital, éste debe enviarse a

servicios@kzi.mx
¿Nos permites conocerte mejor?

☺ Vamos a Mural ☺
AGENDA
WORK IN
TO DO DONE
PROCESS

S1 S1

S3
S2

S4 S5

S6
 AGILIDAD

Ser capaz de moverse y responder rápidamente a los cambios, para crear

productos y/o servicios basados en valor, en ambientes de turbulencia.
BENEFICIOS DE AGILE

+ Gestión de cambios

+ Visibilidad de
proyectos

+ Alineación entre
Negocio e IT

+ Motivación de equipos

+ Velocidad y
Productividad
Fuente: The 13th annual State of Agile report 2019
MARCOS
ÁGILES

AGILE COACH
Más habilidades de enseñanza, facilitación, mentoring y coaching profesional
FUNDAMENTOS
AGILIDAD
 ¿Qué imagen representa mejor la
agilidad?
1 2
 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
Los 12 temprana y continua de software valioso.

principios 2. Aceptamos que los requisitos cambien, incluso en etapas tardías

del desarrollo. Los procesos Ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas

y dos meses, de preferencia al menor tiempo posible.

4. Los responsables de negocio y los desarrolladores deben trabajar

juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay

que darles el entorno y el apoyo que necesitan, y confiarles la ejecución
del trabajo.

6. El método más eficiente y efectivo de comunicar información al

equipo de desarrollo y entre sus miembros es la conversación cara a
cara.

Fuente SBOK 3erd Edition

 7. El software funcionando es la medida principal de progreso.
Los 12
principios 8. Los procesos ágiles promueven el desarrollo sostenible. Los
patrocinadores, desarrolladores y usuarios deben ser capaces de
mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño,

mejora la agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no

realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de

equipos autoorganizados.

12. A intervalos regulares, el equipo reflexiona sobre cómo ser más

eficaz para después ajustar y perfeccionar su comportamiento según
corresponda.

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

Enumera seis valores de gestión necesarios para

reforzar una mentalidad de desarrollo ágil,
particularmente en la gestión de proyectos complejos e
inciertos.

Declaración de Interdependencia
VALORES
 Declaración de Interdependencia
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 la superamos a través de iteraciones, anticipación y adaptación.
4. Damos rienda suelta a la creatividad y la innovación al reconocer que las personas son la fuente máxima
de valor y creamos un entorno en el que puedan tener un impacto positivo.
5. Aumentamos el rendimiento a través de la rendición de cuentas por parte del grupo en cuestión de
resultados y eficacia del equipo, responsabilidades que todos comparten.
6. Mejoramos la eficacia y la fiabilidad a través de estrategias situacionalmente específicas, procesos y
prácticas.
¿Aterrizamos esto a
nuestra realidad?
AGENDA
WORK IN
TO DO DONE
PROCESS

S2 S1

S3

S1

S4 S5

S6
SCRUM

Marco que emplea

enfoques iterativos y
adaptativos para
desarrollar productos y
servicios de la forma
más rápida y flexible
para entregar el mayor
valor en el menor
tiempo posible.
 Flujo
EN TUS Scrum
PALABRAS

¿QUÉ ES SCRUM?
 RESPONSABLES ROLES
PRINCIPALES NO PRINCIPALES

Involucrados
Clientes
Clientes Usuarios
Patrocinadores
Servicios
compartidos
Compras
Soporte
Desarrolladores
Legal
Cuerpo de
Conocimiento
CAPACIDADES DE LOS RESPONSABLES PRINCIPALES

Scrum Master Scrum Product Owner Desarrolladores

• Facilitador de scrum
• Dominio del Negocio • Expertis Técnico
• Líder Servicial
• Especialista en Scrum • Conocimientos en Scrum
• Gestión de equipo
• Excelentes habilidades de • Colaborativo y Auto
• Moderador
comunicación y negociación organizado
• Resolución de problemas
• Gestión de incertidumbre • Proactivo e Inter funcional
• Perceptivo
• Accesible y Proactivo • Responsable e Intuitivo
• Coach-Mentor
• Decisivo y Pragmático • Introspectivo y muy
• Accesible
• Orientado a objetivos motivado
• Introspectivo
RESPONSABILIDADES DEL SCRUM MASTER
CON EL PRODUCT OWNER
RESPONSABILIDADES DEL SCRUM MASTER
CON LA ORGANIZACIÓN

Planifica la Ayuda al Scrum Team

Lidera y guía a la
implementación de (PO y DT) y Stakeholders
organización en la
Scrum en la a entender y llevar a
adopción de Scrum
organización cabo Scrum

Motiva cambios que Trabaja de la mano de

incrementen la otros Scrum Master
productividad del para incrementar la
Scrum Team (PO y DT) efectividad de Scrum
RESPONSABILIDADES DEL SCRUM MASTER
CON LOS DESARROLLADORES
RESPONSABILIDADES DE
LOS DESARROLLADORES
 CARACTERÍSTICAS DE
LOS DESARROLLADORES
RESPONSABILIDADES DEL
PRODUCT OWNER
RESPONSABILIDADES DEL
PRODUCT OWNER
CARACTERÍSTICAS DEL
PRODUCT OWNER
ASPECTOS Y PRINCIPIOS DE SCRUM

Auto organización

Desarrollo Principios Colaboración

Iterativo
SCRUM

Control Priorización
Empírico Valor

Tiempo Definido
 PRINCIPIOS DE SCRUM
Transparencia
Producto Incremental Inspección
Periodo de tiempo mínimo Adaptación

Compromiso y
Recurso No
Responsabilidad
Rescatable
Entorno Innovador

Entregar máximo valor Conciencia

(Riesgo, incertidumbre y Articulación
capacidad) Apropiación
VALORES DE SCRUM
 ASPECTOS DE SCRUM

Justificación del
Negocio

Organización
a Calidad

Aspectos

Cambio Riesgos
¿Practicamos
conceptos?
AGENDA
WORK IN
TO DO DONE
PROCESS

S1

S3

S1

S4 S5

S2

S6
REFORCEMOS
Reforcemos 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.
• Él debe entender y apoyar las necesidades
e intereses de todos los Stakeholders.
• Comprende las necesidades y
el funcionamiento de los Developers.
 Responsabilidad
del Product Owner

• Maximize ROI.
• Release Plan.
• MVP.
• MMP.
 Crear la visión del proyecto

La Visión

La visión debe comunicar la esencia del futuro producto

de una manera concisa y describir un objetivo
compartido que proporcione dirección, pero que sea lo
suficientemente amplio como para facilitar la
creatividad.
- Roman Pichler
Componentes de la visión del proyecto
Componentes de una visión
 Estructura de una visión de proyecto

La Visión

Una técnicaalternativaprovienede CrossingtheChasm porGeoffrey Moore:

1. Para (clienteobjetivo).
2. Quién (declaraciónde la necesidadu oportunidad).
3. El (nombre del producto)esuna (categoría de producto).
4. Eso (beneficioclave, razón de peso para comprar/ usar).
5. Adiferencia(alternativacompetitivaprimaria).
6. Nuestroproducto(declaraciónde diferenciaciónprimaria).

• https://www.amazon.com/exec/obidos/ASIN/0066620023/cutterinformatco
 Técnicas
Técnicas para
para crearuna
crear unavisión
visiónde
de producto
producto o proyectoo proyecto

Técnicas para intentar:

• Vision Box.
• Product Roadmap
• Elevator Statement.
• Press Release.
• Magazine Review.
• One pager
 Product Vision box

El Product Vision Box, es una técnica muy simple pero poderosa promovida
por Jim Highsmith que puede ser utilizada tanto por equipos de proyectos
ágiles como tradicionales.

Design-the-Box, ejercicio hipótesis:

El producto se venderá en una caja envuelta contraíble.

Tarea: Diseñar el frente y la parte posterior del producto.
✓ Nombre del producto.
✓ Un gráfico.
✓ Tres o cuatro puntos claves en el frente para "vender" el producto.
✓ Una descripción detallada de la función en la parte posterior.
✓ Requisitos de funcionamiento.
 Product
El Product vision
Vision Box box

Después de un taller de Design-the-Box, se puede hacer lo siguiente:

Construyendo su propia versión de la declaración de visión del producto de Moore.

-Cree un documento completo de visión de productos de una a tres páginas que
podría incluir:
✓ Nombre del producto.
✓ La declaración de la misión.
✓ Una descripción general del perfil del proyecto (alcance, cronograma, costo,
defectos) con prioridades.
✓ Imágenes de las “boxes“.
✓ Diríjase a los clientes y a cada una de sus necesidades y medidas de
satisfacción del cliente.
✓ Tecnología clave yrequisitos operacionales.
✓ Limitaciones críticas del producto (rendimiento, facilidad de uso, volúmenes) e
indicadores financieros clave.
 Product Roadmap

Product Road Map

El mapa de ruta de un producto le

permite al equipo de Scrum
capturar los objetivos de las
próximas versiones de los
productos. La visión ahora forma
parte de la creación y actualización
del mapa de ruta del producto.

http://www.romanpichler.com/tools/product-roadmap/
 Ejemplo
PRODUCT ROAD MAP
 ÉXITO DEL PRODUCT OWNER
Éxito del Product Owner
El product Owner está disponible durante la iteración.
• Una visión.
• Un plan de negocios.
El Product Owner tiene:
• Una hoja de ruta de lanzamiento.
• Una acumulación de productos que entregará lo correcto.

• Está ordenado correctamente.

• C ontiene todo el trabajo (incluídos los problemas
El Product Backlog: técnicos).
• Está listo para la planificación del sprint.
• Tiene el tamañoadecuado.
• Se estima apropiadamente.
• Tiene especificaciones habilitantes.
¿Aterrizamos estos
conceptos?
 AHORA,

APLIQUEMOS UN CAMINO PARA

UNA VISIÓN DEL PRODUCTO O

PROYECTO EXITOSA.

_
Comencemos por visualizar con innovación
cómo crear y validar una Visión de Proyecto

Como Product Owner

¿Quién es hoy tu cliente?

¿Quiénes son sus clientes?

¿Cuál es su preocupación o mayor

necesidad?

¿Qué más puedes contar de él, ella o

ell@s?

¿ESTÁS DE ACUERDO?
 DESDE TU PUNTO DE VISTA (OBJETIVO E INSPIRADOR)

¿Cuál
es tu mayor problema
para ayudarlo?

SI LO PUDIERAS AYUDAR ¿CUÁL ES EL BENEFICIO MEDIBLE?

 Al menos 5 ideas, más es mejor

Y LA MÁS LOCA MEJOR

Sin perder el enfoque

¿QUÉ SOLUCIONES PUEDES PENSAR?

 ¿Te gustaría probarla?
¡Sí, tu idea!

HISTORIA LO MÁS ILUSTRADA POSIBLE

 ¿Qué falló?

¿Qué salió bien?

¿Cómo debería ser el siguiente

prototipo?

¿Qué te llevas?

¿CUÁL FUE EL RESULTADO?

 ¿TE GUSTÓ ESTA DINÁMICA?
Empatizar Definir Idear Prototipar Evaluar

ACABAS DE VIVIR DESIGN THINIKING

ATERRIZA LOS RESULTADOS
EN TU VISIÓN
¿Practicamos
conceptos?
AGENDA
WORK IN
TO DO DONE
PROCESS

S1

S5
S3

S1
S4

S2

S6
Producto
 Gestión de Productos Ágiles

Enfocando en continuidad

• Refinamiento de los requisitos.

• Priorización de requisitos.
• Comunicación con los Developers.
• Comunicación con el cliente y otras partes interesadas.
 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 identificar lo que el producto necesita para ser
adecuado, competitivo y útil.
La lista de Producto enumera todas las características,
funcionalidades, requisitos, mejorar y correcciones que
constituyen cambios para entregas futuras.
 Product Backlog

Un Product Backlog debe ser DEEP.

• Detallado apropiadamente.
• Estimado.
• Emergente.
• Priorizado.
 ¿Ordenando o dando prioridad?

Factores a considerar:

1. Valor comercial.
2. Costo de desarrollo.
3.Cantidad y significado del
aprendizaje y nuevo conocimiento
creado.
4. Cantidad de riesgo eliminado.
 Product Backlog Refinement

• El refinamiento (refinement) del Product Backlog es el

acto de añadir detalle, estimaciones y orden a
los elementos del Product Backlog.
• Durante el refinamiento del Product Backlog,
se examinan yrevisan sus elementos.
• El Scrum Team decide cómo y cuándo se hace
el refinamiento.
• Éste usualmente consume no más del 10% de
la capacidad de los Developers. Sin embargo,
los elementos del Product Backlog pueden
actualizarse en cualquier momento por el criterio del
Product Owner.
 Refinamiento Progresivo

Los elementos del Product Backlog que están más adelante, en el

futuro pueden ser más grandes.

Cada PBI debe describirse con el detalle suficiente como para que
el equipo pueda completarlo en un sprint.

Puede adjuntar cosas como:

• Diseño de interfaz de usuario.
• Algoritmos matemáticos.
• Pruebas.
Esfuércese por describir cada elemento lo más brevemente
posible.
 Product Backlog Item (PBI)

Product Backlog Items (PBIs) son los elementos que componen el Product Backlog.
 Seguimiento

Seguimiento del Progreso Hacia los Objetivos.

Seguimiento del Progreso del Sprint.

 Control de Proceso Empírico

Transparencia, inspección y adaptación - Control de proceso empírico.

"Es típico adoptar el enfoque de modelado definido (teórico) cuando los mecanismos subyacentes por los cuales opera un proceso se entienden razonablemente bien.
Cuando el proceso es demasiado complicado para el enfoque definido, el enfoque empírico es la elección adecuada ".
Dinámica de procesos, modelado y control, Ogunnaike y Ray, Oxford University Press, 1992.
 Increment

El Increment es la suma de todos los elementos del Product Backlog completados durante un Sprint y el valor de
los incrementos de todos los Sprints anteriores.

Al final de un Sprint, el nuevo Increment debe estar “Done”.

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

El Increment debe estar en condiciones de utilizarse sin importar si el Product Owner decide liberarlo o no.
 Conceptos Clave en Scrum

Épicas: Es una historia de usuario que

es demasiado grande para caber 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áspequeñ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 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énes van a participar.
Nivel de Detalle
 ¿Cómo está conformada una User Story?

Una historia de usuario debe estar Características: modelo INVEST.

conformada por las3C:
• Independencia.
• Negociables.
Card (tarjeta): Descripción escrita de lo que
necesita el usuario. • Valiosa.
Conversación: El PO y el DT aclaran los • Estimable.
detalles. • Pequeña.
Confirmación: Sirve para determinar lo que • Verificable.
se espera.
Estructura de User Story
 Task

En Scrum se puede definir como el trabajo técnico

que realizan los Developers para completar un ítem
del Product Backlog.

La mayoría de las tareas se definen como pequeñas,

lo que representa no más de unas pocas horas de un
día.
 ¿Cómo está conformada un Task?

Características modelo SMART:

S: Specific (Específico).
M: Measurable (Medible).
A:Achievable (Alcanzable).
R: Relevant (Relevante).
T: Time-boxed (Bloque de tiempo).
 Requerimientos

RequerimientosFuncionales
Las propiedades funcionales son funciones o funciones específicas del
producto, como la posibilidad de realizar o recibir llamadas.

Requerimientos No Funcionales
Los requisitos no funcionales, también llamados requisitos operativos,
cualidades del sistema y restricciones, son patitos feos del desarrollo de
software.
 Definición de Done

Son los acuerdos del PO con los Stakeholders que contienen todas las condiciones que
deben de cumplir los ítems del Product Backlog para considerar un Sprint completado o
finalizado.
¿Aterrizamos estos
conceptos?
AGENDA
WORK IN
TO DO DONE
PROCESS

S1
S3

S5

S4 S1

S2

S6
 Time-Boxing

Todos los eventos son bloques de tiempo (duración máxima de tiempo), de tal modo que
todos tienen una duración máxima.
 M oderador
2018-07-12 14:23:41
--------------------------------------------

¿Dónde se utilizan los Time-Boxing?

SPRINT
 Cancelación de un Sprint

Un Sprint puede ser cancelado antes de que el Time-Box 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.
 Reuniones o Ceremonias de Scrum

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

importante. Los Scrum Teams emplean una serie de
reuniones clave para estructurar el trabajo del equipo:

• Daily Standup Meeting.

• Sprint Planning Meeting.
• Sprint Review Meeting.
• Sprint Retrospective.
 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 los estados.
• Esencial para conocer el progreso continuo y evitar bloqueos.
• No tiene como objetivo reportar progreso al Scrum Master, Product Owner
o cualquier otro stakeholder.
• El Product Owner podrá participar siempre y cuando su participación
sea pasiva.
• El Scrum Master se asegura de que los Developers mantengan la reunión,
pero son ellos los responsables de dirigir el Scrum Diario.
Daily Standup Meeting
 ¿Qué puede ser terminado?

Esta pregunta nos ayuda para que el los Developers

trabajen en proyectar la funcionalidad que se
desarrollará durante el Sprint, donde se define el
objetivo del Sprint (Sprint Goal).

El número de elementos del Product

Backlog seleccionados para el Sprint
depende únicamente de los Developers.
 Sprint Goal

• El Sprint Goal es una meta establecida para el Sprint que puede lograrse mediante
la implementación del Product Backlog.

• El Sprint Goal brinda a los Developers cierta flexibilidad con respecto a

la funcionalidad implementada en el Sprint.

• El Sprint Goal puede representar otro nexo de unión que haga

que los Developers trabajen en conjunto y no en iniciativas separadas.
¿Cómo se conseguirá completar el trabajo
seleccionado?

Una vez que se ha establecido el Sprint Goal y

seleccionado los elementos del Product Backlog para el
Sprint, los Developers deciden cómo construirá esta
funcionalidad para formar un Incremento de Producto
“Done” durante el Sprint.

Los elementos del Product Backlog seleccionados para

este Sprint, más el plan para terminarlos, recibe el nombre
de Sprint Backlog.
 Estimación Planning Póker

Ésta es una de las técnicas más reconocidas en

Scrum, ya que es muy sencilla, divertida y
eficaz, donde los Developers estiman
como grupo el esfuerzo a realizar en el Sprint.
Sprint Review Meeting
 Sprint Review Meeting

• Los asistentes son el Scrum Team y los stakeholders

claves invitados por el Product Owner.

• El Product Owner explica qué elementos del Product

Backlog son “Done” y cuáles aún no.

• Los Developers hablan acerca de qué estuvo bien

durante el Sprint, qué problemas aparecieron y cómo
fueron resueltos esos problemas.

• Los Developers hacen una demostración del trabajo

que es “Done” y responden preguntas acerca del
Incremento.
 Sprint Review Meeting

• El Product Owner habla acerca del Product Backlog en su estado

actual. Proyecta objetivos probables y fechas de entrega en el tiempo
basándose en el progreso obtenido hasta la fecha (si fuera necesario).

• El grupo completo colabora acerca de qué hacer a continuación, de

modo que el Sprint Review proporcione información de entrada
valiosa para el subsiguiente Sprint Planning.

• 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 continuación.

• Revisión de la línea de tiempo, presupuesto, capacidades potenciales

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

HISTORIA DE
USUARIO
 Sprint Retrospective

• El Sprint Retrospective es una

oportunidad para el Scrum Team de
inspeccionarse así mismo y de crear un
plan de mejoras que sean abordadas
durante el siguiente Sprint.
• El Sprint Retrospective tiene lugar
después del Sprint Review y antes del
siguiente Sprint Planning.
• Se trata de una reunión de máximo tres
horas para Sprints de un mes.
 Sprint Retrospective

El propósito del Sprint Retrospective es:

• Inspeccionar cómo fue el último Sprint
en cuanto a personas, relaciones,
procesos y herramientas.
• Identificar 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 Scrum
Team desempeña su trabajo.
Las 5 Etapas de una Retrospectiva
¿Cómo gestionamos
todo esto?
MÉTODO KANBAN
_
 PROPIEDADES BÁSICAS

I. Visualizar el flujo de trabajo

II. Limitar el trabajo en proceso
III. Gestionar el flujo
IV. Hacer explícitas las políticas del
proceso
V. Implementar ciclos de
retroalimentación
VI. Mejorar colaborativamente
 Scrum Board
Historias / Objetivos Actividades en Actividades en
Actividades por realizar Actividades terminadas
del Sprint Proceso Revision
Gestión de proyectos
Desarrollo de Software
Manufactura
Recursos Humanos
Marketing
Ventas
¿Aterrizamos estos
conceptos?
AGENDA
WORK IN
TO DO DONE
PROCESS

S3 S1

S4 S1

S5
S2

S6
 RECOPILA, REFLEXIONA Y
ESTABLECE QUÉ VAS HACER