Bienvenidos

Scrum Master
Andres
Rodriguez
Rubio

Coach Agile - Agile Team Facilitator

Certified Training
ACUERDOS
TRABAJO

INVOLÚCRATE PARKING RESPETAR MICRÓFONO ESTAR

EN LA SESIÓN LOT EL TIEMPO SILENCIO PRESENTE
CHECK - IN
¿POR QUÉ AGILIDAD?
QUÉ ES
AGILIDAD?

Si le preguntas a 10 agilistas qué es la

agilidad, seguramente obtengas 11
respuestas

”Agilidad es la capacidad organizacional

de responder y adaptarse a los cambios
para obtener ganancias en un entorno
empresarial turbulento”.
Jim Highsmith
 Ágil es un “mindset”, es un camino de continua
¿QUE ES AGILE? exploración, adaptación, aprendizaje y mejora,
que a partir del desarrollo evolutivo e
incremental busca obtener el producto más
adecuado de la mejor manera posible, basado
en la colaboración, la confianza y la motivación
de las personas involucradas.

Adaptado de una definición de

Mauro Strione
ESTABLECIENDO EL
MINDSET AGILE
ESTABLECIENDO EL
MINDSET AGILE

4 : 12
VALORES PRINCIPIO S
VALORES del
Manifiesto Ágil
Personas e interacciones
sobre procesos y herramientas
VALORES del
Manifiesto Ágil
Producto funcionando
sobre documentación
exhaustiva
VALORES del
Manifiesto Ágil
Colaboración con el cliente
sobre negociación contractual
VALORES del
Manifiesto Ágil
Adaptación al cambio
sobre seguir un plan
PRINCIPIOS DE AGILIDAD
PRINCIPIOS del
Manifiesto ágil
Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de un
producto con valor.
PRINCIPIOS del
Manifiesto ágil
Aceptamos que los requisitos cambien, incluso
en etapas tardías del desarrollo. Los procesos
Ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.
PRINCIPIOS del
Manifiesto ágil
Entregamos un producto funcional
frecuentemente, entre dos semanas y dos
meses, con preferencia al periodo de tiempo
más corto posible.
PRINCIPIOS del
Manifiesto ágil
Los responsables de negocio y los
desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto.
PRINCIPIOS del
Manifiesto ágil
Los proyectos se desarrollan en torno a
individuos motivados. Hay que darles el
entorno y el apoyo que necesitan y confiarles
la ejecución del trabajo.
PRINCIPIOS del
Manifiesto ágil
El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.
PRINCIPIOS del
Manifiesto ágil
El producto funcionando es la medida
principal de progreso
PRINCIPIOS del
Manifiesto ágil
Los procesos Ágiles promueven el desarrollo
sostenible.
Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo
constante de forma indefinida.
PRINCIPIOS del
Manifiesto ágil
La atención continua a la excelencia técnica y
al buen diseño mejora la Agilidad.
PRINCIPIOS del
Manifiesto ágil
La simplicidad o el arte de maximizar la
cantidad de trabajo no realizado, es esencial.
PRINCIPIOS del
Manifiesto ágil
Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.
PRINCIPIOS del
Manifiesto ágil
A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación
ajustar y perfeccionar su comportamiento en
consecuencia.
¿QUE ES MINDSET AGILE
AGILE?
ESTABLECIENDO EL
MINDSET AGILE
 Battleship - Batalla Naval

http://www.leansight.com/contenidos/Batalla_Naval-
Battleship/
Enfoque PREDICTIVO Vs
Enfoque EXPLORATORIO

Fijo

Alcance Costo Tiempo

Costo Tiempo Variable Alcance

DESARROLLO INCREMENTAL
MVP
Modelo Tradicional

M od elo Ágil
 ACTIVIDAD
WRITING NAMES

MINDSET

https://trello.com/invite/b/Z5ONdmo8/84d15362d39173937125fa276e6c0ca6/foco
PRÁCTICAS Y TÉCNICAS
AGILES

Design Thinking
Kaizen
Lean Toyota Kata
Inception Kanban Scrum

Product
Scrumban
Discovery
MITOS SOBRE
AGILIDAD

BALA DE ANTI SOLO PARA INDISCIPLINA

PLATA PLANIFICACIÓN STARTUPS

MÁS FÁCIL BENEFICIOS DESARROLLO RÁPIDO

INMEDIATOS DE
SOFTWARE
MÉTODOS ÁGILES
USADOS

Scrum continúa siendo

el marco de trabajo ágil
más común utilizado
por las organizaciones
encuestadas
QUE ES
SCRUM?

Es un framework ágil para gestionar proyectos complejos.

Fue formalizado originalmente para proyectos de desarrollo de
software, pero funciona bien para cualquier ámbito de trabajo
complejo e innovador. Las posibilidades son infinitas.
El marco de Scrum es engañosamente simple.
VALORES
DE SCRUM Cuando los valores del coraje, focalización,
compromiso, respeto y apertura, son
incorporados y vividos por el equipo Scrum,
los pilares Scrum como son la transparencia,
inspección y adaptación se materializan y
fomentan la confianza en todo el mundo.
CICLO SCRUM
AREAS FUNDAMENTALES
DE SCRUM

➢ 6 Principios
➢ 5 Aspectos
➢ 19 Procesos
PRINCIPIOS DE
SCRUM
1. CONTROL DEL PROCESO
EMPÍRICO (PILARES)
Este principio enfatiza la filosofía central de Scrum, con base a las
tres ideas principales de:
Todos sabemos lo
que está pasando

Comprobar la
conformidad Está bien
del trabajo cambiar la
dirección
táctica
TRANSPARENCIA
Artefactos
Cronograma de
Declaración de Backlog priorizado
planificación de
visión del proyecto del producto
lanzamiento

Eventos Radiadores de
información

Revisión del Sprint BurnDown Chart

TRANSPARENCIA

Daily Scrum Scrumboard

INSPECCIÓN

Scrumboard

• Creación del Backlog

priorizado Demostrar y validar
INSPECCIÓN
• Realizar planificación el Sprint
del lanzamiento
ADAPTACIÓN
Daily Scrum

Identificación
Retrospectiva
constante de
del proyecto
riesgos

ADAPTACIÓN

Retrospectiva Solicitudes de
del Sprint cambio

Scrum
Guidance
Body
2. AUTO-ORGANIZACIÓN
Aprovechar el
conocimiento
de un equipo
Multifuncional

Comprender la
Buscar trabajo
visión del
Proactivamente
proyecto

Las metas de
un Equipo
Auto -
Entregar Organizado Hacer el trabajo
resultados
por si mismos
tangibles

Continuamente
Estar abiertos a
actualizar
nuevos
conocimientos y
aprendizajes
habilidades
3 . COLABORACIÓN

Este principio se centra en las tres dimensiones básicas

relacionadas con el trabajo colaborativo :

- Conocimiento
- Articulación
- Apropiación.

También fomenta la gestión de proyectos como un proceso

de creación de valor compartido con equipos que
traba ja n e intera c túa n co nju ntam ente pa ra ofrecer el m ayo r
valor.
3. COLABORACIÓN
Colaboración

Procesos de Scrum

✓ Minimizar solicitudes
de cambio
✓ Mitigar riesgos
✓ Aumentar la eficacia
✓ Practicar la mejora
continua
4. PRIORIZACIÓN BASADA
EN VALOR
Este p r i n c i p i o p o n e d e relieve e l enfoque de Scrum p a r a
o f r e c e r e l máximo va lo r d e negocio, desde e l principio
d e l p r o y e c t o h a s t a su c o n c l u s i ó n .
CONTROL DEL TIEMPO
TIME-BOX
Este p r i n c i p i o describe c ó m o e l tiempo se c o n s i d e r a u n a restricción
l i m i t a n t e en Scrum, y c ó m o este se u t i l i z a para a y u d a r a manejar
efica zm ente l a p l a n i f i c a c i ó n y e j e c u c i ó n d e l proyecto. Los elementos
d e l time boxing en Scrum incluyen:

- Sprints
- Daily Scrum
- P l a n i f i c a c i ó n d e l sprint
- Revisión d e l sprint.
- Retrospectiva d e l sprint.
DESARROLLO
ITERATIVO
Este pri nci pio define el desarrollo iterativo y hace énfasis en cómo
gestionar mejor los cambios y crear productos que satisfagan
las necesidades del cliente. También delinea las
responsabilidades del Product Owner y las de la organización
relacionadas con el desarrollo iterativo.
ASPECTOS
Organización

Justificación
Riesgo
del negocio

Aspectos
Scrum

Cambio Calidad
1. ORGANIZACIÓN
ROLES NO
CENTRALES
Stakeholders es un término colectivo que incluye a clientes, usuarios y patrocinadores,
que con frecuencia interactúan con el equipo principal de Scrum, e influyen en el proyecto
a lo largo de su desarrollo .

El Scrum Guidance Body (SGB) es un rol opcional, que generalmente

consiste en un conjunto de documentos y/o un grupo de expertos que normalmente
están involucrados en la definición de los objetivos relacionados con la calidad, las
regulaciones gubernamentales, la seguridad y otros parámetros claves de la
organización . El SGB guía el trabajo llevado a cabo por el Product Owner, el Scrum
Master y los developers.

Los proveedores, incluyendo a individuos u organizaciones externas, ofrecen

productos y/o servicios que no están dentro de las competencias centrales de la
organización del proyecto.
SCRUM PARA PORTAFOLIOS,
PROGRAMAS Y PROYECTOS
2. JUSTIFICACIÓN
DEL NEGOCIO
La j u s t i f i c a c i ó n d e l n e g o c i o demuestra la s ra zo n e s para emprender un proyecto.
Responde a l a pregunta: “¿Por qué es necesario este proyecto?” La j u s t i f i c a c i ó n d e l
n e g o c i o es l o que impulsa to d a s la s d ecisio nes r e l a c i o n a d a s a u n proyecto. P o r
l o tanto, es importante evaluar l a v i a b i l i d a d d e u n proyecto, n o s o l o antes d e
comprometerse a gastos o inversiones considerables en la s etapas iniciales, sino
también a l o l a r g o d e l c i c l o d e v i d a d e l proyecto.

Un proyecto debe cancelarse si se c o n s i d e r a que n o es viable; l a d e c i s i ó n debe ser

esca la d a a lo s stakeholders pertinentes y a l a alta gerencia.
Entrega
de valor
3. CALIDAD

E n S c r u m , l a c a l i d a d s e d e fi n e c o m o l a c a p a c i d a d
con la que cuenta un producto terminado o los
entregables para cumplir con los criterios de
aceptación y lograr el valor del negocio que
espera el cliente.
3. CALIDAD

En Scrum, el alcance y la calidad del proyecto se capturan en

el Backlog Priorizado del Producto, mientras que el alcance de
cada sprint se determina por l a r e fi n a c i ó n de los amplios
elementos del Producto (PBIs, por sus siglas en inglés) en un conjunto
de pequeñas, pero detalladas historias de usuario que pueden
ser planeadas, desarrolladas y verificadas en un sprint.
3. CALIDAD
4. CAMBIO

Cada proyecto, independientemente de su método o marco utilizado, se

expone a cambios. Es indispensable que los miembros del equipo del
proyecto entiendan que los procesos de desarrollo de Scrum están
diseñados para aceptar el cambio.

Un principio fundamental de Scrum es su reconocimiento de :

a) los stakeholders cambian de opinión acerca de lo que quieren y
necesitan durante el curso del proyecto

b) Es muy difícil, si no imposible, que los stakeholders definan todos los

requisitos durante el inicio del proyecto.
COMO PRIORIZAR
EL CAMBIO
QUIEN PUEDE SOLICITAR
LOS CAMBIOS?
Los stakeholders
pueden presentar solicitudes de cambio en cualquier momento durante todo el
proyecto.

Equipo scrum
pueden motivar y sugerir cambios o mejoras en el producto, servicio, o cualquier
otro aspecto del proyecto.

La alta gerencia
Esto puede deberse a cambios estratégicos en la dirección de la empresa, a un
entorno competitivo, a problemas financieros, etc.
INTEGRACIÓN DEL
CAMBIO
5. RIESGOS

El riesgo se define como un evento incierto o serie eventos que

pueden afectar los objetivos de un proyecto y pudieran contribuir a su
éxito o fracaso.

Los riesgos con un potencial de impacto positivo en el proyecto se

denominan “oportunidades”, mientras que las amenazas son riesgos
que pudieran afectar negativamente a un proyecto.
RIESGOS vs
PROBLEMAS

Los riesgos con un potencial de impacto positivo en el proyecto se denominan

“oportunidades”, mientras que las amenazas son riesgos que pudieran afectar
negativamente a un proyecto.

Debido a que los riesgos son incertidumbres a futuro, no tienen ningún impacto
actual en el proyecto, pero podrían tener un impacto potencial en el futuro.
Los problemas generalmente son certezas que se están suscitando en el proyecto,
por lo que no hay necesidad de realizar una evaluación de la probabilidad como lo
haríamos con un riesgo. Los problemas deben atenderse.
PRIORIZACIÓN
DE RIESGOS
PROCESOS
EN SCRUM
PATRONES CORE
DE SCRUM

3 ROLES 5 EVENTOS 3 ARTEFACTOS

QUE ES
SCRUM?
PRODUCT OWNER
EL Product Owner es el responsable de maximizar el
valor del producto.

● Expresar claramente los requerimientos.

● Ordenar los elementos de la lista de requerimientos para
alcanzar los objetivos de la mejor manera posible.
● Optimizar el valor del trabajo desempeñado por el
equipo de desarrollo.
● Asegurar que la lista de requerimientos es visible,
transparente y claro para todos.
● Asegurar que el equipo de desarrollo entiende los
elementos de la lista de requerimientos.

ROLES
LAS PRINCIPALES
RESPONSABILIDADES
> Asegurar que el Equipo de Desarrollo entiende los
elementos del Product Backlog al nivel necesario.
> Desarrollar la visión del producto: Público objetivo,
> Ordenar los elementos en el Product Backlog
Necesidades, Funcionalidades y ROI.
para alcanzar los objetivos y misiones de la
mejor manera posible.
> Definir el Release Plan del producto (MVP versions).
> Asegurar que el Product Backlog es visible,
> Entendimiento de los OKRs y definición de los KPIs
transparente y claro para todos y que muestre
de negocio.
aquello en lo que el equipo trabajará a continuación.
> Liderar la Sprint Planning.
> Refinar las Historias de Usuario.
> Garantizar que se defina el objetivo del sprint.
> Validar que el incremento de producto cumpla los
criterios de aceptación.
> Expresar claramente los elementos de la Lista del
Producto.
> Garantizar la asistencia de los Stakeholders a la
Sprint Review.
> Priorizar los Ítems de mejora continua planteadas
por el equipo en el Backlog.
Q aE ES
SCRa M ?
DEVELOPERS
Los developers son los profesionales que desempeñan
el trabajo de entregar un incremento de producto
“Terminado”, que potencialmente se pueda poner en
producción al final de cada Sprint.

● Son auto-gestionados.
● Los equipos de desarrollo son multifuncionales.
● Scrum no reconoce títulos para los miembros de un
equipo de desarrollo.
● La responsabilidad del cumplimiento recae en todo el
equipo.
LAS PRINCIPALES
RESPONSABILIDADES
> Ser auto-gestionado y multifuncional.
> Definir principios y acuerdos como equipo que
promuevan la excelencia técnica.
> Promover y participar activamente en los
refinamientos y estimaciones.
> Seleccionar los elementos del Product Backlog
que serán comprometidos para lograr el
objetivo del sprint.
> Exigir que se cumpla el Definition of Ready.
> Cumplir con la Definition of Done.
> Evitar y/o mitigar la deuda técnica del producto.
> Liderar la sincronización diaria (Daily).
> Durante la review, demostrar el trabajo
terminado.
> Definir las tareas para el sprint.
> Promover la integración continua.
Q aE ES
SCRa M ?
SCRUM MASTER
El Scrum Master es responsable de promover y apoyar Scrum
como se define en la Guía de Scrum. Los Scrum Masters
hacen esto ayudando a todos a entender la teoría, prácticas,
reglas y valores de Scrum.

●Facilitar reuniones y eventos del equipo

●Coaching a los miembros del equipo, mediando a través
de conflictos, ayudando a las decisiones y al equipo a ser
auto-organizado.
●Aprendizaje continuo, ayudando al equipo a crear
radiadores de información.
● Remover o ayudar a remover impedimentos.
●Reflejar los valores ágiles y de Scrum, recordando al
equipo sus acuerdos, ayudando al equipo continuamente
a mejorar sus procesos y preguntar cuestiones abiertas.
LAS PRINCIPALES
RESPONSABILIDADES
> Entender y practicar la agilidad.
> Facilitar los eventos de Scrum según se
requiera o necesite.
> Encontrar técnicas para gestionar el
Product Backlog de manera efectiva.
> Liderar la Sprint Retrospective.
> Ayudar al Equipo Scrum a entender la
necesidad de contar con elementos del
Product Backlog claros y concisos.
> Asegurar que el Dueño de Producto
conozca cómo ordenar el Product Backlog
para maximizar el valor
> Guiar al Equipo de Desarrollo en ser auto
organizado y crossfuncional
> Eliminar impedimentos para el progreso del
Equipo de Desarrollo
> Guiar al Equipo de Desarrollo en entornos
organizacionales en los que Scrum aún no
haya sido adoptado y entendido por
completo.
> Garantizar que las reuniones de trabajo
sean altamente efectivas
> Desarrollar la motivación de cada uno de
los miembros del equipo aplicando técnicas
como Improvement Kata y Moving
Motivators.
TALLER DE
ROLES

ACTIVIDAD

https://trello.com/invite/b/zHtH4LfO/d52b0b400724ce712289cba58c97bdf2/roles
5 EVENTOS
Q aE ES
SCRa M ?
SPRINT

El Sprint corresponde al bloque de tiempo (entre 1 a 4

semanas) durante el cual se crea un incremento de
producto “Terminado”, utilizable y potencialmente
desplegable. Cada nuevo Sprint comienza
inmediatamente después de la finalización del Sprint
previo.

EVENTOS
1 a 4 semanas
Q aE ES
SCRa M ?
SPRINT PLANNING
Descripción: El trabajo a realizar durante el Sprint se planifica
en la Sprint Planning. Este plan se crea mediante el trabajo
colaborativo del Equipo Scrum completo.

Que me llevo: Definir qué puede entregarse en el Incremento

resultante del Sprint que comienza y cómo se conseguirá
hacer el trabajo necesario para entregar el Incremento. ¿Por
qué este sprint es valioso?
Objetivo del evento: Definición del objetivo y predicción del
sprint (Pronóstico).

Cuando ocurre: Al inicio del sprint

Cuánto demora: 8 horas máximo(sprint 1 mes)

EVENTOS Quienes participan: Equipo scrum

SPRINT
PLANNING
Q aE ES
SCRa M ?
DAILY SCRUM
Descripción: Reunión que busca sincronizar las actividades y
el plan del equipo de desarrollo para las siguientes 24 horas.

Que me llevo: Una actualización de lo que el equipo está

haciendo para lograr el objetivo del sprint.
Visibilizar los impedimentos que no se hayan conversado por
otra vía.

Objetivo del evento: Que el equipo realice una planeación

diaria en pro de conseguir el objetivo del Sprint.

Cuando ocurre: Diariamente

Cuánto demora: 15 minutos máximo.

EVENTOS Quienes participan: Developers como mínimo.

DAILY
SCRUM
Q aE ES
SCRa M ? SPRINT REVIEW
Descripción: Es una reunión informal, no de seguimiento,
donde mediante la presentación del incremento, se busca
facilitar la retroalimentación y la colaboración.

Que me llevo: Feedback de los stakeholders

Objetivo del evento:

1. Inspeccionar el incremento.
2.Recolectar el feedback obtenido en la reunión para
adaptar el Product Backlog si fuese necesario.
3.Facilitar la retroalimentación de información y
fomentar la colaboración.

Cuando ocurre: Al finalizar el sprint

Cuánto demora: 4 horas máximo(sprint 1 mes)

EVENTOS Quienes participan: Equipo scrum, stakeholders.

SPRINT
REVIEW
Q aE ES
SCRa M ? RETROSPECTIVE
Descripción: La Retrospectiva del Sprint es una oportunidad
para el Equipo Scrum de inspeccionarse a sí mismo y de crear
un plan de mejoras que sean abordadas durante el siguiente
Sprint
El Scrum Master se asegura de que la reunión sea positiva y
productiva.

Que me llevo: Plan de acción de mejoras.

Objetivo del evento:

1. Inspeccionar/Reflexionar el proceso realizado en
el sprint.
2.Generar un plan de mejora para el siguiente
sprint.

Cuando ocurre: Al finalizar del sprint

Cuánto demora: 3 horas máximo (sprint 1 mes)

EVENTOS Quienes participan: Equipo scrum

SPRINT
RETROSPECTIVE
QUE ES
SCRUM? REFINAMIENTO*
Descripción: Presentar las próximas PBIs al equipo que van a
entrar tanto para el siguiente sprint como para los 2 o tres
próximos y discutir aspectos sobre ellos, como los insumos,
riesgos y dependencias.

Que me llevo: PBIs refinados. Entendimiento de los PBIs a

tomar en los próximos sprints.

Objetivo del evento: Generar entendimiento de los PBIs del

Product Backlog por parte del equipo scrum y refinarlas según
corresponda.

Cuando ocurre: Durante el Sprint.

Cuánto demora: No más del 10% de la capacidad del equipo

EVENTOS Quienes participan: Equipo scrum

3 ARTEFACTOS
 PRODUCT
BACKLOG

El Product Backlog contiene un listado de

ítems (Product Backlog Items, PBIs) o
características del producto a construir.

El Product Owner es el responsable del listado

de características del producto, incluyendo,
disponibilidad y ordenación.

Compromiso Product Goal

ARTEFACTOS
Los ítems están
organizados
por prioridad, en la
parte superior se
encuentran los más
prioritarios.
 SPRINT
BACKLOG
Es el conjunto de elementos del Product
Backlog seleccionados para el Sprint.
Es un PRONÓSTICO hecho por el Equipo de
Desarrollo acerca de qué funcionalidad formará
parte del próximo Incremento y del trabajo
necesario para entregar esa funcionalidad en un
Incremento “Terminado”.

Para asegurar el mejoramiento continuo, la Lista

de Pendientes del Sprint incluye al menos una
mejora de procesos de alta prioridad identificada
en la Retrospectiva inmediatamente anterior.
ARTEFACTOS
Compromiso Sprint Goal
 INCREMENTO
DE PRODUCTO

El Incremento es la suma de todos los elementos

de la Lista de Producto completados durante un
Sprint y el valor de los incrementos de todos los
Sprints anteriores. El incremento debe estar en
condiciones de utilizarse sin importar si el Dueño
de Producto decide liberarlo o no.

Compromiso Definition of Done

ARTEFACTOS
 DEFINITION
OF READY *

DoR Corresponde al conjunto de

características que debe cumplir un PBI para
que el equipo de desarrollo pueda
comprometerse en su entrega, es decir,
incluirla en un Sprint Backlog

ARTEFACTOS
EJEMPLO
DoR
 DEFINITION
OF DONE*
DoD Cuando un elemento de la Lista de
Producto o un Incremento se describe como
“Terminado”, todo el mundo debe entender lo
que significa “Terminado”.
Aunque esto varía significativamente para
cada Equipo Scrum, los miembros del Equipo
deben tener un entendimiento compartido de
lo que significa que el trabajo esté
ARTEFACTOS completado, para asegurar la transparencia
EJEMPLO
DoD
HISTORIAS
DE USUARIO
En agilidad las historias de usuario son el reemplazo escrito de
los requerimientos de usuario, se escriben en el lenguaje propio
de los usuarios y describen que debería “construir” y “entregar”
el equipo de desarrollo.

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

extensiva.
(Valoramos las personas y sus interacciones por sobre los
procesos y las herramientas, el software funcionando por sobre la
documentación extensiva)
BUENAS HISTORIAS
DE USUARIO
Las 3C
C ard

C onvers ation

C onfirmation
 Las HU deben ser cortas, caber en una tarjeta de
fichero. Contiene el título, la descripción y los
criterios de aceptación.

Debe contener:

● Título corto HU
C ard
● Descripción
● Criterios de aceptación
¿Título corto?

Título corto: Verbo + complemento

Eliminar us uario Detalles de usuario

inactivo
Carro de compras
C ambiar contras eña
Configuración de
Publicar pos t usuario
Formato de descripción
¿Qué preguntas responder?

¿ Q uién? Como . R ol

¿ Q ué? Quiero . Necesidad

¿ P ara qué? Para . Valor

Algunos ejemplos
de descripción
Como usuario registrado Como visitante web

Quiero cambiar mi contraseña Quiero suscribirme a la lista

de difusión
Para mantener mi cuenta
segura Para recibir novedades por
email

Como usuario móvil Como administrador

Quiero grabar todos mis datos Quiero desactivar un usuario

en la nube
Para prevenir accesos no
Para acceder desde otros autorizados de ex empleados
dispositivos
 Una historia de usuario no es un reemplazo de un
documento de requisitos, es un disparador para
tener una conversación con las personas
pertinentes, cuando sea necesario, sobre los
requisitos. De hecho, la idea es tener una
colaboración continua con el cliente a través de
conversaciones.
Conversation
 Finalmente, la historia de usuario ayuda al equipo
a discutir con el propietario del producto cómo
determinar cuándo una característica / pieza de
trabajo está completa.

Para la confirmación se utilizan generalmente

C onfirmation criterios de aceptación.
C oncepto INVES T

INVES T
Independent
Negotiable
Valuable
Estimable
Small sized
Testable
¿ QUÉ
ES UN CRITERIO DE
ACEPTACIÓN (CA)?

Son enunciados que se describen desde el punto de

vista del usuario/product owner cuándo una historia se
puede considerar hecha y correctamente
implementada.
DEFINITION OF DONE Vs
CRITERIO DE ACEPTACIÓN
Definición de terminado (DoD) Criterios de aceptación (CA)

Sirve para desambiguar el Sirve para clarificar requerimientos del

entendimiento de que debe hacerse negocio / condiciones que se deben
antes de declarar cualquier PBI hecho cumplir para satisfacer al usuario en un
y completo requerimiento dado
Se aplica por igual a todos los PBI Aplica a un único PBI

Pertenece al equipo, es entendido y Es propiedad del Product Owner, el

acordado por todo el equipo Scrum equipo de desarrollo lo entiende

No cambia frecuentemente, no debería Son negociables entre el Product

cambiar durante el Sprint Owner y el equipo de desarrollo

Cumplir con el DoD debe implicar Su cumplimiento no implica cumplir con

cumplir con el CA el DoD
 ESTIMACIÓN DE
HISTORIAS
E l principal objetivo de este tipo de
estimación, es utilizar técnicas de
asociación donde prima lo subjetivo
en un entorno en el que un grupo de
personas deberán ponerse de
acuerdo frente a algo específico y
complejo.
QUIÉN DEBE
ESTIMAR?
•
En el modelo de estimación por esfuerzo no es el
Cliente o el Product Owner quienes en solitario
estiman, la estimación la debe hacer quien se va a
“meter en faena”, es decir quienes definen el cómo lo
hacen...y lo hacen (Developers).
•
De esta forma conseguimos: Reforzar la
responsabilidad de todo el equipo respecto a los
compromisos adquiridos, hacemos que todos se sientan
escuchados y que podemos aterrizar la estimación a
algo más acertado.
TÉCNICAS DE
ESTIMACIÓN
 Planning
Poker
Es una tecnica que permite hacer una estimación inicial rápida y segura del
proyecto, puesto que todos los miembros del equipo comparten en “cada
mano” sus diferentes informaciones y expresan su opinión.

Cada número significa un peso /complejidad / esfuerzo necesarios para

completar una historia de usuario.

La numeración de las cartas está basada en la sucesión de Fibonacci, en la

que la distancia entre los números crece a medida que estos se hacen
mayores.
TALLAS DE
CAMISETA
EJEMPLO
Utilizando la serie Fibonacci, estime en términos de la Complejidad y
el Esfuerzo de peinar a los siguientes animales.
¡Gracias!
anroru@gmail.com

http://linkedin.com/in/andres-rodriguez-rubio-
18064ba5

316 690 6616

 CASO No 1
Como nuevo Scrum Master te damos la bienvenida a la célula de trabajo cliente internacional, la cual esta constituida por 5 personas del
equipo de desarrollo y Producto Owner.
Actualmente, esta célula lleva trabajando 12 sprint y están próximos a su entrega de MVP que se tiene planeada para el Sprint 20. El
anterior Scrum Master fue asignado a un nueva célula y tu serás el responsable de continuar apoyando a la célula desde tu rol como
Scrum Master.
Alejandra, la anterior Scrum Master ha identificado una lista de comportamientos que ha considerado que si no son trabajados como
oportunidades de mejora, el equipo no lograra entregar su MVP en el Sprint 20.

La lista de comportamientos es:

◦ Entre el PO y el equipo de desarrollo solo se comunican por correo electrónico
◦ Los miembros del equipo de desarrollo han solicitado no tener el PO dentro de las retrospectivas.
◦ Cada vez que el PO esta en la daily, el equipo se incomoda y en muchas ocasiones duran mas de lo que deben.

Teniendo en cuenta la lista de comportamientos que Alejandra te ha dejado como parte de su entrega; desde tu experiencia y
conocimiento qué acciones propondrías para ayudar a:
◦ Poder llegar al sprint 20 con el MVP.
CASO No 2
En un equipo de trabajo multifuncional se tienen constantes
quejas de la calidad de trabajo del desarrollador Juan. Esto
ocasionó que Leidy, una de las integrantes del equipo se fuera
debido a que la calidad y resultados de su trabajo se estaban
viendo afectados.

Posterior a esto, el reemplazo de Leidy llegó al equipo y en una

sesión de feedback se evidencia que el nuevo integrante presenta
las mismas quejas hacia Juan.

¿Desde tu rol de Scrum Master, cual sería la propuesta para

solucionar esta situación?
CASO No 3
La Compañía en la cual trabajas durante el último año ha aplicado
marcos ágiles de trabajo para su Transformación Digital, durante ese
tiempo, fue necesario contar con un rol de alto perfil (El Escalador)
que se encarga de la remoción de impedimentos organizacionales para
la adopción de los productos implementados a nivel portafolio.

Gracias a los buenos resultados obtenidos por la compañía, esta ultima

está dispuesta a seguir implementando esta figura de Escalador; sin
embargo no cuenta con las personas que tengan las habilidades para
ello.

¿Desde tu rol cual sería la propuesta para solucionar esta situación ?

CASO No 4
Tu equipo Scrum fue contratado para desarrollar una página WEB de
un cliente que tiene una agencia de viajes, en ella ofrece tiquetes
nacionales e internacionales, hoteles, renta de vehículos, promociones
y registro de clientes VIP.

Tienes 4 Sprint para diseñar una solución con base en los

requerimientos planteados por el cliente en el siguiente tablero:
https://trello.com/invite/b/5QJLTmio/8ceddd237d45daf70dcbdabe45f
9822c/paginaweb

Recuerda que al utilizar el Marco de trabajo Scrum se debe realizar un

proceso de entregas iterativas y funcionales.
LECTURAS
RECOMENDADAS