Programa de capacitación al

Product Owner
SISTEMA DE EXCELENCIA
 Product Product
Owner Backlog

Artefactos Historias de Eventos

Operativos Usuario
¿Qué es la Agilidad?
Entorno VUCA
¿Qué es la agilidad?

La agilidad es una mentalidad, cuya máxima prioridad

es satisfacer al cliente. Se trata de trabajar más
inteligente en lugar de esforzarse más. Se trata de
generar más valor con menos trabajo

Steve Denning. Autor de “The Age of Agile. How Smart Companies Are
Transforming the Way Work Gets Done”
El manifiesto ágil

Extreme Programming (XP)

Test-Driven Development o TDD
Scrum
Crystal Clear
Walking Skeleton
Arquitecturas Hexagonales
Wiki
Patrones de Diseño
UML
Refactoring
Microservicios
Clean Code
Principios SOLID
Scrum Guide
Scrum.org
Nexus
Scrum Alliance
Code Kata
DRY
Valores
Principios

1 2 3 4
Colaboración diaria del
Satisfacer al cliente mediante Los cambios se aceptan y Entrega frecuente de
negocio y los
entrega continua de valor aprovechan producto funcionando
desarrolladores

5 6 7 8
Medimos producto Promovemos el ritmo
Personas motivadas Conversación cara a cara
funcionando sostenible

9 10 11 12
Atención continua a la
La simplicidad es esencial Equipos auto-organizados Mejora continua
excelencia técnica
Metodologías ágiles
Design Thinking
Design Thinking - Emphatizar

Stakeholders Mapping
Análisis de Puntos de Dolor
Design Thinking - Definir
Design Thinking - Idear
Design Thinking - Prototipar
 - Duración fija.
- Contenedor de
- Sprint Backlog. - Sincronización.
eventos.

Marco Scrum

- Tener el Backlog - Incremento. - Mejora continua.

listo. - Velocidad.
- Feedback.

Eventos

Roles Artefactos

- Voz del cliente. - Visión.

- Visión. - Prioridades.
- Interfaz estable conocida.

- Proceso estable. - Saber trabajar.

- Mejora continua. - Capacidad.

- Competencia. - Suma del trabajo completado.

- Conocimiento. - Done.
- Valor
Interacción de los roles del Equipo Scrum
Scrum
Master

Product
Owner
Cliente /
Stakeholder
El PO transforma los El Scrum Master gestiona
requerimientos del cliente el Proceso Scrum,
en Historias de Usuario, asegurando que se cumpla
construye el Product la teoría y práctica de
El cliente proporciona Backlog, lo ordena y Scrum.
sus necesidades al prioriza y lo comunica al
PO Equipo de Desarrollo

Equipo de
Desarrollo
El PO entrega el valor del
negocio al cliente mediante
lanzamientos incrementales
del producto
El Equipo Scrum demuestra
el incremento del producto
al Product Owner durante el
Sprint Review
El Equipo de Desarrollo
autogestionado crea los
entregables del proyecto
Resumen de la agilidad

Kanban

Scrum

|
XP
Lean

AGILE es un Descrito por Definido por Manifestado en

MINDSET 4 cosas que 12 principios Muchos marcos de trabajo, prácticas y
valoramos técnicas
Resumen de la agilidad
 EL weeding planner I
OBJETIVO

Como weeding planner ejercer el role de product owner y ser capaz de

definir la mejor propuesta para la boda

TIEMPO

20 Min

INSTRUCCIONES

1. Realizar la fase de Empatía para identificar sus stakeholders y

puntos de dolor
2. Realizar la fase de Definir para elaborar el Customer Journey
Map AsIs.
3. Realizar la fase de Idear utilizando la técnica Brainstorming
para identificar las propuestas de solución.
4. Prototipar una propuesta de solución.
Product Owner
Definición

El Product Owner es responsable de

maximizar el valor del producto
resultante del trabajo del equipo de
desarrollo.

El Product Owner es la única persona

responsable de gestionar el Product
Backlog.
 Generalidades

Responsabilidad Unipersonalidad Legitimidad

El PO puede hacer el El PO es una persona, no Para que el PO tenga

trabajo anterior o acordar un comité. El PO puede éxito, toda la
que lo haga el equipo de representar los deseos de organización debe
desarrollo. Sin embargo, un comité en el Product respetar sus
el PO sigue siendo Backlog, pero aquellos que decisiones. Nadie
responsable deseen cambiar la prioridad puede forzar al Equipo
de un ítem del Product de Desarrollo a trabajar
Backlog deben dirigirse al en un conjunto
PO diferente de requisitos
Características

Visionario y Líder y disponible Jugador de Comunicador Empoderado y

hacedor siempre equipo y negociador comprometido
Competencias

EXPERTICIA CUSTOMER CENTRIC COMUNICADOR

DECIDOR VISIÓN DE NEGOCIO

Funciones del Product Owner

▪ Liderar el desarrollo de las 5 fases de

Design Thinking.

▪ Expresar claramente los elementos de

Product Backlog .

▪ Ordenar los elementos del Product Backlog.

▪ Optimizar el valor del trabajo que realiza el

Development Team.

▪ Que el Product Backlog sea visible,

transparente y claro para todos.

▪ Asegurar que el Development Team

entiende los elementos del Product
Backlog
 EL weeding planner II
OBJETIVO

Como weeding planner ejercer el role de product owner y ser capaz de

definir y priorizar un backlog de la boda

TIEMPO

20 Min

INSTRUCCIONES

1. Identifica tus stakeholders

2. Haz una lista de los intereses que tienen tus distintos
stakeholders
3. En función de los intereses antes definidos, establece como
podría estar compuesto el Scrum Team
4. Describe a muy alto nivel las actividades que necesitarías
llevar a cabo para realizar para satisfacer los intereses de tus
stakeholders
Product Backlog
¿Qué es el Product Backlog?
BACKLOG
+
Rut y Clave

MVP
• El Product Backlog es una lista ordenada de Llamada a VOX
todo lo que se conoce que es necesario en el
producto Llamáme

Prioridad

RELEASE 2
Diríjase a su Sucursal

• Es la única fuente de requisitos para cualquier Descripción Seguro

cambio a realizarse en el producto. Accidentes

RELEASE 3
Llamada a VOX
• El Product Owner es el responsable de la Servicio al Cliente

Lista de Producto, incluyendo su contenido,

disponibilidad y ordenación
Botón Seguro
Accidentes

-
Ejemplo de Backlog
Características del Product backlog

ES UN CUERPO VIVO
Nunca está terminado. El desarrollo más temprano de la
misma solo refleja los requisitos conocidos y mejor
entendidos al principio

EVOLUTIVO
De adapta a medida que el producto y el entorno en el que
se usará también lo hacen

DINÁMICO
Cambia constantemente para identificar lo que el
producto necesita para ser adecuado, competitivo y útil.

DUAL
Si un producto existe, su Product Backlog también existe
Cualidades del Product Backlog
DETALLADO
Los elementos de la parte de alta del Backlog deberán
estar más detallados que los de la parte baja

ESTIMADO
Deben incluir una estimación del esfuerzo necesario
para llevarlo a cabo

EMERGENTE
En función del feedback que se recibe del producto, el
backlog siempre está en constante evolución

PRIORIZADO
La propia definición de Product Backlog establece que se
trata de una lista priorizada de los elementos que
forman parte del alcance del proyecto
 Elementos del Product Backlog

• El Product Backlog está compuesto, por

todas las características que
constituyen cambios a realizarse sobre

R1 o MVP
Sprint 1 Backlog

el producto
Sprint 2 Backlog
• Los de mayor prioridad, tienen una Release Backlog
definición más detallada de sus 880 story points

Sprint 3 Backlog

R2
elementos

• Los elementos del Product Backlog Sprint 4 Backlog

muchas veces incluyen descripciones

R3
de las pruebas que demostrarán la Sprint 5 Backlog

completitud de sus requerimientos,

cuando estén “Terminados” Product Backlog
2400 story points

Fuente: The Definitive Guide to Scrum:The Rules of the Game. 2017

Organización del Product Backlog

• Para organizar el Product Backlog

puede utilizarse el User Story
Mapping, una técnica que consiste
en organizar los elementos del
Product Backlog en dos dimensiones
con el objetivo de construir un
Roadmap.

• Este mapa se compone de dos ejes,

en uno de ellos las releases (vertical)
y en el otro las funcionalidades
(horizontal)
 Jerarquía del Product Backlog
El Product Backlog puede tener varios niveles: por ejemplo, épicas, historias de usuarios y tareas. En algunos casos
dependiendo de la magnitud del producto y del tiempo que lleve su desarrollo, la granularizacion también puede hacerse
por Feature (o Theme) e Historia de Usuarios

Proyecto PRODUCTO

Primer
ÉPICA ÉPICA
nivel

Segundo
Historia de Historia de Historia de Historia de Historia de Historia de Historia de Historia de
Nivel Usuario Usuario Usuario Usuario Usuario Usuario Usuario Usuario

Tarea Tarea Tarea Tarea Tarea Tarea Tarea

Tercer Tarea
Tarea Tarea Tarea Tarea Tarea
Nivel Tarea
Tarea Tarea Tarea Tarea Tarea

Tarea Tarea Tarea Tarea

Tarea
Tarea
Refinamiento

El refinamiento (refinement)
del Product Backlog es el
acto de añadir detalle,
estimaciones y orden a los
elementos que componen
éste.
 Refinamiento

TRABAJO EN EQUIPO
Es un trabajo en equipo continuo, entre el Product Owner y el
Development Team.

PERIODICIDAD
El Scrum Team decide cómo y cuándo hacerlo (no debe consumir
más del 10% de la capacidad del Development Team)

PRIORIZACIÓN
Los elementos del Product Backlog de orden más alto deben tener
un mayor nivel de detalle

RESPONSABILIDAD
El Development Team es el responsable de proporcionar todas las
estimaciones

Fuente: The Definitive Guide to Scrum:The Rules of the Game. 2017

 Ejemplos de refinamiento del Backlog

Elementos sin el Elementos con Elementos con distinto nivel de

+ nivel de detalle + el mismo nivel + detalle (los de nivel superior con
suficiente de detalle mayor granularidad

Feb 2021

Prioridad
Mar 2021
Prioridad

Prioridad
- - - Abr 2021
Criterios de priorización
del backlog

VALOR

CONOCIMIENTO

RIESGO

INCERTIDUMBRE

DEPENDENCIAS
 EL weeding planner III
OBJETIVO

Como weeding planner ejercer el role de product owner y ser capaz de

refinar y priorizar un backlog de la boda

TIEMPO

20 Min

INSTRUCCIONES

1. Describe a muy alto nivel las actividades que necesitarías

llevar a cabo para realizar para satisfacer los intereses de tus
stakeholders
2. Clasifica dichas actividades en épicas, historias de usuarios y
tareas
3. Refina dichas actividades, añadiéndole detalles y ordenando
sus elementos
4. Ordena de manera priorizada el Product Backlog, utilizando
los criterios estudiados durante el módulo
Artefactos Operativos
Definition Of Ready

Es un acuerdo entre el Product Owner y el equipo

de Desarrollo donde se colocan los criterios por las
cuales una historia se encuentra lista para ser
trabajada dentro de un sprint.

Básicamente, es un conjunto de condiciones -y un

checklist también- a la cual se somete una historia
para ser tomada en un Sprint Planning.
Definition Of Done

Cuando un elemento del Product Backlog o un Incremento se describe

como “Done” (terminado), todo el mundo debe entender lo que
significa “Done”.

Aunque esto puede variar significativamente para cada Scrum Team, los
miembros del Equipo deben tener un entendimiento compartido de lo
que significa que el trabajo esté completado para asegurar la
transparencia.

Esta es la definición de “Done” para el Scrum Team y se utiliza para

evaluar cuándo se ha completado el trabajo sobre el Incremento de
producto.
 EL weeding planner IV
OBJETIVO

Como weeding planner en su rol de Product Owner aprenda a evaluar si

las historias de usuarios (HU) de su backlog están listas para ser
incluidas en el sprint y así reducir la complejidad y esfuerzo requerido

TIEMPO

20 Min

INSTRUCCIONES

Habiéndose definido las actividades para llevar a cabo la boda,

ahora, como Product Owner, toma las decisiones siguientes:

1. Determina el Definition Of Ready y Definition of Done para

incorporar esas HU al sprint planning
Historias de usuario
¿Qué son las Historias de Usuarios?

En agilidad las historias de usuario son el reemplazo escrito de

los requerimientos de usuario, se escriben en el lenguaje
propio de éstos y determinan de manera simple y concreta su
finalidad, el objetivo de negocio que se de que se desea
alcanzar, y que se requiere para lograrlo

Son una invitación a una conversación y no una descripción

extensiva. (Valoramos las personas y sus interacciones por
sobre los procesos y las herramientas, el software funcionando
por sobre la documentación extensiva)
Ventajas de utilizarlas

Centrado en el usuario

Pequeñas

Poco mantenimiento

Están vivas
Ventajas de utilizarlas

Relación cercana

Incremental

Estimables

Flexibles
Elementos: las 3C

Los elementos fundamentales de una historia de usuario

conocidas como las 3C son:

Cards
La historia debe ser corta, debería caber en una
tarjeta de fichero

Conversation
Deben ser un disparador, una invitación a una
conversación, sin esa conversación no están
completas

Confirmation
Deben tener un mecanismo para verificar que
se cumple con lo que requiere, una forma de
saber que la historia se realizó correctamente
 Criterio INVEST
Es una metodología desarrollada por Bill Wake y nos ayuda a garantizar que las historias de usuario ofrecen
valor a negocio aunque se desarrollen en un sola iteración

La historia de usuario no debe depender de otra historia ya que esto

I INDEPENDENT
facilitará la priorización de las mismas

No son contratos, sino promesas de comunicación (negociada con el

N NEGOTIABLE
Product Owner).

V VALUABLE Debe brindar valor al proyecto y al usuario final

La historia de usuario debe tener el esfuerzo que ésta tomará en

E ESTIMABLE
implementarse

Debe ser pequeña y concisa, si es muy grande se debe dividir en

S SMALL SIZE
historias más pequeñas para tener un mejor control sobre ellas

T TESTEABLE Puedo escribir un test que pruebe su correcto funcionamiento

 Estructura
• Una buena historia de usuarios está compuesta por: un título descriptivo, una descripción
y criterios de aceptación

Descripción

Título corto y
descriptivo
Historia de
Usuarios

Criterio de
Aceptación
Título corto descriptivo
El título descriptivo debe estar compuesto por un
verbo y un complemento

• Detalles de
• Eliminar usuario
usuario
inactivo

• Carro de
• Cambiar
compras
contraseña

• Configuración de
• Publicar post
usuario
 Descripción
• Las historias de usuario definen una funcionalidad, pues en una sola frase debe quedar claro
quién (rol) hará una acción (objetivo) para satisfacer una necesidad (motivación)
EJEMPLOS
Criterios de Aceptación (CA)

Son enunciados que se describen desde el punto de vista del usuario cuándo una historia se puede
considerar hecha y correctamente implementada
Formato de un CA
Los Criterios de Aceptación deben describir siempre un contexto (dado que) un evento (cuando) y
la respuesta o consecuencia (entonces) esperada del sistema

• Historia de Usuario

Yo como usuario de la app del banco

Quiero consultar y descargar todos los cobros
que el banco me ha hecho en el pasado
Para entender cuanto estoy pagando Y poder
reconfigurar el uso que hago de los servicios del
banco.

• Criterio de Aceptación
Dado que la cuenta tiene crédito
y que la cuenta el usuario de la cuenta en loging
de app es validada
Cuando el cliente pide descargar sus cobros
Entonces el estado de cuenta de 3 meses atrás
puede ser consultado
Definición de slicing

Slicing o splitting (dividir, rebanar en cortes) es una práctica que permite reducir la
complejidad y esfuerzo requerido de las Historias de Usuario, y que se aplica a
todos los ítems sobre los cuales trabaja el equipo. Cuánto más pequeñas sean las
Historias de Usuario resultantes, mayor será además la posibilidad de
completarlas dentro de un Sprint.
 ¿Por qué dividir historias?
Definición
Retroalimentación rápida

Es una fase previa a la construcción

de un producto digital -o a agregar una Corrección rápida de errores
Valor funcionalidad-, cuyo objetivo es
nueva
identificar cuáles de las ideas que
tuvimos realmente vale la pena
Historias Posponer trabajo menos valioso
construir pequeñas

Más confianza

Utilidad Historias grandes

Ahorro de tiempo en estimaciones
• Identificación de funcionalidades
valiosas
• Ahorro tiempo y dinero
Minimizar de riesgos
• Reducción rápida del ciclo de Cascada
desarrollo
• Validación de funcionalidades con Tiempo Mejor distribución del trabajo
clientes finales
Proceso de slicing

El objetivo de Historias de Usuarios (HU) es hacerlas más pequeñas y entregar funcionalidades de mayor
valor más rápido

Existen al menos 2 formas de hacerlo:

1. El slicing horizontal implica desglosar historias

por el tipo de trabajo que debe hacerse, o las
capas o componentes que están involucrados

2. El slicing vertical es más útil, pues, los PBI se

dividen en trozos más pequeños (en lugar de
tareas técnicas), dando como resultado un
software demostrable que funciona
Proceso de slicing (overview)
El proceso de slicing consta de 3 fases: evaluar historias, aplicar patrones y evaluar división
Evaluar
historias
0
1

Evaluar Aplicar
división patrones
0 0
3 2

Fuente: http://agileforall.com/wp-content/uploads/2013/06/Story-Splitting-Flowchart-ES.pdf
Paso 1: evaluar historias

Una vez creadas nuestras historias de usuario nos

podemos hacer dos preguntas:

1 ¿Satisface
INVEST?
el criterio

2 ¿Es menor a 1/6 de nuestra

velocidad de equipo?
Paso 2: aplicar patrones (1/2)
Patrones a considerar al momento de aplicar un slicing

NOMBRE El primero y el Por tipo de Interfaz de Por regla de

último usuario usuario negocio

Un proceso con varios Variación de acuerdo al Desarrollo de la interfaz Reglas de negocio

SUPUESTO
pasos complejos tipo de usuario es muy complejo complejas

Crear 3 nuevas Crear historias por tipo Crear historias por Crear historias por
historias que de usuario interfaz reglas de negocio
incluyan: el primer
CRITERIO paso del proceso, el
último paso del proceso
y lo que queda en
medio
Paso 2: aplicar patrones (1/2)
Patrones a considerar al momento de aplicar un slicing

NOMBRE Por Por Por

datos flujo browser

Muchos datos de Casos de prueba con Compatibilidad con

SUPUESTO
entrada caminos alternativos varios navegadores

Dividir de acuerdo al Una historia en el Dividir la historia

significado de los caso de prueba creando una por cada
datos, agregar perfecto. navegador. Enfocarse
CRITERIO inicialmente sólo la Otras historias que en aquello que da más
funcionalidad necesaria agreguen validaciones y valor
para los datos soporte a las
seleccionados excepciones
Paso 3: evaluar la decisión
Una vez aplicamos uno o varios patrones toca evaluar si quedó bien dividida, para esto algunas preguntas que nos
pueden ayudar:

¿Ha aparecido una

¿Las nuevas
¿Cada una de las historia muy obvia
historias de usuario
nuevas historias con la que empezar,
resultantes, son
satisface los por que es la que
relativamente
principios nos va aportar el
iguales en
INVEST? máximo valor de
tamaño?
forma temprana?

¿Cada una de las ¿Qué historias

¿Han aparecido
nuevas historias son aportan mayor
historias que
aproximadamente valor al negocio o
pueden bajar su
de 1/6 de nuestra implican menos
prioridad, o incluso,
velocidad de riesgos para el
ser borradas?
equipo? proyecto?
 Dentro de las técnicas de
slicing que existen,
encontramos a SPIDR, una
herramienta eficiente
para dividir historias de
usuarios
Técnica SPIDR
SPIDR, es una técnica de slicing, que describe cinco técnicas que se definen por el propio acrónimo, que se basa
en una estrategia iterativa e incremental

SPIKES PATH
Realizar prototipos que nos Crear tantas HU como alternativas a
permiten evaluar la viabilidad de considerar como posibles soluciones
una historia usuario para alcanzar nuestros objetivos

RULES INTERFACES
Crear de manera incremental tantas Establecer una estrategia que nos
HU como condiciones especiales permita dividir las HU en términos de
que deben cumplirse para la diversidad que aporta cada una de
satisfacer las necesidades del estas interfaces
negocio

DATA
Dividir HU en elementos más
pequeños viene dada por la gestión
de la complejidad según los datos
que en estas se utilizan
Tipos de Estimaciones

• Estimación Absoluta • Estimación Relativa​

Proporcionar el mayor nivel de detalle tratando También llamada estimación con puntos
de alcanzar un mayor nivel de certeza respecto consiste en asignar un puntaje de acuerdo al
del tiempo​. esfuerzo requerido según la experiencia del
equipo.
Estimación Relativa

Consiste en agrupar cosas de similar medida, comparándolas

entre ellas, con base en alguna referencia (pivote).
Estimación por puntos
Se considera punto al valor numérico que utilizan para
establecer el “tamaño” de una iniciativa (PBI, necesidad) en
función de su esfuerzo, complejidad e incertidumbre.
¿Qué variables usamos al estimar?
Esfuerzo

Incertidumbre Complejidad
Ejercicio – Serie Fibonacci
• Los equipos pueden asignar puntos según el
esfuerzo y juicio de experto, donde puede
asignar el 0 para lo que requiere un esfuerzo
casi nulo, 1/2 para esfuerzo pequeño, 13 y
40 los más grandes. Escala de Fibonacci.
 EL weeding planner V
OBJETIVO

Como weeding planner en su role de product owner deberás escribir las

historias de usuarios (US) necesarias para llevar a cabo una boda

TIEMPO

20 Min

INSTRUCCIONES

1. Escribe las HU respetando la estructura siguiente:

• Título corto y descriptivo
• Descripción
• Define los criterios de aceptación (CA)

Al escribir la HU utiliza la fórmula siguiente: COMO <rol>

QUIERO <objetivo> PARA <motivación>

2. Evalúa cada una de las HU conforme el criterio INVEST

3. Aplica slicing a alguna de tus HU, aplicando la técnica
SPIDR
Eventos
 Discovery Meeting
1.5H SM - DT – PO - PgO, EADL,
PL, AC,

Definición
Reunión de trabajo colaborativa a través de la cual, el
se presenta las programas que han terminado la
etapa de Discovery.

Objetivos
Presentar los programas y sus épicas identificadas .
 Discovery Retrospective
1.5H SM - DT – PO – PgO.

Definición
Reunión informal para inspeccionar el trabajo
realizado en la etapa de Discovery

Objetivos
Planificar formas de aumentar la calidad y eficacia del
equipo de Discovery.
Replenishment Discovery meeting
2.5H SM - DT – PO – PgO, EADL, PL, AC.

Definición
Reunión informal para planificar los programas que
se realizarán en el trimestre actual.

Objetivos
Reponer iniciativas a aplicar discovery.
 Sprint Planning
2H SM - DT - PO

Definición
Reunión de trabajo colaborativa a través de la cual,
el Scrum Team planifica las actividades que se
llevarán a cabo durante el sprint.

Objetivos
Planificar las actividades que se llevará a cabo
durante el sprint
Daily Scrum
15 Min SM

Definición
Reunión de trabajo para evaluar el progreso hacia
el Objetivo del Sprint y la tendencia sigue este
progreso hacia la finalización del trabajo contenido
en el sprint backlog

Objetivos
Planificar el trabajo para las siguientes 24 horas
Refinamiento
15 Min SM

Definición
Reunión de trabajo dedicado a agregar detalles,
estimar y ordenar las historias de usuario que haya
dentro del Product Backlog.

Objetivos
Analizar las próximas historias de usuario a
incorporarse en los siguientes sprints,
identificando dependencias y riesgos.
Sprint Review
1H SM - DT - PO

Definición
Reunión informal para inspeccionar el
Incremento y adaptar el Product Backlog si
fuese necesario

Objetivos
Inspeccionar el Incremento y adaptar el
Product Backlog
Sprint Retrospective
1H SM – DT - PO

Definición
Reunión informal para inspeccionar el
Incremento y adaptar el Product Backlog si
fuese necesario

Objetivos
Inspeccionar el Incremento y adaptar el
Product Backlog
 El weeding Planner VI
OBJETIVO

Como weeding planner en su rol de product owner deberá definir las

Historias de Usuarios (HU) que se llevarán a cabo en el primer sprints,
entre ellas, la elaboración de la comida principal: la pizza.

TIEMPO

60 Min

INSTRUCCIONES

SPRINT PLANNING (15 min)

1. Júntate con tu equipo de trabajo (Development Team) y

establece las actividades que deberán llevarse a cabo
durante el primer sprint para la celebración de la boda, entre
ellas, la elaboración de la comida principal: la pizza. Para
ello, invítalos a responder 2 preguntas:

• ¿Qué puede entregarse en el Incremento resultante

del Sprint que comienza?
• ¿Cómo se conseguirá hacer el trabajo necesario para
entregar el Incremento?
 El weeding Planner VI
INSTRUCCIONES

ORGANIZACIÓN (5 min)

2. Una vez que se elabore la lista de actividades a realizar

conforme el punto anterior (comprar ingredientes, equipos de
cocina, etc.,) pídeles que se organicen en equipos para
llevar a cabo dichas actividades y que comiencen con la
elaboración de la pizza

DAILY SCRUM (10 min)

3. Luego, reúnete con tu equipo y evaluar el progreso hacia el

Objetivo del Sprint realizando las preguntas siguientes:

• ¿Qué hice ayer que ayudó al lograr el Objetivo del

Sprint?
• ¿Qué haré hoy para ayudar a lograr el Objetivo del
Sprint?
• ¿Veo algún impedimento que evite que logremos el
objetivo del Sprint?

4. Lleva a cabo una nueva iteración para que el equipo se

ponga de acuerdo y realice las actividades necesarias para
la elaboración de la pizza
 El weeding Planner VI
INSTRUCCIONES

SPRINT REVIEW (15 min)

5. Júntate con tu equipo e inspeccionar el incremento de la

realización de la pizza hasta el momento; para ello, realicen
las acciones siguientes:

• Comenten acerca del proceso de desarrollo de la pizza

y hagan una demostración de cómo quedó la misma

• Analicen el sprint de cara a mejorar los próximos sprints

• Como Product Owner da a conocer cual era el objetivo

del Sprint y si este se cumplió o no y expresa cual es el
valor que se está entregando

SPRINT RETROSPECTIVE (10 min)

6. Por último, analicen como equipo, cuales fueron los

principales problemas que afrontaron y definan un plan de
mejoras que sean abordadas durante el siguiente Sprint
Gracias

SISTEMA DE EXCELENCIA