Introduccin a tcnicas

giles y Scrum
Curso taller: Da 2
Product Owner

Analista de negocios y parte

probador.
Descripcin
El product owner es el punto central facultado de
liderazgo del producto.

El product owner tiene que ver por lo menos en dos

direcciones al mismo tiempo:
Negocio
Equipo

El product owner tambin debe asegurarse de que

se especifiquen los criterios para la aceptacin de
las caractersticas y de las pruebas que verifican
que esos criterios se cumplan
Descripcin y
Responsabilidades
Gestionar la economa
Participar en la planificacin
Pulir el product backlog(Grooming)
Definir los criterios de aceptacin y

compruebe que se cumplen

Colaborar con el equipo de desarrollo
Colaborar con los grupos de inters
Caracteristicas y habilidades
Habilidades de dominio
Es un visionario
Sabe que no todo se puede anticipar
Tiene experiencia en negocios y administracin
de dominio
 Habilidades con la gente
Tiene una buena relacin con las partes
interesadas
Es negociador / un generador de consenso
Es un gran motivador
Es un buen comunicador
 Toma de decisiones
Est facultado para tomar decisiones
Est dispuesto a tomar decisiones difciles
Toma una visin econmica para equilibrar los
problemas tcnico / econmicos
Es decisivo
 Rendicin de cuentas
Acepta la responsabilidad por el producto
Es comprometido y disponible
Acta como un miembro del equipo Scrum
Entregas (Release)
Reuniones de Release Planning
Coloreando el Backlog
Midiendo PBIs y estimando el Product Backlog
Velocidad
Asignando Sprints
Seguimiento del progreso El release Burndown
Planning Poker
Tipos de Release
Lanzamiento despues de multiples sprints
Lanzamiento despues de cada sprint
Lanzamiento despus de cada

caracterstica(continuous deployment)
Release Planning
La planificacinde lanzamientono es un eventode una sola vez.

La planificacin Lanzamiento inicialsigue lgicamentela

conceptualizacin/planificacin a nivel de producto.

El propsito de la planeacin del producto es de imaginar lo que

debe ser el producto, el objetivo de la planificacin de liberacin
es para determinar el siguiente paso lgico hacia el logro de la
meta de producto

Pueden ser revisados como parte de cada revisin de sprint o en

el curso normal de la preparacin y conduccin de cada sprint
posterior.
Cuando ocurre el Release Planning
Participantes

Involucra la colaboracin de los

stakeholders y el esquipo Scrum completo

La participacin exacta de cada persona

con el tiempo puede variar.
Reuniones de Release Planning
Las entradas del release planning incluyen
salidas de planeacin de producto (product
planning):
Visin del producto
Product backlog de alto nivel
Plan de trabajo del producto
La velocidad del equipo o equipos que trabajar
sobre la liberacin.
Limitacines de la
Liberacin
Una actividad que se repite en la
planificacin de la liberacin es confirmar
las limitaciones de la liberacin:
alcance
fecha
presupuesto
Revisarlos para ver si es necesario realizar
cualquier cambio, dado el avance obtenido.
Caractersticas mnimas
liberables
Cada liberacin debe tener un conjunto bien
definido de caractersticas mnimas
liberables (MFR).
Las MFR iniciales de una liberacin podran

definirse durante conceptualizacin.

Actividad de Planeacin de Liberacin
Backlog Grooming
Product Backlog Grooming: Creacin,
estimacin y priorizacin ms detallada de
los elementos del product backlog.
Ocurre en mltiples puntos en el tiempo:
Despus de la planificacin de productos, pero
antes de la planificacin de liberacin inicial
Como parte de la actividad de planificacin
inicial de liberacin
Durante cada sprint conforme sea necesario
Velocidad
La velocidad es la cantidad de trabajo realizado cada
sprint

Se mide sumando los tamaos de los PBIs que se

completan al final del sprint.

La velocidad se utiliza para dos propsitos importantes:

Planificacin a nivel de Liberacin
Planificacin a nivel de Sprint

A efectos de planificacin, la velocidad es ms til cuando

se expresa como un rango, por ejemplo, "El equipo suele
ser capaz de completar entre 25 y 30 puntos cada sprint."
Calculando la velocidad
Asignando Sprints
En cada sprint el equipo trabaja en un conjunto de
elementos de trabajo pendiente del producto

El equipo y el product owner no deciden en que

tem especfico se va a trabajar hasta la planeacin
del sprint.

Usando la velocidad del equipo, podemos

aproximar un conjunto de tems del product
backlog para cada sprint agrupndolos de forma tal
que la suma de tamaos sea lo mas cercana a la
velocidad promedio del equipo.
Mapeo de PBI a Sprints
Seguimiento del progreso El
release Burndown
Un grafico de burndown para una liberacin con
alcance fijo muestra la cantidad total de trabajo
sin finalizar que queda por hacer despus de
cada sprint para alcanzar nuestro objetivo.

En este tipo de grfico, los nmeros de eje

vertical son en las mismas unidades que
utilizamos para el tamao de nuestros
elementos de product backlog(normalmente
puntos de la historia o los das ideales). El eje
horizontal representa los sprints
Planning Poker.
Es una tcnica para el
dimensionamiento PBIs
Descripcin
Es una tcnica para el dimensionamiento
PBIs que fue descrita por primera vez por
James Grenning (Grenning 2002) y luego
popularizado por Mike Cohn (Cohn 2006).

El equipo de desarrollo estima historias de

forma individual (utilizando un mazo de
cartas con nmeros como uno, tres y cinco
puntos sobre ellos) y luego compara los
resultados colectivamente
Conceptos del Planning
Poker
Basada en el consenso
Opinin de los expertos
Intenso debate
Tamao relativo
Agrupacin precisa
Apalancamiento al estimar historia
Cmo Jugar?
El equipo completo de Scrum participa al realizar Planning
Poker. Durante la sesin, el product owner presenta, describe y
aclara los PBIs.

El ScrumMaster ayuda al equipo para aplicar mejor el Planning

Poker. El ScrumMaster tambin est constantemente buscando
personas que, por su lenguaje corporal o por su silencio,
parecen estar en desacuerdo y ayuda a hacerlos participar.

Y el equipo de desarrollo est generando colaborativamente

las estimaciones.

Cada miembro del equipo de desarrollo est dotado de una

serie de tarjetas de Planificacin de Poker
Carta Interpretacin
0 Indica que el tem ya se ha completado
o que es tan pequeo que no tiene
sentido siquiera darle un nmero de
tamao.
1/2 Se utiliza para elementos de tamao
diminuto
1, 2, 3 Se utiliza para elementos de tamao
pequeos
5, 8, 13 Se utiliza para elementos medianos.
Para muchos equipos, un elemento de
tipo 13 sera la ms grande que se
programar en un sprint.
20, 40 Se utiliza para los elementos de
tamao grande (por ejemplo,
caractersticas o de nivel de tema).
100 Una gran caracterstica o una historia
pica
(infinito) Se utiliza para indicar que el elemento
es tan grande que ni siquiera tiene
sentido poner un nmero en l.
? Indica que un miembro del equipo no
entiende el elemento y est pidiendo
al product owner aclaraciones
adicionales.
Las reglas de Planning Poker
1. El product owner selecciona un PBI que ser estimado y lee el elemento para
el equipo.
2. Los miembros del equipo de desarrollo discuten el elemento y hacer
preguntas aclaratorias para el dueo del producto, que responde a las
preguntas.
3. Cada estimador selecciona de forma privada una tarjeta que representa su
estimacin.
4. Una vez que cada estimador ha hecho una seleccin privada, todas las
estimaciones privadas se exponen simultneamente a todos los estimadores.
5. Si todo el mundo selecciona a la misma tarjeta, tenemos consenso, y ese
nmero se convierte en el consenso estimacin de PBI.
6. Si las estimaciones no son las mismas, los miembros del equipo participan en
un debate especfico para exponer los supuestos y malentendidos.
Normalmente empezamos preguntando a los estimadores ms altos y ms
bajos para que expliquen o justifiquen sus estimaciones.
7. Despus de la discusin, volvemos al paso 3 y se repite hasta que se llega a
un consenso.