Scrum Product Owner Certified Expert -

SPOCE
 A cerca de CertiJoin
• Es una empresa con experiencia en el desarrollo,
creación y gestión de contenido relacionado con el
área de tecnologías de la
información.
• Ofrece certificaciones internacionales
con exámenes estandarizados, implementando las
mejores prácticas de la industria con
reconocimiento de clase mundial.
• Es Corporate Member de Agile Allianz,
nos enfocamos en compartir la firmeza de nuestros
valores y el compromiso con la calidad.

Más información: [Link]

Acerca de certificaciones de CertiJoin

 Garantiza calidad y veracidad en la realización de

nuestros exámenes de certificación
 Acredita los conocimientos y habilidades de las
personas en áreas específicas.
 Brinda un acceso conveniente donde y cuando lo
necesite
 Ofrece facilidad para presentar nuestros exámenes
(24x7) en cualquier momento y en cualquier lugar del
mundo

Está comprometido con la transformación hacia el

agilismo por esta razón con nuestras certificaciones Agile
podrá alcanzar el máximo nivel como Agile Coach
Certified Expert – ACCE
Resumen del curso

Un Product Owner debe

tener la capacidad de demostrar sus
habilidades y conocimientos a
profundidad en torno a la filosofía
Agile y el marco de trabajo
Scrum. Con esta certificación podrá
entender y asumir el rol de
Propietario de Producto
representando los intereses del
cliente hacia el Equipo Scrum.
Contenido del curso
Agile Rol del Product Owner
 Cascada vs Agile  Características del Product Owner
 Manifiesto para el desarrollo ágil de software  Responsabilidades del Product Owner
 Principios del manifiesto Agile
 Mejora continua Rol del Product Owner en el ciclo de vida Scrum
 Otros marcos de Agile
 Visión del producto
 Scrum
 Teoría de Scrum  El Product Backlog
 RoadMap del producto
Roles y Responsabilidades
 Equipo Scrum
 El Dueño de Producto (Product Owner)
 El Scrum Master
 El Equipo de Desarrollo (Development Team)
Contenido del curso
Creando y priorizando el backlog  Velocidad del equipo
 Historias de usuario/Épicas  Refinamiento (refinement) de la Lista de Producto
 Ventajas que aportan las historias de Planificando el Sprint
usuario  Creando el Sprint Backlog
 Épicas  Sprint Planing Meeting
 Información en una historia de usuario  El Product Owner en los eventos de Scrum
 Recomendación de atributos  Objetivo del Sprint (Sprint Goal)
 Criterios de aceptación  Definición de “Terminado” (Definition of Done)
 Calidad en las historias de usuario  Lista de Pendientes del Sprint (Sprint Backlog)
 Priorización de historias de usuario  Creando el Sprint Backlog
 Técnica MoSCoW  Ejemplo: Lista de Pendientes del Sprint
 El Sprint
Estimando y refinando el backlog
 El Product Owner en los eventos de Scrum
 Estimación ágil utilizando planning poker
 Cancelación de un Sprint
 ¿Cómo jugar?
Contenido del curso
Seguimiento y comunicación del progreso Revisión de Sprint (Sprint Review)
 Scrum Diario (Daily Scrum) Retrospectiva de Sprint (Sprint Retrospective)
 El Product Owner en los eventos de Scrum
 Utilizando un tablero de tareas Añadiendo valor
 Cambios en SCRUM  Valor comercial /Valor de negocio
 Actualización del Sprint Backlog  Voz del cliente
 ¿Cómo trabajar con clientes, usuarios y otras partes
Monitoreo de progreso interesadas?
 BurnDown Chart
 Actualización del BurnDown Chart
 Burndown de release (Release Burndown Chart)
 Interpretando resultados
 Identificando obstáculos
Este curso incluye los siguientes recursos

Ejercicios Cuestionarios Plantillas Simulador

Descargables Web
Agile
Cascada vs Agile

Agile
Cascada
Proyecto más
Proyecto de
pequeño y entrega
desarrollo altamente
incremental
complejo.
Flexible, negociable,
Requisitos bien
justo a tiempo.
pensados
Fecha de entrega
Fecha de entrega fija
flexible
Equipos grandes
Equipos más
pequeños (<20)
Manifiesto para el desarrollo ágil de software
Colaboración con el
Individuos e interacciones cliente sobre
sobre procesos y negociación contractual
herramientas Esto es, aunque
valoramos los elementos
de la derecha,
3 valoramos más los de la
1 izquierda.
Más información:
2 4 [Link]

Software
funcionando sobre Respuesta ante el
cambio sobre
documentación
seguir un plan
extensiva
Principios del manifiesto Agile

[Link] 2. Aprovechamos 3. Entregamos productos 4. Trabajamos

al cliente los cambios funcionales y juntos
frecuentemente

5. Permanecemos 6. Conversamos 7. Medimos los 8. Mantenemos un

motivados cara a cara productos ritmo constante de
funcionando forma indefinida

9. Prestamos
11. Somos 12. Mejoramos
atención continua a 10. Lo hacemos simple
la excelencia técnica
autoorganizados continuamente
Mejora continua
• La mejora continua hace que los errores o
defectos se noten con más facilidad a
través de pruebas de calidad repetitivas, y no
simplemente cuando el producto final esté casi
terminado.
• El equipo aprende de sus experiencias y
de la participación de Stakeholders
• Cualquier cambio en los requisitos debe reflejar
los cambios en el entorno empresarial,
ya sean internos o externos, y los equipos se
deben adaptar continuamente a fin de
alcanzar esos requisitos
Preguntas para guiar a los equipos hacia la mejora continua

“El objetivo no es alcanzar cierto nivel de productividad y

quedarse estático, sino examinar constantemente los procesos
para mejorarlos siempre”

¿Cómo podemos hacer mejor ¿Qué cambios podemos hacer ¿Cuál es nuestro principal
lo que llevamos a cabo? en la forma como riesgo?
trabajamos?
Otros marcos de Agile

Crystal
Extreme
Methodologies
Programming
(XP)
Se guían a través del
SCRUM
Manifiesto Ágil
Kanban

LeSS
DSDM
Otros marcos de Agile

Crystal
Entre todos los métodos de la familia
Methodologies
Crystal, hay siete propiedades comunes
predominantes.
 Entrega frecuente
Los métodos de cristal se consideran y describen  Mejora reflexiva
como "metodologías ligeras"  Comunicación estrecha
 Seguridad personal
 Enfoque
Son flexibles y evitan procesos estrictos y rígidos
típicamente encontrados en metodologías antiguas  Fácil acceso a usuarios expertos
 Entorno técnico con pruebas
automatizadas, gestión de la
Se centran en:
Gente/ Interacción/ Comunidad configuración e integración frecuente
Habilidades/ Talentos/ Comunicaciones
Otros marcos de Agile

Extreme Los equipos se autoorganizan en torno

Programming
(XP) al problema para resolverlo de la
manera más eficiente posible.
Extreme Programming mejora un
proyecto de software de cinco maneras
Es una metodología de desarrollo enfocada en la
adaptabilidad esenciales:
Enfatiza la satisfacción del cliente.  Comunicación
Implementa un entorno simple pero eficaz que permite
 Simplicidad
a los equipos ser altamente productivos  Retroalimentación
 Respeto y coraje
Las reglas de XP definen un entorno que promueve la
colaboración y el empoderamiento del equipo
Otros marcos de Agile

Kanban
Kanban
 ¿Qué producir?
 ¿Cuándo producirlo?
 ¿Cuánto producir?

Cinco características básicas

Es un método para gestionar el trabajo intelectual,
con énfasis en la entrega justo a tiempo, mientras
1. Visualizar
no se sobrecarguen los miembros del equipo. 2. Limitar el trabajo en curso
3. Dirigir y gestionar el flujo
4. Hacer las Políticas de Proceso Explícitas
En este enfoque, el proceso, desde la definición de
5. Utilizar modelos para reconocer
una tarea hasta su entrega al cliente, se muestra
para que los participantes lo vean y los miembros oportunidades de mejora
del equipo tomen el trabajo de una cola.
Scrum

Scrum es: Scrum se basa en la teoría

Ligero de control de procesos
empírica o empirismo.

Scrum emplea un enfoque iterativo e

Fácil de entender incremental para optimizar la
predictibilidad y el control del riesgo.

El empirismo asegura que el conocimiento

Extremadamente difícil procede de la experiencia y de tomar
de llegar a dominar decisiones basándose en lo que se
conoce.
Teoría de Scrum

Tres pilares soportan toda la implementación del control de procesos empírico:

transparencia, inspección y adaptación

Pilares

Transparencia Los aspectos significativos del proceso deben ser visibles para
aquellos que son responsables del resultado.

Los usuarios de Scrum deben inspeccionar frecuentemente los

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

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

Adaptación desvían de límites aceptables, y que el producto resultante no será
aceptable, el proceso o el material que está siendo procesado deben
ser ajustados.
Roles y Responsabilidades
Equipo Scrum

Dueño del producto Equipo de Desarrollo

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 del Producto Dueño 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
Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista producto y del trabajo del Equipo de
del Producto al nivel necesario. Desarrollo.
 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.
El Equipo de Desarrollo (Development Team)

Equipo de Desarrollo
(Development Team)
El Equipo de Desarrollo consiste en los profesionales que
Incremento
desempeñan el trabajo de entregar un

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
Rol del Product
Owner
Características del Product Owner
Dueño del producto
(Product Owner)

comprende el proceso que el Tiene la autoridad para tomar

equipo recorre para saber qué decisiones.
puede hacerse e, igualmente,
qué no.

1 2

Está a disposición del equipo Debe hacerse cargo del valor

“La responsabilidad de liderazgo de un individuo no para explicar qué se debe hacer generado. En un contexto de negocios
y por qué lo que importa son los ingresos.
depende de la autoridad. La arraigada suposición de que la
autoridad equivale a responsabilidad es la causa de 3 4
muchos males organizacionales”
Características del Product Owner
Dueño del producto El Product Owner debe equilibrar múltiples
(Product Owner) atributos del producto
Responsabilidades del Product Owner

Dueño del producto

(Product Owner)
"El Propietario del Producto es responsable  Expresa claramente los elementos de la Lista
de maximizar el retorno de la del Producto
 Ordena los elementos en la Lista del Producto
inversión (ROI) identificando las para alcanzar los objetivos
características del producto, traduciéndolas  Optimiza el valor del trabajo desempeñado
en una lista de características por el Equipo de Desarrollo
priorizadas, decidiendo cuál debe  Asegura que la Lista del Producto es visible,
transparente y clara para todos
estar en la parte superior de la lista para el  Asegura que el Equipo de Desarrollo entiende
próximo Sprint, y continuamente los elementos de la Lista del Producto
priorizando y refinando la lista"
Rol del Product Owner
en el ciclo de vida
Scrum
Visión del producto

Dueño del producto

“El primer paso en Scrum es que el (Product Owner)
1 Propietario del Producto articule la
visión del producto”

Esto evoluciona en una lista refinada

2 y priorizada de características
llamada Product Backlog

El Product Backlog existe y

3 evoluciona a lo largo de la vida útil

del producto; es la hoja de ruta del
producto
El Product Backlog

Dueño del producto

(Product Owner)
Product Backlog:
Un proyecto Scrum
► Es una lista está impulsado por una
ordenada de visión de
todo lo que podría
ser necesario en el producto
producto compilada por el
Propietario del Producto
► Es laúnica y expresada en el
Product Backlog
fuente de requisitos
para cualquier
cambio a realizarse
en el producto.
Ejemplo Lista de Producto (Product Backlog)
El Product Backlog muestra el camino a seguir para el equipo de Scrum y es
mantenido por el propietario del Producto

Como comprador deseo poner el libro

en un carrito de compras

Esfuerzo Inicial (Puntos)

Prioridad establecida
por el Product Owner
RoadMap del producto
Va más allá de un release individual, describiendo la Dueño del producto
ruta que seguirá el producto a futuro
(Product Owner)

El Dueño de producto describe como se

visiona la evolución del producto a lo largo
de varios sprints
Creando y Priorizando el
Product Backlog
Historias de usuario
¿Qué es una historia de
usuario?  Ayuda a crear Historias de
usuario
► Son utilizadas en los métodos ágiles para la
 Ayuda a definir los criterios de
especificación de requisitos Aceptación para cada Historia
► Son una descripción breve de una de Usuario
 Clarifica contenido de Historias
funcionalidad tal y como la percibe el
de Usuario
usuario
 Facilita la comprensión y
► Describen lo que el cliente o el usuario confirma las Historias de
Usuario con el Equipo Scrum
quiere que se implemente y se escriben
Dueño del producto
con una o dos frases utilizando el lenguaje
(Product Owner)
común del usuario
Ventajas que aportan las historias de usuario
Al ser muy cortas,
representan requisitos
del modelo de negocio Mantienen una
que pueden Necesitan poco relación cercana
implementarse mantenimiento. con el cliente.
rápidamente días o
semanas

Permiten dividir Permiten

estimar Son ideales para
los proyectos en
fácilmente el proyectos con
pequeñas
entregas. esfuerzo de requisitos volátiles o
desarrollo. 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
Recomendación de atributos

ID: identificador de la Estimación: Esfuerzo Prioridad: permite

historia de usuario, único Descripción: descripción necesario en tiempo ideal determinar el orden en el
para la funcionalidad o sintetizada de la historia de implementación de la que las historias de
trabajo de usuario. historia de usuario. story usuario deben de ser
points implementadas

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

Los criterios de aceptación ayudan

al equipo de desarrollo a entender Uno de ellos es el método SMART en el
el funcionamiento del producto, de que se han de cumplir en lo máximo posible los
manera que estimarán mejor el siguientes criterios:
tamaño de la historia de usuario.
S Specific (Específicos)
M Measurable (Medibles)
Existen diversos métodos A Achievable (Alcanzables)
para medir la calidad de los R Relevant (Relevantes)
criterios de aceptación.
T Time-boxed (Limitados en el tiempo)
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, Entiende las necesidades y
prioridades de las partes
cuya base se apoye en: interesadas, incluyendo clientes y
usuarios

 Beneficios de implementar una funcionalidad

 Pérdida o costo que demande posponer la
implementación de una funcionalidad
Prioriza ítems de producto
 Riesgos de implementarla identificados en el Backlog
 Coherencia con los intereses del negocio
 Valor diferencial con respecto a productos de la
competencia. Dueño del producto
(Product Owner)
Técnica MoSCoW para priorización del Product Backlog

M - MUST HAVE
(es necesario): se debe tener la funcionalidad implementada en la solución, sino
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

S - SHOULD HAVE que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si
no 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

W - WON'T HAVE en ese momento, pero que en futuro pueda ser relevante. Posteriormente, cuando
cobre importancia, puede pasar a alguno de los estados anteriores.
 Estimando y
Refinando el Backlog
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
que otra tendrá más puntos historia.
 Esfuerzo: Quizás una historia no tiene complejidad
pero si requiere esfuerzo (ejemplo: Crear Web
Services de integración para varias aplicaciones),
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
usuario, siempre por falta de información previa.
 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: [Link]
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”.
¿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 Product Owner
 Todos los participantes proceden a realizar su estimación en forma necesita una
secreta, sin influenciar al resto del Equipo, poniendo su carta elegida
boca abajo sobre la mesa. evaluación
 Una vez que todos los integrantes han estimado, se dan vuelta las cartas
y se discuten principalmente los extremos.
honesta de
lo complejo que
 Al finalizar la discusión se levantan las cartas y se vuelve a estimar, esta
vez con mayor información que la que se tenía previamente. será el trabajo
 Las rondas siguen hasta que se logra consenso en el Equipo y luego se
continúa desde el punto número uno con una nueva historia de usuario
Dueño del producto
(Product Owner)
Conceptos de tamaño y velocidad
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.

La velocidad es la
cantidad de story
points que
se completan por
iteración
 Velocidad del equipo
La velocidad del equipo en Story Point o
Como dueño del producto y del
release planning, el PO debe formular puntos historia.

objetivos a corto y  Ejemplo: un equipo de 3 personas hace en

medio plazo teniendo promedio 52 Story Point en un Sprint de 4
semanas. Con esta velocidad el equipo puede
en cuenta la velocidad. tomar historias de usuario que sumen máximo 52
Estos objetivos deben ser realistas,
Story Point.
compartidos y aceptados por el
equipo, permitiendo así que todas las
 Luego, se realiza el Tasking, aquí se define el
mayor
entregas maximicen el número de horas por cada tarea a realizar de la

Dueño del producto

valor posible. Historia de Usuario, el número de horas debe ser
par y una tarea no debe superar las 8 horas.
(Product Owner)
 Una vez realizado el Tasking se realiza el tiempo de
dedicación del recurso humano. Ver ejemplo
Refinamiento (refinement) de la Lista de Producto

Acto de añadir detalle, El Equipo Scrum decide cómo cinco o diez por ciento de El refinamiento no es para los
estimaciones y orden a los y cuándo se hace el cada Sprint debe ser elementos del Sprint actual,
elementos de la Lista de refinamiento dedicado por el Product es para sprints futuros
Producto Owner y el Development Con esta práctica, el Sprint
team para refinar (o Planning se vuelve
“arreglar”) el Product Backlog relativamente simple.
Refinamiento (refinement) de la Lista de Producto

El Product Backlog Refinement incluye:

Una reunión semanal

Análisis detallado de requisitos
programada regularmente con
Product Owner es
División de elementos grandes en
suficiente para que los equipos
otros más pequeños
experimentados ajusten el
Product Backlog
Estimación de nuevos elementos

Dueño del producto

Reestimación de los elementos (Product Owner)
existentes
Planificando el Sprint
Sprint Planing Meeting

Tema Uno
¿Qué puede hacerse en Una práctica clave en Scrum es que
este Sprint?
El Product Owner presenta la serie de funcionalidades cuánto
el equipo decide
que desea que sean implementadas y el equipo
realiza las preguntas necesarias para comprender los
requerimientos con el detalle suficiente que le
trabajo se
permita comprometerse a entregar dichas
funcionalidades al final del sprint comprometerá a
completar, en lugar de que el
Tema Dos: Product Owner se lo asigne
¿Cómo se conseguirá
completar el trabajo
seleccionado? Dueño del producto
Se centra en la planificación detallada de tareas de los
ítems a los que se ha comprometido
(Product Owner)
El Product Owner en los eventos de Scrum
Sprint Planning Meeting

► El Product Owner revisa el product backlog con el equipo de

desarrollo
► El Product Owner presenta la serie de funcionalidades que desea que sean
implementadas y el equipo realiza las preguntas necesarias
para comprender los requerimientos

► El Product Owner debe estar presente durante esta

reunión para poder guiar al equipo en la dirección correcta y responder
preguntas
Dueño del producto ► Al finalizar el equipo se compromete ante el Product Owner a desarrollar aquello
(Product Owner) que consideran podrá ser entregado testeado y funcionando al
finalizar el sprint
Objetivo del Sprint (Sprint Goal)

Es una meta establecida para el Sprint

Creado durante la reunión de
Planificación del Sprint

Puede ser alcanzado mediante la

implementación de la Lista de
Producto
A medida que el equipo de
desarrollo trabaja, se mantiene el
Guía para entender por qué está objetivo del Sprint en mente.
construyendo el incremento
Definición de “Terminado” (Definition of Done)

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

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

Los miembros del Equipo deben tener un

entendimiento compartido de lo que Los Equipos Scrum deben definir en
significa que el trabajo esté completado, conjunto la definición de “Terminado”
para asegurar la transparencia
Definición de “Terminado” (Definition of Done)

El Propietario del Producto y el

Equipo revisan la "Definición de
terminado" que todos los
elementos deben cumplir,
tales como, "Terminado significa
codificado según estándares,
revisado, implementado y desarrollo
basado en pruebas unitarias (TDD),
probado con automatización de
pruebas 100 por ciento,
integrado y Dueño del producto
documentado." (Product Owner)
Lista de Pendientes del Sprint (Sprint Backlog)
Es el conjunto de elementos de
la Lista de Producto Aunque el Product Owner
Elementos seleccionados para el Sprint, más no tiene control sobre
un plan para entregar el cuánto se compromete el
equipo, sabe que los
Incremento de producto y elementos a los que el
conseguir el Objetivo del Sprint equipo se compromete se
extraen de la parte superior
La Lista de Pendientes del del Product Backlog, es
Visibilidad Sprint hace visible todo el decir, los elementos a los
que ha calificado como los
trabajo que el Equipo de más importantes.
Desarrollo identifica como Dueño del producto
necesario para alcanzar el (Product Owner)
Objetivo del Sprint.
Creando el Sprint Backlog
Ejemplo de cómo se pueden estimar las horas disponibles para un Sprint de 2 semanas en un
equipo de 4 personas

Duración del Sprint

Días laborales durante el
Sprint

Total de horas disponibles

Miembros del equipo

Ejemplo: Lista de Pendientes del Sprint (Sprint Backlog)

Un ejemplo de un Sprint Backlog

Desglose de actividades
(tareas)

Estimación de esfuerzo

Ítem del Product Backlog

“Como comprador deseo poner el
libro en un carrito de compras”
El Sprint

Es el corazón de Scrum Contienen y consisten en:

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

Sprint
► Motiva al equipo con un objetivo claro
► Está disponible para su equipo
► Hace un compromiso recíproco de no
lanzar nuevos requerimientos durante el
sprint. Los cambios de requerimiento son
posibles pero solo fuera del sprint
► Comunica los diferentes mensajes a
Dueño del producto diferentes personas acerca del proyecto en
(Product Owner) todo momento
Cancelación de un Sprint

 01 Un Sprint puede  03 Se revisan todos

ser cancelado antes los Elementos de la
de que el bloque de Lista de Producto que
tiempo llegue a su se hayan completado
fin. y “Terminado”
01 02

05 03
 02 Solo el  04 Todos los
Dueño de Elementos de la Lista de
04
Producto tiene la Producto no
autoridad para completados se vuelven
cancelar el Sprint a estimar
 05 Se cancela si el
Objetivo del Sprint queda
obsoleto
Seguimiento y Comunicación
Del Progreso
Scrum Diario (Daily Scrum)
Es una reunión para que el
Equipo de Desarrollo sincronice
sus actividades y cree un plan El Product Owner podrá asistir a la
para las siguientes 24 horas reunión para entender lo que está
sucediendo en el sprint actual y
ayudar al equipo a resolver dudas.
Time-box: 15 minutos

Misma hora y en el mismo El Product Owner no deberá

lugar todos los días interferir con la autoorganización del
equipo ya que esto dañaría la
Preguntas
¿Qué hice ayer? Dueño del producto autonomía del equipo y podrá
(Product Owner) debilitar el compromiso
¿Qué haré hoy?
¿Veo algún impedimento?
El Product Owner en los eventos de Scrum

Scrum Diario
► La reunión diaria NO tiene como objetivo
reportar progreso al ScrumMaster, Product
Owner o cualquier otro stakeholder
► El Product Owner podría participar en un
daily meeting siempre y cuando se
mantenga en posición pasiva, hablando
únicamente cuando se le realicen
preguntas
Dueño del producto
(Product Owner)
Utilizando un tablero de tareas

La exposición de las tareas facilita la detección

El Product Owner tiene la
temprana de problemas al monitorizar

confianza de saber
continuamente la evolución del proyecto.

que el equipo se ha comprometido a

completar un conjunto realista
y claro de tareas que han La actualización de la información just-in-time,
elegido. ayuda a identificar en un primer momento los
posibles impedimentos, problemas y riesgos.
Dueño del producto
(Product Owner)
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
Cambios en SCRUM
El Product Owner puede
realizar los cambios que
Uno de los pilares de Scrum es que una vez que el sean necesarios en el Product
Equipo hace su compromiso, cualquier adición o
cambio debe ser aplazado hasta el próximo antes del
Backlog
Sprint.
inicio del siguiente Sprint.

Son posibles y
Si a mitad del Sprint el Propietario del Producto aceptables:
decide que hay un nuevo elemento en el que le • Adiciones
gustaría que el Equipo trabajara, no podrá realizar Dueño del producto • Eliminaciones
el cambio hasta el inicio del próximo Sprint. (Product Owner) • Modificaciones
• Re priorizaciones
Actualización del Sprint Backlog
Actualizaciones diarias del trabajo restante en el Sprint Backlog para la primera iteración de dos semanas

Desglose de actividades
(tareas)

Nueva estimación
Recurso de esfuerzo
Estimación inicial
de esfuerzo restante al final del
día
Ítem del Product Backlog
“Como comprador deseo poner el
libro en un carrito de compras”
Monitoreo de progreso (BurnDown Chart)

La gráfica Burn Down representa el

trabajo pendiente de realizar a lo largo del
tiempo, es decir, lavelocidad 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)
Burndown Chart es una práctica del
equipo de desarrollo que les permite
ser transparentes acerca de la Esta información permite
situación del trabajo reflejado en el al equipo y al Propietario
Sprint Backlog y decidir si es necesario del Producto discutir los
adaptar. En el caso de que así fuera, es el ajustes necesarios a los
Development Team el compromisos del equipo
para el Sprint actual de
responsable de hablar manera oportuna.
con el Product Owner
para que sea él o ella quien decida cual Dueño del producto
es el trabajo de más valor del Sprint. (Product Owner)
Actualización del 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)
Burndown de release (Release Burndown Chart)
Mide el ritmo de entrega de funcionalidades
testeadas a lo largo del tiempo. Los Product Owners
Este ritmo es conocido como la velocidad del equipo utilizan esta velocidad
para predecir el
ritmo con el cual el
equipo va a entregar
funcionalidad en el futuro,
lo que lleva a tener planes
de release cada vez más
predecibles.
Dueño del producto
(Product Owner)

El Release Burndown Chart muestra el progreso hacia la fecha de lanzamiento

 Interpretando resultados
Los datos son el instrumento de
trabajo principal de un Product
Owner, dado que se trata de
crear el mejor producto posible no
se puede dejar nada al azar.
Cuantos más datos tenga a
su alcance más se podrá optimizar
el desarrollo del producto.

Un buen Product Owner debe saber analizar con precisión todos los datos
Dueño del producto que llegan a sus manos. Ya sean los resultados de las pruebas del equipo de
(Product Owner) desarrollo o los últimos informes sobre el mercado. También debe saber interpretar los
deseos del cliente para transmitirlos al equipo de forma que puedan crear el producto
exactamente como espera el cliente
Identificando obstáculos
Conocer como las personas relacionadas con el producto evolucionan es importante para mantener el
producto al día
Los mejores Product Owners:
• Muestran su compromiso por hacer lo que sea
necesario para construir el mejor producto posible; y
eso significa comprometerse activamente con su
equipo para identificar y liberar obstáculos que se
presenten

• Son capaces de comunicar diferentes mensajes a

diferentes personas acerca del proyecto en todo
Dueño del producto
momento.
(Product Owner)
Revisión de Sprint (Sprint Review)

Sirve para inspeccionar el

Incremento y adaptar la Lista de  El Product Owner ayuda a
Producto si fuese necesario
inspeccionar lo entregado
por el equipo.
• Obtiene y proporciona el feedback
Time-box: 4 horas de los asistentes a la reunión para
poder adaptar el plan para sprints
subsiguientes
Ver y aprender lo que está pasando y
Tiene como objetivo facilitar la luego evolucionar en base a la
retroalimentación de información retroalimentación, en ciclos
y fomentar la colaboración. repetidos Dueño del producto
(Product Owner)
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 Su objetivo es
durante el siguiente Sprint.
inspeccionar
en profundidad cuán
Time-box: 3 horas colaborativo y productivo
es el equipo y cómo
hacer para mejorar en
ese sentido
Tiene lugar después de la Dueño del producto
Revisión de Sprint y antes de la (Product Owner)
siguiente Reunión de
Planificación de Sprint
Añadiendo valor
Valor comercial /Valor de negocio

Todo Product Owner debe poseer los

conocimientos básicos del funcionamiento
de la industria en la cual va a colocar el
producto

El Product Owner, al ser quien define los objetivos con el

cliente, es quien tiene mayor visión de cómo reaccionará el
producto una vez que esté en el mercado, teniendo la
capacidad de decidir como, cuando y donde debe comenzar
Dueño del producto el proceso de producción, pudiendo replantear los objetivos
(Product Owner) y alcances en cualquiera de las etapas de producción.
Voz del cliente

El Product Owner debe entender las necesidades y

prioridades de los stakeholders

Un Product Owner debe conocer perfectamente la organización de las

empresas y tener una persona de referencia en cada una de sus funciones,
departamentos o áreas.

Lo más importante del Product Owner es conseguir que el equipo sea capaz de
comprender un problema/oportunidad y proponer cómo abordarlo compartiendo
conocimientos y una misma visión.
Dueño del producto
(Product Owner)
¿Cómo trabajar con clientes, usuarios y otras partes interesadas?

Un Product Owner debe

encontrar la manera de que
Todos los Stakeholders
haya transparencia en el
deben tener acceso al
estado del producto de
Product Backlog, así
forma constante y simple:
pueden ver qué se va a
• Dar visibilidad hacer y dónde están sus
• Proporcionar información peticiones.
entendible, actualizada y
accesible

Dueño del producto

(Product Owner)
¡Gracias!