AyT SPOPC

Scrum Product Owner
Professional Certificate
SPOPC®
©2020 Ken Schwaberand Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at
http://creativecommons.org/licenses/by-sa/4.0/legalcodeand also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/ By utilizing
this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlikelicense of Creative Commons.
1 2 3
Introducción Generalidades Product Owner
C
o
n 4 5 6
t Visión & Definición del Construyendo el Velocidad
Producto Product Backlog
e
n
i
d
7 8 9
Estimación Priorización Refinamiento
o
9
Tópicos de Refuerzo
Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Objetivos
ENTREGAR
El conocimiento necesario para entender el
rol del Product Owner, sus implicaciones y
sus responsabilidades; además de reforzar
los conceptos explícitos para certificarse
como Scrum Product Owner Professional
Certificate (SPOPC®).

El Facilitador
Emprendedor, consultor, conferencista, facilitador • Project Manager Professional (PMP®) By PMI (PMP N° 1433488).
experiencial y docente. Ha ocupado importantes
cargos como director de programas, director de • Disciplined Agile Senior Scrum Master (DASSM™) By PMI (#2978841).
proyectos y CEO en importantes organizaciones • Certified Scrum@Scale Practitioner By Scrum@Scale®.
multinacionales en Latinoamérica, Caribe y Estados
• Project Manager Office Certified Practitioner (PMO-CP®) By PMO Global Alliance.
Unidos.
• PM4R Trainer Professional By Banco Interamericano de Desarrollo – BID.
Cuenta con más de 20 años de experiencia en temas
como: Gestión del Cambio, Cultura Organizacional, • PM4R Trainer Leadership By Banco Interamericano de Desarrollo – BID.
Agilidad y Transformación Organizacional, Estrategia • Scrum Master Professional Certified (SMPC) By Certiprof.
Organizacional, Desarrollo Organizacional, Gestión
Estratégica de RRHH, Innovación, Gerencia TI y • Scrum Product Owner Professional Certified (SPOPC) By Certiprof.
Dirección de Proyectos. • HCMBOK® Certified Instructor By Human Change Management Institute.
Creador de las certificaciones “Coaching For Project • HCMBOK® To AGILE Practitioner By Human Change Management Institute.
Managers (C4PM®)”, “Coaching For Change Managers
• HCMBOK® 3G Master Professional By Human Change Management Institute.
(C4CM®)”, “Culture Management Professional
Certified (CMProC®)” y “Certified Professional • HCMP® 3G Expert Professional By Human Change Management Institute.
Consultant (CPC®)”. • HCMBOK® 3G Practitioner By Human Change Management Institute.
Autor del Cuerpo de Conocimiento para la Gestión de • Lean Change Management By Lean Change Management Academy.
la Cultura Organizacional OCMBoK™: Organizational
Culture Management Body of Kowledge™. • ICAgile Certified Professional Coaching Agile Transitions (ICP-CAT), By ICAGILE.
Coautor del Libro “TRASCENDER, Como hacer que su • Leadership TotalSDI Facilitator & Coach Certified By Personals Strengths Publishing USA
Edgar Alvarez negocio permanezca en el tiempo”, colaborador en el
desarrollo del HCMBOK® Versión 3 y editor del
• Management 3.0 By Jurgen Appelo.
• Executive Coach by The International School of Coaching (TISOC).
HCMBOK® Agile 2020.
• Corporate Coach by The International School of Coaching (TISOC).
Actualmente socio fundador y CEO de la empresa
consultora Actitud & Talento®, en Ecuador y con • Higher Management Coach by The International School of Coaching (TISOC).
operaciones en Latinoamérica y El Caribe, Past • Facilitador Directivo Coach (DC) by The International School of Coaching (TISOC).
President del PMI® Capítulo Ecuador y Subject Matter
• NLP™ Master Practitioner by Richard Bandler and The Society of Neuro-Linguistic Programming™.
Expert (SME) del Human Change Mangement Institute
(HUCMI®).

Introducción

Manifiesto Ágil | Cambio de Paradigma
Adaptado de: What’s Missing In The Agile Manifesto: Mindset by Stephen Denning. http://www.agilealliance.org/whats-missing-in-the-agile-manifesto-mindset

Predictivo versus Adaptativo
FACTOR
PREDICTIVO ADAPTATIVO
DIFERENCIAL
PREDICTIVO ADAPTATIVO
Guiado por un plan Guiado por visión y valor ENFOQUE Predictivo (rígido) Adaptativo (flexible)
ENTORNO Fijo Cambiante
FIJOS CONTEXTO Simple Complejo

ALCANCE COSTOS TIEMPO
COMUNICACIÓN Normas por escrito Debate “cara a cara”
Especializados Multi-disciplinares
EQUIPOS
Jerarquizados Auto-organizados
AUTONOMÍA Baja Alta
CALIDAD
ALINEAMIENTO Bajo Alto
CALIDAD
Alcance fijo. Tiempo-Costo Máximos Fijos
PRESUPUESTO
Tiempo-Costo Variable Alcance ajustable
Parciales, regulares y de valor

ENTREGA DE VALOR Todo al final
creciente
ESTIMADOS COSTOS TIEMPO ALCANCE VELOCIDAD No es prioritaria Se prioriza al alcance

Al final: Riesgo de fracaso
FEED-BACK En cada entrega: Permite éxito parcial
total

Generalidades

Agilidad
“Agilidad es la
capacidad de crear y
En cualquier tipo de disciplina de
gestión, ser ágil es una cualidad, responder al cambio
por lo tanto, esto debe ser una con el fin de obtener
meta que se debe tratar de
alcanzar. ganancias en un
La gestión de proyectos Agiles entorno empresarial
especialmente, implica la
adaptabilidad durante la creación turbulento.”
de un producto, servicio, o
cualquier otro resultado.
• El 80% de todos los proyectos
emplearán Métodos Ágiles en “La agilidad es la capacidad
los próximos años (Gartner).
de equilibrar la flexibilidad
• Proyectos que usan
metodologías Agiles son mas y estabilidad.”
exitosos que los proyectos que
usan metodologías en cascada
(Standish Group 2010).

Algo de Historia & Simbología
En 1993, Jeff Sutherland y su equipo en

La historia de Scrum se puede rastrear Easel Corporation crearon el proceso de
desde 1986 en un artículo de la Scrum para ser utilizado en los procesos
Harvard Business Review, “El nuevo
de desarrollo de software combinando
nuevo juego para el desarrollo de
los conceptos del artículo de 1986 con
productos” ( Takeuchi y Nonaka 1986).
los conceptos del desarrollo orientado
Este artículo describe como empresas
como Honda, Canon y Fuji-Xerox a objetos, un control de procesos
producen nuevos productos a nivel empírico, desarrollo iterativo e
mundial utilizando un enfoque incremental, procesos de software y
escalable y basado en equipos mejora de la productividad, así como el
integrales para el desarrollo de desarrollo de sistemas complejos y
productos. Este enfoque enfatiza la dinámicos.
importancia de dar poder a los equipos
En 1995, Ken Schwaber publica el
auto-organizados.
primer informe sobre Scrum en
El artículo de 1986 fue una influencia OOPSLA 1995. Desde esa fecha,
para desarrollar muchos de los Schwaber and Sutherland, juntos y
conceptos que dieron nacimiento a lo separados, han producido y publicado
que hoy llamamos Scrum. Scrum no es
varias especificaciones para Scrum,
un acrónimo, sino un término extraído
incluyendo Desarrollo de Software
del Rugby, que se refiere a la manera
en cómo se reinicia el juego luego de Agile con Scrum, Gestión de Proyectos
una falta o cuando la bola se ha ido Agiles con Scrum y la Guía de Scrum.
fuera del juego.

Elementos Scrum
1 7
20
CULTURA ROLES EVENTOS ARTEFACTOS
Sprint
PILARES Product Owner Product Backlog
Sprint Planning
VALORES Scrum Master Daily Meeting Sprint Backlog

Sprint Review
PRINCIPIOS Development Team Sprint Retrospective Incremento
Product Backlog Refinement

Elementos Scrum
2 0
20
CULTURA SCRUM TEAM EVENTOS ARTEFACTOS
PILARES Product Owner Sprint Product Backlog

Sprint Planning
VALORES Scrum Master Daily Meeting Sprint Backlog
Sprint Review
PRINCIPIOS Developers Sprint Retrospective Incremento
Product Backlog Refinement

Pilares Scrum
Empirismo TRANSPARENCIA
• El empirismo se basa en tomar decisiones basados en la información
concreta obtenida de la observación que muestra el progreso del
desarrollo de producto, los cambios en el mercado y los comentarios de
los cliente.
• Se implementa un proceso empírico en el que el progreso se basa en la INSPECCIÓN ADAPTACIÓN
observación y la experimentación en lugar de en los detalles.
• Lo contrario al empirismo es usar planificación previa, procesos definidos,
planes predictivos, hechos no concretos.
La inspección es “revisar” Adaptación, sucede La Transparencia permite

el avance del proyecto y cuando uno o más que todas las facetas de
el producto. No debe ser aspectos de un proceso cualquier proceso de
tan frecuente como para se desvían de límites Scrum sean observadas
que lleve mucho tiempo, aceptables y que el por cualquier persona.
pero debe ser lo producto resultante será
suficientemente efectiva inaceptable, el proceso o Esto promueve un flujo
como para que en cada el material que está fácil y transparente de
nueva iteración (o Sprint) siendo procesado deben información en toda la
El Control de Procesos Empíricos tiene las siguientes se detecten variaciones ajustarse. organización y crea una
características: indeseadas. cultura de trabajo abierta.
Aprende a medida que avanzamos.
Esperar y aceptar el cambio.
ntación
Inspeccionar y adaptar usando ciclos cortos de desarrollo. p o rta n to d a la impleme
Las estimaciones son sólo indicativas y pueden no ser exactas. Tres pilares so írico.
procesos emp
del control de
Valores Scrum
Los equipos Scrum se enfocan en un conjunto acotado
de características por vez (Sprint, Product Goal). Esto permite
FOCO que al final de cada Sprint se entregue un incremento
(producto) de alta calidad y adicionalmente se reduce el time-
to-market.
Debido a que los equipos Scrum trabajan como verdaderos

equipos nos apoyamos entre compañeros para así asumir
CORAJE compromisos desafiantes. Es fundamental para el éxito de un
equipo. Hacer las cosas correctas, trabajar a través de los
problemas. Mejorar constantemente.
CO FRANQUEZA Nos permite una discusión abierta de los problemas que

M
PR tenemos al realizar el proyecto, la información esta disponible
OM para todos. Apertura al dar a conocer la organización, el
trabajo, el progreso, el aprendizaje y los problemas.
IS
O
Cada integrante del equipo debe tener un compromiso para
con el resultado, a través del logro de los objetivos.
Ya que el grupo trabaja en forma conjunta

RESPETO compartiendo éxitos y fracasos se fomenta el respeto mutuo.

Principios Scrum
1. Control del proceso empírico: Este 2. Auto-organización: Este principio se enfoca en

principio enfatiza la filosofía central de los trabajadores de hoy en día, que entregan un
SO
Scrum con base a las tres ideas OCE valor considerablemente mayor cuando se auto-
DEL PR AUTO-ORGANIZACIÓN organizan, lo cual resulta en equipos que poseen un
principales de transparencia, inspección L ICO
TRO
y adaptación. CON EMPÍR gran sentido de compromiso y responsabilidad; a su
vez, esto produce un ambiente innovador y creativo
que es más propicio para el crecimiento.
6. Desarrollo iterativo: Este principio define

el desarrollo iterativo y hace énfasis en cómo 3. Colaboración: Este principio se centra en las
DE
gestionar mejor los cambios y crear tres dimensiones básicas relacionadas con el
CO
productos que satisfagan las necesidades del SA
PRINCIPIOS
trabajo colaborativo: conocimiento, articulación
LA
cliente. También de linea las RR
BO
OL y apropiación. También fomenta la gestión de
RA
responsabilidades del Product Owner y las de LO
proyectos como un proceso de creación de
CIÓ
Scrum
ITE
la organización relacionadas con el desarrollo valor compartido con equipos que trabajan e
N
RA
iterativo. interactúan conjuntamente para ofrecer el
TIV
mayor valor.
O
5. Time-boxing: Este principio describe cómo el

tiempo se considera una restricción limitante en
Scrum, y cómo este se utiliza para ayudar a manejar TIME-BOXING DA 4. Priorización basada en valor: Este principio
eficazmente la planificación y ejecución del proyecto. PRIORIZACIÓN BASA
Los elementos del time boxing en Scrum incluyen EN VALOR pone de relieve el enfoque de Scrum para ofrecer
Sprints, Daily Standups, reuniones de planificación el máximo valor de negocio, desde el principio del
del sprint y reuniones de revisión del sprint. proyecto hasta su conclusión.

Product Owner

Roles Ágiles | Conflicto
Existen muchas formaciones con las

que desarrollar el conocimiento
necesario para cada uno de los roles,
sin embargo, son perfiles cuyas
habilidades más importantes son las
sociales y emocionales, ya que la
cultura ágil se enfoca en la
colaboración y la transparencia y, a
pesar de que hay herramientas que
facilitan estos valores, somos las
personas las que ejecutamos acciones
con dichas herramientas, por lo tanto,
la experiencia es el mejor de los
maestros.

Equipo Scrum
1 7
20 Scrum Master (SM)
• “El Dueño de Producto (Product Owner) es el

responsable de maximizar el valor del producto y del
Product Owner (PO)
trabajo del Equipo de Desarrollo.
• El Dueño de Producto es la Única persona responsable
de Gestionar la Pila de Producto (Product Backlog).” PO conunica los
requerimientos
SM asegura un ambiente
<Scrum Guide® 2017> empresariales
laboral adecuado para el
priorizados el Equipo
Scrum. Elabora el Equipo Scrum
Backlog de producto
Stakeholders Stakeholders proporcionan sus priorizado y define
(Cliente) requerimientos al PO criterios de aceptación.
Equipo Desarrollo (TD)
El PO entrega el valor al cliente mediante TD y PO demuestran el

lanzamientos incrementales del producto incremento del producto
al PO y a los Stakeholders
TD construye los Incrementos

Roles Tradicionales vs. Ágiles
Product Manager Product Owner Project Manager Scrum Master
Asegurar que el Proyecto cumpla los objetivos

Investigación de Mercado Experto Scrum
Negociar el trabajo con el equipo
Facilitador, creativo y
Visión, Voz del Cliente empoderado.
Gestionar el alcance, fechas y presupuesto
Alentar la
auto-organización
Gestionar la Comunicación con los Stakeholders
Precio Alentar el Mejoramiento
del Equipo en prácticas de
Gestionar riesgos de negocio desarrollo
Comunicaciones al
Mercado
Gestionar/Priorizar
Product Backlog
Documentación Visualizar y comunicar información
Requerimientos de Disponible Para el Equipo
Marketing
Listo Para el Sprint Remover Impedimentos, ayudando al equipo para
Planning completar su trabajo
Permitir al equipo que
planifique el trabajo
Respetar los límites del Creación Detallada del Miembro del Equipo
Sprint WBS (No Gerente)

Product Owner
Responsabilidades
• Maximizar el valor del producto.
• Gestión efectiva del Product Backlog.
El Product Owner (PO) representa la voz del cliente, y es • EL Product Owner puede delegar.
el encargado de maximizar el valor del producto. • El Product Owner sigue siendo el responsable aunque delegue.
• El Product Owner puede representar las necesidades de muchos interesados
Un PO siempre debe mantener la visión de las partes en el Product Backlog.
interesadas. • Para ajustar el contenido u orden del Product Backlog se requiere convencer
(negociar con criterio) con el Product Owner.
El debe entender y apoyar las necesidades e intereses de • Para que los Product Owners tengan éxito, toda la organización debe respetar
todos los Stakeholders. sus decisiones.
• Sus decisiones son visibles en el contenido y el orden del Product Backlog, y a
través del Incremento inspeccionable en la revisión de Sprint (Sprint Review).
Características
El Product Owner no es un comité, es una persona. La gestión efectiva del Product Backlog que
incluye:
• Desarrollar y comunicar explícitamente el Objetivo del Producto.
• Crear y comunicar claramente los elementos del Product Backlog.
• Ordenar los elementos del Product Backlog (Decidir).
• Asegurarse de que el Product Backlog sea transparente, visible y se entienda.

Product Owner
El Dueño de Producto es el responsable de maximizar el Decidir que construir… ¡Y que no!

valor del producto. El cómo se lleva a cabo esto podría
Recoger y tener claros los requisitos del El Pro
variar ampliamente entre distintas organizaciones, du
producto, servicio. dar ó ct Owner
Equipos Scrum e individuos. El equ rdenes al no debe
El Dueño de Producto es la única persona responsable de Definir buenas historias de usuario. ipo equi
gestionar la Lista del Producto (Product Backlog). La en ot no debe tr po.
r
distin s requis abajar
o
gestión de la Lista del Producto incluye: Fijar criterios de aceptación para cada Produ tos a los itos
• Expresar claramente los elementos de la Lista del historia de usuario. ct Ow
ne
que e
l
Producto; el Bac r incluya e
• Ordenar los elementos en la Lista del Producto para Ordenar y priorizar los ítems del Product klog. n
Backlog.
alcanzar los objetivos y misiones de la mejor manera
posible; Definir el Producto Mínimo Viable.
• Optimizar el valor del trabajo desempeñado por los
desarrolladores (Developers); Acordar junto al Scrum team una
• Asegurar que la Lista del Producto es visible, definición de DONE.
transparente y clara para todos, y que muestra aquello El Produc
en lo que el equipo trabajará a continuación; y,
Definir el plan de releases. t
conocer la Owner debe
velo
• Asegurar que los desarrolladores (Developers) Estar disponible y accesible para los los develo cidad de
entiende los elementos de la Lista del Producto al Developers. realizar e pers, para
stimac
nivel necesario. cuando e iones de
Es el responsable de cancelar el sprint si starán
implemen
ocurre un imprevisto extremo. tadas las
Debe Participar en las Reuniones necesidad
es en el
Asegurarse de que el Product Backlog es producto
.
visible para todo el mundo.
Asegurarse de que todo el mundo
Daily Meeting Sprint Sprint Sprint Prodcut Backlog entiende los ítems del Product Backlog.
(Optativa) Planning Review Retrospective Refinement

Product Owner | Características
7
SIEMPRE
1
VISIÓN COMPRENDER LA
20
COMPETENCIA DISPONIBLE COMUNICADOR Y
COLABORADOR
EMPODERADO
NEGOCIADOR
MENTALIDAD MVP

Product Owner | Responsabilidades
0 1 7 • Responsable de que será desarrollado y en que orden.
2 • Empoderado para ser el punto central del Producto.

• Comunica a los otros practicantes la visión de lo que
se espera obtener.
• Responsable del éxito de la solución desarrollada.
• Responsable de que se realice el trabajo de que de
El Product Owner (PO) mayor valor de negocio.
representa la voz del cliente, • Responsable de revisar el producto desarrollado.
y es el encargado de • Trabaja de forma colaborativa con el Scrum Master y el
maximizar el valor del equipo de desarrollo.
producto. • Debe estar disponible para responder las preguntas
sobre el producto, tan pronto como se presenten.
Un PO siempre debe • Responsable del retorno de la inversión (ROI).
mantener una visión dual. • Guiar el esfuerzo de desarrollo.
1. El debe entender y • Comunicación continua con los involucrados.
apoyar las necesidades • Mantener la moral del equipo.
• Disponibilidad para resolver dudas del equipo.
e intereses de todos los • Toma de decisiones bien analizadas .
Stakeholders, • Reunirse con Ios involucrados.
2. Comprende las • Asistir a las sesiones de planeación.
necesidades y el • Aclarar los requerimientos.
• Dar retroalimentación.
funcionamiento del
• Aceptar las historias de usuario.
Development Team. • Refinamiento del Backlog.
• Actualizar el plan de la entrega.

Product Owner & Producto
1 7
20
CALIDAD DEL PRODUCTO
• El PO es responsable retransmitir al equipo la expectativa de calidad.
• EI equipo de desarrollo es responsable de cubrir esa expectativa.
• EI equipo de desarrollo debe involucrar la expectativa de calidad en Ia
• Responsable de revisar el producto definición de ”Hecho” (Done).
desarrollado. • EI PO es responsable de la calidad en los requerimientos.
• Trabaja de forma colaborativa con el Scrum
Master y el equipo de desarrollo. PO & CALIDAD DEL PRODUCTO
• Debe estar disponible para responder las • Entender con claridad las expectativas, retos y uso del producto.
preguntas sobre el producto, tan pronto como • Discutir los requerimientos con el equipo.
se presenten. • Hacer el Backlog del producto disponible y transparente.
• Conocedor del mercado y administrador. • Entender que la calidad no se logra solo con pruebas.
• La integración continua y automatización de pruebas son
• Empoderado para ser el punto central del fundamentales para la entrega Ágil.
Producto. • NO presionar el compromiso, confiar.
• El Dueño de Producto es la Única persona • NO aceptar productos que no cumplan con la definición de "Hecho”.
responsable de Gestionar la Pila de Producto • Escuchar al equipo cuando identifica problemas técnicos que deben
(Product Backlog). ser corregidos.
• Si se identifican problemas serios técnicos apoyar la refactorización
propuesta.
• Entender Ia profundidad requerida de las pruebas.

Product Owner & Gestión del Producto
Refinamiento Visión
del Producto
Definiendo el
Definición
Product Backlog
del Producto
Comunicación y negociaciones con diferentes involucrados:

Clientes, Usuarios, Equipo Scrum, Comerciales, Ventas, Servicios, Operaciones,
Gerencia, Niveles Directivos, entre otros.
Cancelación Sprint
Un Sprint puede ser

cancelado antes de que el
bloque de tiempo 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.

Visión & Definición del Producto

Release Planning
Un “release plan” o plan de proyecto es un

conjunto de historias de usuario (normalmente
épicas) agrupadas por “releases” (entregas) o
versiones del producto que se ponen a
disposición de los usuarios incrementando el
valor para estos respecto de la anterior.
También nos referimos a él como “plan de
versiones” o “plan de entregas”.
Podemos imaginar que el producto en
construcción es una cebolla a la que vamos
añadiendo una capa con cada “release”.
A la primera de esas versiones se le suele
denominar MVP (o Producto Mínimo Viable).
El concepto de “release” ayuda al equipo a
enfocarse, les da un contexto y evita moverse
sin rumbo de una iteración a otra.
El fin del “timebox” es la oportunidad para
pararse, buscar oportunidades de mejora y
revisar el plan incorporando lo aprendido,
incluyendo el feedback de los usuarios, si es que
ya lo tenemos.

Visión & Definición del Producto

Producto Mínimo Viable
Productos viables mínimamente, perfectos para

reducir incertidumbres, probar hipótesis, re-
MÍNIMO + VIABLE definir conceptos y mejorar iterativamente el
producto según el mercado responde…
Es usado para probar rápidamente de
manera cuantitativa y cualitativa la
respuesta del mercado a un producto o
una funcionalidad específica.
Un MVP tiene sólo aquella
funcionalidad requerida para mostrar el
producto al cliente y su principal
MÍNIMO VIABLE
objetivo es evitar el desarrollar
productos que los clientes no quieran y
maximizar la información obtenida
sobre los clientes con base en el costo y
esfuerzo invertidos.
A pesar de su nombre, el MVP no se
trata solamente de crear un producto.
Es una estrategia y un proceso Productos que, generalmente tras una gran
Productos insuficientes en sus
enfocados en crear y vender un inversión de tiempo y dinero, salen al mercado
funcionalidades o valor aportado.
producto a un grupo de clientes. Es un con una gran cantidad de funcionalidades que
Generalmente, son productos de mala calidad
proceso iterativo de generación de nadie (usuarios finales) ha probado todavía y
que no responden a la necesidad esencial de
ideas, desarrollo de prototipos, que es probable que no respondan a las
sus potenciales usuarios, y que, por tanto,
presentación, recolección de datos, necesidades del usuario final.
nadie quiere usar.
análisis y aprendizaje.

“Un producto con el MÍNIMO

de CARACTERÍSTICAS necesarias
para lograr un objetivo
específico y que los clientes
estén dispuestos a pagar de
alguna forma con un recurso
escaso.”
<Brant Cooper>
“Es la versión de un nuevo producto que permite a un

equipo recolectar la MÁXIMA CANTIDAD DE
APRENDIZAJE validado sobre clientes al menor coste.”
<Eric Ries>


Agile Inception
Agile inception es un concepto introducido por

primera vez en el libro The Agile Samurai, de Jonathan
Rasmusson. Esta práctica deriva de los workshops de
reflexión estratégica, los cuales son algo más maduros.
Esencialmente se trata de técnicas de
conceptualización que deberían emplearse en el
proceso de iniciación de un proyecto para aumentar la
probabilidad de éxito del producto resultante.
Estas técnicas se pueden usar igualmente para
clarificar la estrategia (misión, visión y propuesta de
valor) del proyecto de empresa de cualquier
compañía; o bien, para reorientar proyectos de
cualquier índole.
El principal objetivo del agile inception es construir
una visión completa sobre el concepto de producto y
que además no caiga en sesgos personales, es decir,
que esa visión sea compartida y comprendida de
idéntica forma por los principales interesados.

Agile Inception | Product Vision Board
Para crear una visión y estrategia del producto antes de

arrancar un workshop de historias de usuario para
descubrir requerimientos y prioridades el Product Vision
Board creado por Roman Pichler es una opción viable.
Visión: Como toda visión, además de ser inspiradora
tendrá una intención positiva y motivación que la respalde
Grupo Objetivo: Identifica el segmento de mercado al
que se apunta. Quienes usarán el producto (usuarios) y
quienes van a comprarlo (clientes)
Necesidad: La propuesta de valor del producto se basará
en los problemas y frustraciones, beneficios, ventajas para
los usuarios y clientes a convencer de que se utilice o
compre el producto.
Producto: Pitchler recomienda que de 3 a 5
funcionalidades claves para que el producto sea exitoso
es suficiente. En esta sección se sugiere épicas alineadas a
la propuesta de valor y necesidades identificadas
Valor: Justificar por qué vale la pena invertir en el
producto. Esta sección intenta hacer explícitos los
beneficios del producto a nivel de la organización
alineándolo a los objetivos. Los objetivos pueden ser
monetarios (ganar, preservar o ahorrar) y no monetarios
(reputación, motivación, prestigio etc)

Agile Inception | Lista del SI y NO
LISTA DEL SI y NO
Es una técnica para delimitar alcance.

• Se prepara una lista en un tiempo (Timebox)
de máximo 20 minutos.
• Se definen las cosas que queremos dentro
del alcance y se acuerdan las cosas que
quedan fuera.
• Se toman nota de las cosas que no podemos
decidir o definir (al menos por ahora).
• Se anotan los puntos en conflicto para
discutir al final. Otros se definirán a lo largo
del proyecto.
• La lista sirve de input para construir el
backlog. Tanto para añadir o limitar
funcionalidad a lo largo del proyecto.

Agile Inception| Elevator PITCH
Imagina que un buen día te subes a un

ascensor y en él te cruzas con un empresario,
directivo o cliente con quien podrías entablar
producto
el negocio de tu vida. Es una oportunidad
única: sabes que nunca más volverá a
repetirse.
Sin embargo, tienes apenas 2 minutos (o
incluso menos) para romper el hielo y dirigirle
unas cuantas palabras que despierten su
interés por tu marca, producto o servicio. No
valen los titubeos ni las dudas. Debes ser
preciso, directo y contundente a la hora de
transmitir tu mensaje. ¿Qué le dirías? ¿Cuál
sería tu apuesta?
De eso se trata el Elevator pitch, una técnica
propia del siglo XXI para presentar las ideas de
negocio ante potenciales clientes o terceras
personas que de alguna u otra forma estén
interesados en ella.
https://www.youtube.com/watch?v=2b3xG_YjgvI

Agile Inception | Stakeholders
GRÁFICO DE INTERESADOS
• Se lista y mapea los interesados por poder
e interés.
• Se representa a cada interesado por un
color diferente o figura geométrica.
• De acuerdo al análisis de equipo se ubica
en el mapa.
CÍRCULO DE INTERESADOS
• Se piensan en los distintos interesados,
quienes son, a donde pertenecen, roles,
etc.
• Se conversa sobre el impacto, interés o
poder que ellos generan en el producto o
proyecto.
• Al finalizar se revisan los diferentes mapas
y se trazan planes de acción, de ser
necesario.

Agile Inception | Technical Board
producto
• Se realiza con personas que tienen buena visión
técnica. Estos conceptualizan la visión a
desarrollar.
• Se puede involucrar a un experto y se construye
la solución (técica) a alto nivel.
• Se busca especificar algunos detalles de cómo
sería el proyecto o producto, para que la gente
de las otras áreas lo pueda revisar y de su
feedback.
• La complejidad técnica resume aspectos
generales de la construcción del producto.
• El backgound del equipo es analizado para
estimar la brecha técnica.
• La brecha técnica considera los conocimientos
técnicos que carece el equipo.
• Los riesgos técnicos lista los sucesos que
afectarían positiva o negativamente al proyecto.

Agile Inception | Riesgos
producto
• Se discute lo que potencialmente

podría quitar el sueño durante el
proyecto.
• Se discute las oportunidades que
podrían impulsar el desarrollo del
proyecto.
• Los actores exponen el miedo
durante las diferentes etapas del
proyecto: inicio, desarrollo, pruebas,
producción, etc.
• Se prioriza los riesgos
• Se lista algunas medidas con las
cuales se puede mitigar estos riesgos.

Agile Inception | Restricciones
producto
• Seleccionar restricciones tempranas que

ayuden a pensar si los cambios futuros
están alejados o no de la idea original.
• Se sugiere pasen a un proceso de
priorización.
• La visibilidad de esta lista para el equipo es
importante, a lo largo de todo el proyecto.
• Se consideran restricciones internas y
externas, en función de la organización
ejecutante.
• Si son varios equipos se discute y se
prioriza en conjunto a fin de tener una sola
lista.
• Se debe socializar con los diferentes
interesados.

Construyendo el Product Backlog

Product Backlog
Se puede ver desde la perspectiva de una iteración

o sprint, de una release o de todo el producto. En
cualquier caso, sigue siendo una lista priorizada de
historias de usuario más o menos detalladas,
aunque hablemos en cada caso de sprint backlog,
release backlog o product backlog.
¿Para qué sirve?

• Se hace para tener una perspectiva de todo lo
que se quiere hacer y tener claras las prioridades
del cliente.
• Ayuda a que el equipo sea más autodisciplinado y
respete las prioridades del cliente.
• También permite que el cliente pueda introducir
cambios durante la vida del proyecto.
• Ayuda a manejar la incertidumbre durante el
proyecto porque empuja a describir con más
detalle las historias más importantes y a
relativizar la importancia de detallar historias de
menor prioridad.
• Es más ligero que un documento de requisitos
exhaustivo.

Product Backlog
Se puede ver desde la perspectiva de una

iteración o sprint, de una release o de todo el
producto. En cualquier caso, sigue siendo una
lista priorizada de historias de usuario más o
menos detalladas, aunque hablemos en cada
caso de sprint backlog, release backlog o product
backlog.
¿Para qué sirve?

• Se hace para tener una perspectiva de todo lo
que se quiere hacer y tener claras las
prioridades del cliente.
• Ayuda a que el equipo sea más
autodisciplinado y respete las prioridades del
cliente.
• También permite que el cliente pueda
introducir cambios durante la vida del
proyecto.
• Ayuda a manejar la incertidumbre durante el
proyecto porque empuja a describir con más
detalle las historias más importantes y a
relativizar la importancia de detallar historias
de menor prioridad.
• Es más ligero que un documento de requisitos
exhaustivo.
Product Backlog
Product Owner (PO)
Ítems muy refinados
(detallados), listos para
incluir en el próximo
Sprint. Historias de
Usuario pequeñas.
Ítems Medianamente
refinados (menos
detallados). Historia de
Usuario grandes.
Ítems poco refinados

(poco o nada detallados),
Épicas.
Stakeholders

Product Backlog
TEMAS
• Se denomina tema a una colección de épicas relacionadas
para describir un sistema o subsistema en su totalidad. Por
ejemplo, en un sistema de software para gestión contable,
el conjunto de épicas: "Altas, bajas y mantenimiento de
clientes" "Facturaciones puntuales y recurrentes",
"Consultas de navegación y acciones de fidelización",
"Pedidos", "Devoluciones" se podrían denominar como el
tema de la gestión de clientes.
ÉPICAS
• Se denomina épica a una historia de usuario que, por su
gran tamaño, el equipo descompone en historias con un
tamaño más adecuado para ser gestionada con los
principios y técnicas ágiles: estimación y seguimiento
cercano.
HISTORIAS DE USUARIO
• Es una representación de un requisito del usuario en forma
escrita, de una o dos frases, utilizando el lenguaje común del
usuario.
TAREA
• Es una representación del requisito que está en lenguaje del
usuario, pero de una forma técnica donde está definido
cómo se va a trabajar y quién van a participar.
Product Backlog
TEMA ÉPICA HISTORIAS DE USUARIO

Product Backlog

User Story Mapping
Adaptado del sitio web: https://scrum.menzinsky.com/2018/11/como-se-hace-un-user-story-mapping.html
Es una técnica descrita por Jeff Patton en su libro "User Story Mapping: Discover the
Whole Story, Build the Right Product", en el 2014. Es muy útil para construir una pila
de producto (Product Backlog) que vaya más allá de una simple lista de historias de
usuario y epicas. Esta técnica permite los siguientes beneficios:
• Visión compartida: a través de la participación de todos los involucrados se
construye una visión compartida del producto, lo que facilita mantener el foco en la
solución a lo largo de su construcción.
• Alineación: los miembros del equipo y negocio (Propietario del Producto,
interesados y clientes) podrán estar alineados sobre lo que se va a construir.
• Mejor entendimiento de lo que quieren los clientes: a través del modelado de los
clientes y de lo que van a hacer con el producto, se puede alcanzar un alto nivel de
entendimiento de sus verdaderas necesidades.
• Mejor entendimiento de los problemas que enfrentan los clientes: se puede lograr
un alto nivel de empatía con los clientes, tanto por participar en la dinámica, como
también por tener la oportunidad de ponerse en su lugar a la hora de modelar lo
que hará con el producto y cómo lo hará.
• Un mapa de historias de usuario ordenado por versión: al modelar un backbone
del flujo del cliente a través del producto, podemos definir el conjunto de historias
que conformarán el Mínimo Producto Viable (MPV) a sacar al mercado, que le
permita a los usuarios llevar a cabo todo el flujo de una manera básica (con por lo
menos una funcionalidad por cada actividad obligatoria en el flujo), así como una
idea inicial de las siguientes versiones que se prevé sacar posteriormente, que
puede cambiar en función del feedback y otros elementos del mercado obtenidos
cuando salga a producción el MPV y cada una de las versiones siguientes.

User Story Mapping

User Story Mapping

User Story Mapping

User Story Mapping

User Story Mapping | Ejemplo

User Story Mapping | Ejemplo

Historias de Usuario
Independientes entre sí, para poder llevarlas a cabo

en el orden que más nos convenga según las
prioridades que establezca el Product Owner.
Negociables con el Product Owner para establecer los
limites adecuados, la parte de conversación de una
historia es esencial
Valor para el usuario, el PARA es fundamental. Se ha
de entender la funcionalidad siempre y la tiene que
entender todo el Equipo de Desarrollo
Estimable. El Equipo de Desarrollo que la vaya a
recoger, debe ser capaz de estimar el esfuerzo que
supone realizarla.
Small de un tamaño que el equipo de desarrollo
Las historias de usuario, o user stories, tienen su origen en el trabajo de Kent pueda asumir en un sprint (3-4 días). Y a ser posible
Beck, a finales de los 90’s. Él notó (supongo que no fue el único…), que diferentes que el equipo pueda asumir varias dentro del sprint
personas leyendo el mismo documento, pueden interpretarlo de maneras
completamente diferentes. Entonces incluyó dentro de “Extreme Programming” Testeable para poder confirmar que está
el término “historia de usuario” para definir algo que un usuario quiere hacer correctamente implementada. O dicho de otra forma
dentro de un sistema, y de lo que se hablará con más detalle antes de construirlo. con los Criterios de Aceptación establecidos.

Historias de Usuario | Card
ROL NECESIDAD BENEFICIO
Una oración que resume la Con estas tres líneas

necesidad y se escribe en una
tarjeta. conoceremos:
Es frecuentemente utilizado • El quién (lo que nos
el formato rol-necesidad- permitirá ubicarnos
beneficio (o formato dentro de un contexto Formato: rol-necesidad-beneficio
Connextra). de uso),
No es obligatorio usarlo, pero • El qué (cuál es el Como [tipo de usuario] -> quién
es una buena guía para problema a resolver) y
empezar. quiero [necesidad] -> qué
• El para qué (el valor que para [beneficio esperado] -> para
Cada necesidad del usuario
se escribe en una tarjeta (de esperamos obtener una
vez construida la
qué
modo que se convierta en
una promesa de historia, y que será
conversación). fundamental a la hora
IMPORTANTE: son escritas de priorizar). Adaptado del blog: https://julibetancur.blog/
desde el punto de vista del
usuario.
Historias de Usuario | Card
“Como cliente del

“Como (rol de
banco,
usuario), necesito
quiero retirar dinero
(objetivo/el qué),
de mi cuenta
para conseguir
para hacer pagos en
(valor obtenido/ el
efectivo”
por qué)”.

Historias de Usuario | Conversación
Es la comunicación cara a “¿Existe algún máximo de dinero a retirar por

cara (¡no es un título en un transacción?
documento!).
Es el momento en que se R: Sí, $200 por transacción, y $1.000 por día.
juntan las personas que Si el usuario tiene menos dinero del que quiere
conocen la necesidad con retirar, ¿qué mensaje se le muestra?
quienes conocen cómo
solucionarla, para hablar en R: Podría ser “Señor usuario, los fondos son
torno a ello. insuficientes. Por favor intente con un valor
A partir de preguntas y menor o igual a xxx”.
respuestas, se busca el
entendimiento compartido ¿La interfaz de usuario podría mostrar la información
del problema que se quiere de esta manera?
resolver. <<mostrar prototipo>>
Aquí es recomendable usar
todos los recursos que R: Sí, y agregaría…
estén a nuestro alcance ¿Qué pasa si el cajero no tiene dinero suficiente?
para validar nuestro
entendimiento (hacer R: En ese caso…”.
prototipos, usar facilitación
gráfica, etc.).

Historias de Usuario | Confirmación
Criterios de Aceptación
La Confirmación es el acuerdo en
torno a lo que vamos a construir.
Es lo que nos permitirá saber si
terminamos de construirlo o no, y
si cumplimos con lo que se “Dado que tengo $400 en mi cuenta
esperaba.
En este punto podemos plantear cuando voy a retirar $100
escenarios y la manera como el
sistema se comportará en cada entonces mi saldo queda en $300 y
uno de ellos.
Lo anterior es lo que llamamos
el sistema me entrega $100.”.
“criterios de aceptación“.
Una historia de usuario puede
tener uno o muchos criterios de
aceptación.

Criterios de Aceptación
Las condiciones de satisfacción de los

objetivos suelen ponerse en forma de
criterios de aceptación, pruebas que se
realizarán para verificar si el sistema se
comporta de la manera esperada.
Para ello se puede utilizar la sintaxis de BDD
(Behaviour Driven Development) siguiendo el
siguiente formato: “Dado aaa, cuando se
produzca bbb, entonces ccc“, donde aaa es la
situación en la que se encuentra el sistema,
bbb es un evento que lo hará cambiar y ccc es
el resultado.
Esta técnica permite evitar la aparición de
errores por malos entendidos y evitar
retrabajar (siguiendo los principios Lean). Por
ello es recomendable no empezar a
desarrollar en una iteración sin antes haber
escrito los casos de prueba, especialmente
por que es más barato escribir texto y pensar
en cómo desambiguar los requisitos que
arreglar errores importantes debido a su mal
entendimiento.

Criterios de Aceptación | Ejemplos

Estimación
COMPLEJIDAD
PUNTOS DE HISTORIA Cuanto más compleja sea una historia más puntos historia se le
El método de los puntos historia aplicarán.
es una forma de realizar

ESFUERZO
estimaciones.
Una historia que implique un mayor esfuerzo asumirá más
Se utiliza para realizar las
puntos historia que una que suponga un esfuerzo menor.
valoraciones del esfuerzo
necesario para completar las INCERTIDUMBRE
historias de usuario.
Se refiere a la posibilidad de que se produzca una situación
Cuando un equipo se plantea inesperada, por falta de información previa. Una historia tendrá
cuánta dedicación requiere una más puntos historia cuanto mayor sea su incertidumbre.
historia de usuario determinada
no lo expresa en horas de 1.Definición de la referencia
trabajo. Lo hace en puntos
Escogemos una historia de usuario sencilla, una que todo el mundo
historia. Esto significa que se
aplica un valor relativo que
HISTORIA DE USUARIO ESTIMADA entiende, para emplearla como referencia. Esta podría ser la definición
de 1 punto de la historia en nuestro proyecto.
relaciona la complejidad de esa
historia de usuario con respecto 2.Estimación
de una que sirve de referencia. Establecida la referencia, cada vez que queremos estimar algo tan solo
Un punto de historia no es tenemos que compararlo con la historia de referencia. Si creemos que la
equivalente a una unidad de compejidad, el esfuerzo o la incertidumbre es el doble que la historia de
tiempo. referencia, entonces el valor será de 2 puntos de historia; si creemos que
las variables expuestas son la mitad, sería 0.5 puntos; etc..

Estimación | Planning Poker
Un mazo típico se encuentra compuesto por siguiente secuencia: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40,
100 y además, tarjetas: una con signo de interrogación (?), otra con signo de infinito (∞) y otra
con una taza de café.
• 0: Cuando se trate de una tarea que podremos resolver gracias a una funcionalidad
out of the box y ya existe desarrollada.
• ∞: Aplicamos el infinito cuando se considera que el esfuerzo para realizar la tarea
es superior a las opciones anteriores, en cuyo caso habría que descomponer la tarea
en varias.
• ?: El interrogante lo mostraremos cuando nuestra respuesta sea “No estoy seguro..”,
o “No sé de que se trata”.
• Café: Existen dos teorías posibles:
a) “Necesito un descanso”.
b) El coste de la equivales a tomar un café.
Se recomienda que:
• Si en 30 segundos no puedes determinar qué esfuerzo requiere esa tarea, no
deberías mostrar ninguna carta, puesto que careces de la experiencia/criterio para
poder evaluar.
• Puedes limitar el uso de las cartas a la secuenciade Fibonacci hasta el 21, y además,
las tarjetas: (?), (∞) y (café).
• Si estás estimando épicas puedes usar cartas con tallas de camisetas, y además, las
tarjetas: (?), (∞) y (café).

Estimación | Planning Poker
Cada participante tiene un mazo de cartas, de donde selecciona una carta con que estima el
elemento y la pone boca abajo sobre la mesa.
Cuando todos han hecho su selección, se voltean todas las cartas boca arriba.
Si las estimaciones son similares se busca consenso y se sigue con el siguiente elemento.
Si las estimaciones resultan en infinito, por sobrepasar el límite máximo establecido por la
baraja, el elemento debe dividirse en elementos de menor tamaño.
Si las estimaciones resultan muy dispares, el moderador con su criterio de gestión, y
basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes
de evaluar… puede optar por:
• Preguntar a las personas de las estimaciones extremas: ¿por qué crees que es necesario
tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo? Tras haber escuchado
todo el equipo las diferentes razones de unos y otros se reestima el elemento en una
segunda o tercera vuelta.
• Dejar a un lado la estimación de ese elemento y retomarlo al final o en otro momento.
• Pedir al cliente o Propietario del Producto que descomponga el elemento para estimar
cada uno de los elementos resultantes.

Priorización

Priorización Basada en Valor
• Conocimiento, incertidumbre y riesgo
• Entre menos conozcamos sobre un producto mayor incertidumbre
se tiene.
El marco de Scrum es
• A mayor incertidumbre mayor es el riesgo.
impulsado por el objetivo
• Los elementos inciertos y de alto riesgo, deben tener alta prioridad.
de ofrecer el máximo valor
en un período de tiempo • Posibilidad de liberación:
mínimo. • La habilidad para liberar incrementos de producto temprana y
frecuentemente debe influenciar las decisiones de priorización.
• Responsabilidad del PO .
• Es recomendado el • Dependencias:
involucramiento de todo el • Las dependencias entre algunos elementos del PB no se podrán
equipo. evitar.
• Permite retrasar las • Los elementos de los que se depende deben ser implementados
decisiones sobre los, primero.
elementos de menor
prioridad.
• Se considera el valor, FACTORES DE PRIORIZACIÓN
conocimiento,
incertidumbre, riesgo, El Product Owner (PO) debe traducir las necesidades de los Stakeholders para crear el Prioritized
posibilidad de liberación y Product Backlog. Se prioriza basado en la creación de valor, y se hace teniendo en cuenta que:
dependencias.
• Se pueden agrupar 1. Se liberen primero los elementos de mayor valor.
elementos del PB para 2. Se evalúen si el elemento es realmente requerido.
facilitarla priorización.
3. Se evalúen alternativas con menor tiempo/costo.

Grupos Afines
• En conjunto los involucrados y el
equipo Scrum.
• Colocar todas las historias en una
mesa.
• Una por una se levantan las historias,
se discute y define en que grupo o
tema debe clasificarse.
• Dinámicamente se pueden ir
cambiando de grupo o creando
nuevos grupos.
• El equipo establece una jerarquía de
grupos que define la prioridad de las
historias.

• El PO lee el elemento del PB.
PLANNING POKER • El equipo comenta el elemento y para clarificarlo realiza preguntas al

PO, quien las responde.
• Cada estimador selecciona una carta que representa su estimación,
Se mantienen en privado hasta que todos hayan estimado.
• Si todos seleccionaron las mismas, hay consenso.
• Si no, se discuten supuestos preguntando primero a quienes tienen
estimados altos y bajos.
• Todos estiman de nuevo y se selecciona el valor para la historia:
• Promedio
• Frecuencia
• Consenso
• Las estimaciones se van haciendo comparando el tamaño con la
estimación de elementos estimados anteriormente y de similar
esfuerzo.
• Se inicia estimando una historia de usuario que sirve de referencia
para las demás.

Urgencia: Se introducen valores de 1 a 5, VALOR DE NEGOCIO vs URGENCIA

donde 5 implica que esa US debe estar
lista ya o de lo contrario perderá sentido,
mientras que un valor 1 indica que no hay
apuro en tenerla lista. También se tienen
en cuenta para este valor de urgencia si la
funcionalidad tiene que estar desarrollada
por cuestiones contractuales, o porque de
ella dependen muchas otras US, por lo
debe implementarse antes.
Los Business Value siguen la misma escala

y se asignan valores de 1 a 5. Obtenidas
todas las asignaciones, se multiplican los
valores de urgencia por los de Business
Value (obteniendo números entre 1 y 25) y
se ubican en la gráfica de calor.

Task Board
Task Board: Es un tablero de tareas

que se divide en tres columnas con
la etiqueta "Tareas pendientes", "En
Progreso" y ”Finalizadas”.
Se utilizan notas adhesivas o fichas
para cada tarea en la que el equipo
está trabajando y se colocan en las
columnas que reflejan el estado
actual de cada una.

Daily Scrum | Burndown Chart
Mediante esta sencilla gráfica todo el Scrum Team puede visualizar si el Sprint se dirige hacia el
objetivo de entregar todos los puntos de historia planificados o si por el contrario hay algún
impedimento que lo retrasará o más cantidad de trabajo para recoger del Product Backlog.
Los Developers se encargan de actualizar las estimaciones de trabajo restante para cada una de las
historias o tareas que el equipo haya decidido acometer en el Sprint. Esa es la clave para su
obtención, y también es la clave para obtener una métrica realista (Ágil es honestidad y
transparencia) basada en la información del que realmente está produciendo.
La gráfica, típicamente muestra:
• El trabajo realizado en cada iteración.
• El trabajo restante.
• El trabajo realizado hasta el momento.
Pintarlo es fácil. Actualizarlo tras cada reunión diaria del equipo. Disciplina.
Ver detalle: https://medium.com/chris-nielsen/sprint-burndown-charts-gone-wrong-e06382acd276

Burndown Chart | Ejemplos
Nombre de Sprint Puntos en Sprint 01 Puntos en Sprint 02 Puntos en Sprint 03

Día 1 10 5 5
Día 2 5 7 10
ID Tamaño Día 3 6 8 9
HU1 5 Día 4 7 8 10
HU2 5 Día 5 5 8 10
HU3 2 Día 6 10 8 9
HU4 2 Día 7 10 6 10
HU5 5 Día 8 5 6 10
HU6 13 Día 9 20 5 7
HU7 8 Día 10 2 10 0
HU8 8
HU9 5
HU10 5
HU11 3
HU12 2
HU13 2
HU14 5
HU15 10
80

Velocidad del Equipo

Ejemplo:
• Se tiene un equipo de desarrollo compuesto por 4 miembros.
• La duración de los Sprints será de 15 jornadas (días) de trabajo efectivo por Sprint.
• Las historias del Product Backlog están estimadas de la siguiente forma:
• El objetivo del cálculo de la velocidad es
determinar la capacidad de trabajo del
Historia Tamaño
equipo para un Sprint y, para este fin, se
basa en la información recopilada de los
• Durante el primer Sprint, al no disponer
H1 8 de información de la capacidad de
Sprint anteriores.
• La velocidad está relacionada con el método H2 13 trabajo del equipo, se decidió intentar
de estimación del tamaño de las historias. abordar las 5 primeras historias.
H3 20
Se tratan los siguientes aspectos:
• Sin embargo, solo se han podido
• Calcular la velocidad real resultante del H4 3
trabajo realizado por el equipo en el primer completar las 4 primeras.
Sprint. H5 5
• Además, durante el Sprint surgieron
• Interpretar correctamente el significado del H6 8 algunas incidencias que afectaron al
valor obtenido.
H7 2 equipo y que no estaban previstas: uno
• Utilizar este cálculo de velocidad durante el
Planning del siguiente Sprint. de los miembros del equipo estuvo un
H8 2 día de baja y todos los miembros del
• Conseguir el compromiso del equipo con el
trabajo planificado para el segundo Sprint. H9 13 equipo tuvieron que asistir a un curso
H10 5
de un día de duración que no estaba
programado al inicio del Sprint.
H11 20
H12 5
Adaptado del blog: http://bemyscrummaster.blogspot.com

Ejemplo:
Historia Tamaño Al final de un Sprint, la velocidad se calcula de la siguiente forma:

H1 8 • Total de puntos completados: se suman los puntos de historia
correspondientes a las historias terminadas, es decir, de las 4 primeras
H2 13
(aunque el compromiso inicial fue de 5 historias, en realidad se completaron
H3 20 4 y para el cálculo de velocidad solo se tiene en cuenta el trabajo finalizado).
H4 3 Puntos Completados = 8 (H1) + 13 (H2) + 20 (H3) + 3 (H4) = 44
H5 5 • Total de jornadas reales: se suman las jornadas reales que cada miembro del
equipo ha realizado en el Sprint, descontando las ausencias o circunstancias
H6 8 especiales que han surgido.
H7 2 Jornadas ideales = 15 + 15 + 15 + 15 = 60
H8 2 Jornadas reales (descontando ausencias) = 13 + 14 + 14 + 14 = 55
H9 13 • Cálculo de Velocidad: la velocidad es la división de los puntos completados y

de las jornadas reales.
H10 5
Velocidad = 44 / 55 = 0,8
H11 20 El equipo ha trabajado en el primer Sprint con una velocidad del 80%.
H12 5
<Esta estimación posiblemente cambiará para el inicio del siguiente Sprint> Adaptado del blog: http://bemyscrummaster.blogspot.com

Ejemplo:
Historia Tamaño Una velocidad del 80% significa que el equipo

ha podido dedicar el 80% de su jornada
H1 8 laboral a acciones concretas de desarrollo que
H2 13 se habían programado para el Sprint y que un
20% ha sido invertido en otras acciones como:
H3 20
¿Cuál es la medida de llamadas telefónicas o correos electrónicos,
H4 3 reuniones de seguimiento (en Scrum, la
velocidad adecuada? reunión diaria), ir al baño, corregir un bug
H5 5
Depende del equipo, del grave que se ha descubierto.
H6 8
H7 2
proyecto, de la empresa, Al planificar los sucesivos Sprint con este
"colchón" del 20%, estamos aportando al
H8 2
etc. equipo una herramienta que le permite
asumir trabajo no previsto sin que esto tenga
H9 13
impacto en el trabajo comprometido lo cual
H10 5 favorece el clima de trabajo y la imagen hacia
H11 20 el cliente.
H12 5

Ejemplo:
Con un cálculo orientativo de la capacidad de trabajo (80%) del equipo y siguiendo el ejemplo
Historia Tamaño anterior, para determinar la cantidad de trabajo que el equipo podría asumir en el siguiente Sprint
debemos de tener en cuenta lo siguiente:
H1 8
• Durante el próximo Sprint, 2 miembros del equipo estarán de vacaciones durante una semana cada uno (5 días).
H2 13 • La historia 5 estaba estimada en 5 puntos, pero como parte de esta historia fue abordada durante el primer Sprint
(aunque no se completó), se realiza una re-estimación y se determina que su nuevo tamaño es de 2 puntos.
H3 20
En el escenario descrito para el Sprint 2, se procede a determinar la capacidad de trabajo del equipo y
H4 3 a extrapolar este valor a las historias que podrán ser abordadas:
H5 2 Jornadas de trabajo disponibles: determinamos las jornadas de trabajo para el nuevo Sprint como la
suma de las jornadas que cada miembro del equipo podrá dedicar con la información de la que
H6 8
disponemos en este momento.
H7 2 • Jornadas previstas = 10+10+15+15 = 50 (descontando ausencias)
H8 2 Aplicar la velocidad: ajuste de las jornadas disponibles.
H9 13 • Puntos abordables = 80% de 50 = 40
Selección de historias potencialmente abordables: determinamos que historias podrán ser
H10 5
abordadas durante el Sprint en base a su prioridad, estimación y jornadas efectivas calculadas.
H11 20 • Suma puntos de historias H5 a H10 = 2(*)+8+2+2+13+5 = 32
H12 5

Llegados a este punto tenemos un "problema" que solventar:

Ejemplo: • Por una parte, si abordamos solo las historias de la H5 a la H10, al equipo le sobrarán 8
jornadas de trabajo real, lo cual es excesivo (semana y media de trabajo de un miembro
Historia Tamaño del equipo o dos días no planificados para todo el equipo).
H1 8 • Sin embargo, sin añadimos la siguiente historia en prioridad, la H11, la suma llega a 52, lo
H2 13 cual son 12 puntos por encima de las jornadas efectivas calculadas.
H3 20
La solución depende del Product Owner, pero es el Scrum Master y el equipo quienes tienen
que ayudarle a identificar las soluciones disponibles y a escoger la más razonable. Estas son
H4 3 algunas opciones:
H5 2 • No respetar la prioridad, saltarse la historia H11 (20 puntos) y abordar en este Sprint
H6 8 la historia H12 (5 puntos), lo que suponen 37 puntos y es un valor razonablemente
cercano a los 40 efectivos calculados.
H7 2
• Dividir la historia H11 en varias historias más pequeñas, de forma que algunas de
H8 2
estas puedan ser abordada en el Sprint.
H9 13 • Sustituir la historia H9 (13 puntos) por la H11 (20 puntos), lo que deja el total de
H10 5 puntos planificados en 39.
H11 20 • Etc.
H12 5

Refinamiento

Product Backlog Refinamiento
Suelen adquirir este grado de transparencia tras las

actividades de refinamiento.
El refinamiento del Product Backlog es el acto de dividir y
definir aún más los elementos del Product Backlog en
elementos más pequeños y precisos.
Esta es una actividad continua para agregar detalles, como
una descripción, orden y tamaño.
Los atributos suelen variar según el ámbito del trabajo.

Product Backlog Refinamiento
• "El refinamiento del PB es el

acto de añadir detalle,
estimaciones y ordenamiento
a los elementos del PB.
• Se trata de un progreso
Continuo, en el cual el PO y el
Equipo de Desarrollo
colaboran acerca de los
detalles de los elementos del
PB.
• Durante el refinamiento del
PB, se examinan y revisan sus
elementos. Sin embargo,
éstos pueden ser actualizados
en cualquier momento por el
PO, o a criterio suyo.”

Product Backlog Groomming
• Descubrimiento de nuevos
elementos, cambios, eliminación
de existentes.
• Priorización de elementos.
• Descomposición de elementos
que se implementaran en el
siguiente Sprints.
• Estimación de tamaño de
elementos nuevos o corrección
de tamaño de elementos
existentes.
• Se dedica 10% del tiempo del
Sprint.
• Comunicación cara a cara.

Product Backlog Groomming
¿Cuándo hacerlo?
• De a poco, después del Daily
Scrum.
• Sesiones semanales.
• Taller largo al final del Sprint.
• Durante la Revisión del Sprint se

hace Refinamiento.

Shu Ha Ri
Maestría de una técnica MAESTRO

Ri
Crea tus propias reglas.
La forma en que los humanos aprendemos las (Mentoring) (Maestría)
cosas; es un proceso progresivo que va de
menos a más, poco a poco. Shu Ha Ri es una
forma de explicar esto en las artes marciales
japonesas (Aikido).
• Shu (Obedecer): En este estado nos han
enseñado los pasos de una técnica y los
seguimos a rajatabla y sin cuestionarlos en PRACTICANTE Ha Rompe y adapta las reglas
ningún momento. Se trata de ejecutarlo a diferentes contextos.
(Coaching)
correctamente, más que de entenderlo. (Adaptación)
• Ha (Ruptura): En este estado la persona
domina la técnica y la comprende.
Comienza a innovar y a realizar cambios SCRUNDAMENTALISMO
con el objetivo de mejorarlo. Rompe las Temor a hacer mal Scrum
normas establecidas. Síntoma: Permanecer en
• Ri (Trascender): En este estado la persona
ESTUDIANTE Shu Aprende, entiende y
Shu.
ya no piensa en la técnica. Piensa en el
objetivo y la técnica fluye sola. En estado Ri
(Training) sigue las reglas.
la técnica se realiza inconscientemente. Se (Aprendizaje)
ha transcendido la técnica.

Contacto…
• Web
Page: w
ww.act
• Face itudyta
book: lento.c
www.F om
a ceboo
• Twit k .co m /
ter: @ a c t it u d
a c titu d ytalen
ytalent to
• M ai o | @
l: ealva EdgarA
rez@a lvarez_
c titu d y ec
• L in k talento
e d in : h .com
ttp://e
c.linke
din.com
/in/eda
lv

Créditos
Material Adaptado del Manual de Trainers:
SCRUM PRODUCT OWNER PROFESSIONAL CERTIFICATE SPOPC®

Tópicos de Refuerzo

Principios para Agilizar
Los principios
para priorizar y
lanzar Agile en
una organización.

Preguntas Poderosas
¿Con qué frecuencia sus equipos integran

completamente sus productos?
¿Cómo responde si hay una crisis o un problema

que hace que una fecha límite o un hito planificado
ya no sea posible de lograr?
Hábleme de tu mejor Scrum Master o Product

Owner.

Product Owner
Con respecto del Scrum Team Con respecto de los Eventos
1. Debe asistir obligatoriamente a la Sprint Retrospective, ya que
1. El Product Owner es un miembro más del Scrum Team.
esta es la oportunidad perfecta para inspeccionar y crear un plan
Quizás la más clara y evidente, pero mejor no dar nada por de mejoras sobre el Scrum Team.
supuesto.
2. Debe convocar a los stakeholders a la Sprint Review.
2. No es lo mismo que un Project Manager tradicional.
3. Debe facilitar la Sprint Review y en ella debe (puede contar con la
3. El Product Owner debe ser una única persona, bajo ningún ayuda del resto del Scrum Team):
caso múltiples personas compartirán este rol o el mismo será • Revisar el estado actual del Product Backlog.
desempeñado por un comité. Esto nos ayuda no solo a
• Inspeccionar el incremento de producto.
simplificar y eficientar las comunicaciones, sino que, a la hora
de priorizar el backlog, no se generarán conflictos. • Asegurar que los items entregados cumplen con el
Definition of Done (DoD).
4. No es el responsable del estado de progreso del desarrollo
durante el Sprint, de esto es responsable el Development • Inspeccionar junto con los stakeholders los cambios del
mercado y el potencial uso del producto.
Team.
• Actualizar el Product Backlog.
5. Debe trabajar junto con el Development Team en elaborar un
Sprint Goal. Esto se lleva a cabo en la Sprint Planning y es • Podría también realizar proyecciones sobre fechas
probable que el Product Owner venga con un objetivo de probables de release en base a la velocidad del
Development Team.
negocio definido pero que deberá ajustarse junto con el
Development Team a lo largo del evento. 4. No puede modificar la fecha de inicio o fin de un Sprint. La
duración del Sprint es algo que define el Development Team y
6. Si trabaja junto con múltiples equipos para un mismo debe ser fija en el tiempo. El Product Owner no podrá influir en
producto, tan solo tendrá un Product Backlog, en ningún caso este aspecto.
uno por equipo. Esto ayudará a tener una visión única y 5. Puede cancelar un Sprint siempre y cuando el Sprint Goal haya
global de todo el producto, pudiendo además anticipar quedado obsoleto. Esta situación es extremadamente anormal,
dependencias. pero podría darse el caso.

Product Owner
Con respecto de los Artefactos
1. No puede modificar el Sprint Backlog, ya que esto es un artefacto que pertenece al Development Team.
2. Es el dueño del Product Backlog y, aunque puede delegar las tareas referentes al mismo, debe ser quien finalmente se encargue de
responder/dar explicaciones al respecto de las acciones realizadas sobre el mismo. Recordemos que la responsabilidad puede ser
compartida mientras que el hecho de dar explicaciones sobre las acciones realizadas reside en este caso en el Product Owner.
3. Tiene que ser quien monitorice y comparta el progreso del Product Backlog.
4. Se encarga de crear, mantener y ordenar el Product Backlog. Puede pedir ayuda al resto del Scrum Team. Por ejemplo, puede pedir al
Development Team ayuda para escribir las Historias y el Scrum Master puede echarle una mano en cuanto a mejores técnicas para
mantenerlo y ordenarlo.
5. Podrá actualizar el Product Backlog cuando considere. Recordemos que el Product Backlog es un artefacto que está vivo por lo tanto
puede cambiar continuamente (tanto como el Product Owner considere).
6. Debe encargarse de que el Product Backlog maximice el valor del producto y represente las necesidades de los stakeholders. Para ello
debe fomentar el feedback no solo de los stakeholders, sino del mercado.
7. Puede apoyarse en el Development Team para refinar el Product Backlog. Esta labor es muy importante, pues nos ayuda a anticipar
situaciones, a detallar más aquellos PBI que puedan ser abordadas en la siguiente Sprint Planning, identificar dependencias…
8. Debe colaborar con los stakeholders, los grupos de usuarios y los responsables de producto para conseguir que se involucren y extraer
ideas que incorporar al Product Backlog.
9. Puede añadir una catalogación por “puntos de valor” a los PBI y ordenarlo en base al valor que aporte cada ítem al producto. Además,
debe tener en cuenta las dependencias entre otros productos, ítems del backlog, áreas… para la ordenación del Product Backlog.
10. Puede delegar la escritura de User Stories en el Development Team, pero debe ser él/ella quien dé las explicaciones pertinentes sobre
las acciones realizadas en este ámbito y quien las valide.
11. Será el encargado de aclarar los requerimientos del Product Backlog si el Development Team lo necesitase.
12. No es el responsable de realizar las estimaciones de esfuerzo de los ítems del Product Backlog, pero sí puede aportar un mayor detalle
sobre la definición de los mismos, ayudando al Development Team a afinar la estimación.

Product Owner
Con respecto del Producto

1. Es el responsable de todo el ciclo de vida del producto. De ámbito general
2. Es el encargado de vigilar el TCO (Total Cost of Ownership) y 1. Debe tener capacidad de decisión, de influir en la
esto conlleva contemplar todas las inversiones (concepción, organización y disponer de tiempo. En muchas
desarrollo, operación y mantenimiento) a realizar en el ocasiones podemos encontrarnos con que los Product
producto Owner ocupan cargos altos en las organizaciones y esto
3. Debiera intentar recibir feedback del mercado mediante la puede tener una doble lectura: la positiva que es que
liberación frecuente de incrementos de producto. Algo que tendrá capacidad para influir en la organización y la
repetimos constantemente es “inspeccionar y adaptar” y esto negativa que en consecuencia tendrá una agenda
es algo que se puede aplicar no solo al método de trabajo, sino complicada y poco tiempo.
al producto. 2. El Product Owner no elige el quién ni el cómo. Es el
4. Debe ser quien más sepa sobre el progreso hacia el objetivo de Development Team quien realiza las tareas y elige cómo
negocio o el lanzamiento (de un incremento) de producto. hacerlo, mientras que el Product Owner indica qué
(hacer), reflejándolo en el Product Backlog con ítems.
5. Decidirá cuando es liberado un incremento de producto a
producción. El Equipo de Desarrollo debe de encargarse de que
ese incremento cumpla las necesidades para poder ser liberado
a producción.

Herramientas
1.monday.com 1.ClickUp
2.Jira 2.MeisterTask
3.ProjectManager.com 3.Scrumwise
4.Zoho Sprints 4.Axosoft
5.Targetprocess 5.Vivify Scrum

Herramientas
Retrospectiva On-Line Planning Poker On-Line
1.https://funretro.io 1.https://scrumpoker.online
2.https://www.goreflect.com/ 2.https://www.planningpoker.com
3.https://reetro.io/ 3.https://tools.wmflabs.org/hatjitsu/
4.https://www.retrium.com/ 4.https://www.pointingpoker.com
5.https://www.scatterspoke.com/ 5.https://www.marcnuri.com/es/scrum
-poker-online/
6.https://ideaboardz.com/
7.https://www.teamretro.com/ 6.https://www.planitpoker.com
8.https://www.senseitool.com/ 7.http://votingpoker.com/
9.https://www.parabol.co/

AyT SPOPC

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

AyT SPOPC

Cargado por

Copyright:

Formatos disponibles

Scrum Product Owner

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

FIJOS CONTEXTO Simple Complejo

Parciales, regulares y de valor

ESTIMADOS COSTOS TIEMPO ALCANCE VELOCIDAD No es prioritaria Se prioriza al alcance

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

En 1993, Jeff Sutherland y su equipo en

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

VALORES Scrum Master Daily Meeting Sprint Backlog

PRINCIPIOS Development Team Sprint Retrospective Incremento

Product Backlog Refinement

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

PILARES Product Owner Sprint Product Backlog

VALORES Scrum Master Daily Meeting Sprint Backlog

PRINCIPIOS Developers Sprint Retrospective Incremento

Product Backlog Refinement

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

La inspección es “revisar” Adaptación, sucede La Transparencia permite

Debido a que los equipos Scrum trabajan como verdaderos

CO FRANQUEZA Nos permite una discusión abierta de los problemas que

Ya que el grupo trabaja en forma conjunta

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

1. Control del proceso empírico: Este 2. Auto-organización: Este principio se enfoca en

6. Desarrollo iterativo: Este principio define

5. Time-boxing: Este principio describe cómo el

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Existen muchas formaciones con las

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

• “El Dueño de Producto (Product Owner) es el

Equipo Desarrollo (TD)

El PO entrega el valor al cliente mediante TD y PO demuestran el

TD construye los Incrementos

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Product Manager Product Owner Project Manager Scrum Master

Asegurar que el Proyecto cumpla los objetivos

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

El Dueño de Producto es el responsable de maximizar el Decidir que construir… ¡Y que no!

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

0 1 7 • Responsable de que será desarrollado y en que orden.

2 • Empoderado para ser el punto central del Producto.

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Comunicación y negociaciones con diferentes involucrados:

Un Sprint puede ser

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Un “release plan” o plan de proyecto es un

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

Productos viables mínimamente, perfectos para

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152

“Un producto con el MÍNIMO

“Es la versión de un nuevo producto que permite a un

Web: www.actitudytalento.com Twitter: @actitudytalento e-Mail: info@actitudytalento.com WhatsApp: +593995628152