Basic Student Material For CertiProf Scrum Master Professional Certificate Espanol V42018A PDF

SCRUM
MASTER
PROFESSIONAL
CERTIFICATE
(SMPC)
L
I ONA CERT
SS I
FI
FE
CA
PRO
TE
SCRUM MASTER
SMPC
VERSION 04 - 2018
www.certiprof.com
SCRUM
MASTER
PROFESSIONAL
CERTIFICATE
(SMPC)
Objetivos
• Alcance, propósito, términos y definiciones claves para Scrum Master
Professional Certificate (SMPC) y como puede ser utilizado.
VERSION 04 - 2018
• Certificación profesional.
©2018 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and 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 ShareAlike license of Creative Commons.
www.certiprof.com
(SMPC) VERSION 04 - 2018
ESQUEMA
Presentación y Logística 5
Introducción 6
Tipos de Proyectos 7
Manifiesto Ágil 8
Aspectos o Pilares del Manifiesto 8
Principios detrás del Manifiesto Ágil 9
Principios 10
Declaración de interdependencia 11
Los 6 valores Declaración de interdependencia 11
¿Qué es agilidad? 12
¿Cómo debemos ver a la agilidad? 12
¿Por qué metodologías ágiles? 13
Gestión de Proyectos tradicional 14
¿Qué es Scrum? 15
Usos de Scrum 15
Teoría de Scrum 16
Iterativo 17
Tres pilares de Scrum 17
Transparencia 18
Inspección 18
Adaptación 19
Los Valores de Scrum 20
La esencia de Scrum 21
Roles 22
Scrum Team 23
Product Owner 24
Responsabilidades del Product Owner 25
Características de un Product Owner 26
Scrum Master 27
Responsabilidades del Scrum Master con el Product Owner 28
Responsabilidades del Scrum Master con la organización 29
Responsabilides del Scrum Master con el Development Team 30
Development Team 31
Tamaño del Development Team 31
Responsabilidades del Development Team 32
Características�Development Team 33
3 www.certiprof.com
ESQUEMA
Stakeholders 34
Stakeholders se dividen en: 34
Conceptos Claves en Scrum 35-37
Nivel de detalle 38
¿Cómo está conformada una User Story? 38
Estructura de User Story 39
Task 39
¿Cómo está conformada una Task? 40
Definición de Done 40
Time-Boxing 41
Ventajas de Time-Boxing 41
¿Dónde se utilizan los Time-Boxing? 42
Eventos formales 43
Sprint 44
Cancelación de un Sprint 45
Reuniones o ceremonias de Scrum 46
Daily Standup Meeting 47
Reunión diaria (Daily Sprint) 48
Sprint Planning Meeting 49
¿Qué puede ser terminado? 50
Sprint Goal 50
¿Cómo se conseguirá completar el trabajo seleccionado? 51
Estimación Planning Póker 51
Sprint Review Meeting 52
Sprint Retrospective 53
Las 5 Etapas de una Retrospectiva 54
Artefactos 54
Product Backlog 55
Refinamiento del Product Backlog 56
Sprint Backlog 57
Priorización 58
Seguimiento 59
Incremento 60
4 www.certiprof.com
Presentación y
Logística
VERSION 04 - 2018
www.certiprof.com
Presentación y Logística
Bienvenido
Preséntese en el siguiente formato:
Nombre
Empresa
Papel y fondo
Familiaridad con los conceptos y la práctica de Scrum
Expectativas de este curso
6 www.certiprof.com
Introducción
Los proyectos se ven afectados por las limitaciones de tiempo, costo, alcance,
calidad, recursos, capacidades organizativas y otras limitaciones que los hacen
difíciles de planificar, ejecutar, administrar y finalmente tener éxito.
Tipos de Proyectos
En el eje horizontal tenemos la experiencia y nuestro conocimiento sobre una
herramienta; en el eje vertical se plasma la claridad de los requerimientos.
SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)
7 www.certiprof.com
Introducción
Manifiesto Ágil
El manifiesto Ágil surge el 17 de febrero del 2001, cuando se reunieron diecisiete
críticos del desarrollo de software, y acuñaron el término “metodología Ágil”
para definir los métodos que estaban surgiendo como alternativa a las
metodologías formales.
El manifiesto Ágil está conformado por 12 principios asociados a 4 aspectos o

pilares.
REF: http://agilemanifesto.org/iso/es/manifesto.html
Aspectos o Pilares del Manifiesto
� A los individuos y su interacción, por encima de los procesos y las herramientas.

� El software que funciona, por encima de la documentación detallada.
� La colaboración con el cliente, por encima de la negociación contractual.
� La respuesta al cambio, por encima del seguimiento de un plan.
Procesos y Documentación
Herramientas detallada

Individuos e Software
Interacciones funcionando
Colaboración Respuesta ante

con el cliente el cambio
Negociación Seguir un
contractual plan
8 www.certiprof.com
Introducción
Principios detrás del Manifiesto Ágil
� La mayor prioridad es satisfacer al cliente a través de la entrega temprana y

continua de software útil.
� Bienvenidos los cambios a los requerimientos, incluso los tardíos.
� Liberar frecuentemente software funcionando, desde un par de semanas a un
par de meses, con preferencia por los periodos más cortos.
� Los responsables del negocio y los desarrolladores deben trabajar juntos
diariamente durante el proyecto.
� Construir los proyectos alrededor de individuos motivados. Proporcionar el
ambiente y el soporte que necesiten, y confiar en que conseguirán realizar el
trabajo.
� La conversación directa es el método más eficiente y efectivo de transmitir
información, tanto al equipo como dentro de éste.
Sa�sfacción Cambio a los

del Cliente requerimientos

La conversación Liberar
directa es el
método más PRINCIPIOS frecuentemente
So�ware
eficiente y efec�vo funcional
Construir los proyectos Trabajo conjunto

alrededor de individuos entre los responsables
mo�vados del negocio y los
desarrolladores
9 www.certiprof.com
Introducción
Principios
� El software funcionando es la medida de progreso.

� Los procesos ágiles promueven el desarrollo sostenible.
� La atención continua a la excelencia técnica y al buen diseño incrementan la
agilidad.
� La simplicidad - el arte de maximizar la cantidad de trabajo no hecho - es
esencial.
� Las mejores arquitecturas, requerimientos y diseños emergen de los equipos
auto-organizados.
� En intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo,
entonces afina y ajusta su comportamiento como corresponde.
El so�ware Los procesos ágiles

funcionando es la promueven el
medida de progreso desarrollo sostenible

Excelencia
Reflexión y técnica y el
efec�vidad PRINCIPIOS buen diseño
incrementa la
agilidad
Equipos La simplicidad es arte

auto-organizados
10 www.certiprof.com
Introducción
Declaración de interdependencia
La Declaración de interdependencia en la gestión de proyectos fue escrita a

principios del 2005 por un grupo de 15 líderes de proyectos como un
suplemento al “Manifiesto Ágil”.
Enumera seis valores de gestión necesarios para reforzar una mentalidad de
desarrollo ágil, particularmente en la gestión de proyectos complejos e inciertos.
[©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair

http://pmdoi.org Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith,
Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna
Pixton, Preston Smith and Robert Wysocki.]
Los 6 valores Declaración de interdependencia
1. Aumentamos el retorno de inversión, al enfocarnos en el flujo continuo de

valor.
2. Ofrecemos resultados fiables mediante la participación del cliente en las
iteraciones frecuentes, donde también son responsables por el trabajo.
3. Asumimos que habrá incertidumbre y las superamos a través de iteraciones,

anticipación y adaptación.
4. Damos rienda suelta a la creatividad y la innovación al reconocer que las
personas son la fuente máxima de valor y creamos un entorno en el que puedan
tener un impacto positivo.
5. Aumentamos el rendimiento a través de la rendición de cuentas por parte del
grupo en cuestión de resultados y eficacia del equipo, responsabilidades que
todos comparten.
6. Mejoramos la eficacia y la fiabilidad a través de estrategias situacionalmente
específicas, procesos y prácticas.
[©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair
http://pmdoi.org Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith,
Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna
Pixton, Preston Smith and Robert Wysocki.]
Introducción
¿Qué es agilidad?
“Agilidad es la capacidad de crear y responder al cambio con el fin de obtener

ganancias en un entorno empresarial turbulento”.
“La agilidad es la capacidad de equilibrar la flexibilidad y estabilidad”.
SCRUM CRYSTAL
LEAN KANBAN
Agile
PDD XP
ASD

DSDM
¿Cómo debemos ver a la agilidad?
En cualquier tipo de disciplina de gestión, ser ágil es una cualidad, por lo tanto
esto debe ser una meta que se debe tratar de alcanzar.
La gestión de proyectos Agile especialmente, implica la adaptabilidad durante la

creación de un producto, servicio o cualquier otro resultado.
Introducción
¿Por qué metodologías ágiles?
El 80% de todos los proyectos emplearán Métodos Ágiles en los próximos años
(Gartner).
Casi tres cuartas partes (71%) de las organizaciones informan que utilizan
enfoques ágiles a veces, a menudo o siempre. (Fuente: Project Management
Institute)
Introducción
Gestión de Proyectos tradicional
Requirements Ventajas: Orden Lógico

Desventaja: Asume Predictibilidad
Analysis
Design
Coding
Testing
Operation
Introducción
¿Qué es Scrum?
Scrum es un marco de trabajo de adaptación iterativa e incremental, rápido,

flexible y eficaz diseñado para ofrecer un valor significativo de forma rápida en
todo el proyecto.
Scrum es:
• Ligero
• Fácil de Entender
• Extremadamente difícil de llegar a dominar
Usos de Scrum
Scrum fue desarrollado inicialmente para gestionar y desarrollar productos.

Desde principios de los años 90.
Scrum se ha usado para desarrollar software, hardware, software embebido,

redes de funciones interactivas, vehículos autónomos, escuelas, gobiernos,

mercadeo, también para gestionar la operación de organizaciones y casi todo lo
que usamos en nuestra vida diaria, como individuo y como sociedad.
Scrum demostró ser especialmente efectivo en la transferencia iterativa e

incremental de conocimiento. Scrum se usa ahora ampliamente para productos,
servicios y gestión de la organización matriz.
Teoría de
Scrum
VERSION 04 - 2018
www.certiprof.com
Teoría de Scrum
Iterativo
Scrum se basa en la teoría de control de procesos empírica o empirismo.
El empirismo asegura que el conocimiento procede de la experiencia y de tomar

decisiones basándose en lo que se conoce.
Scrum emplea un enfoque iterativo e incremental para optimizar la

predictibilidad y el control del riesgo.
Vision Iteration
1
Iteration
2
Iteration
3
Iteration
4
Continue
Tres pilares de Scrum

• Transparencia
• Inspección
• Adaptación
Teoría de Scrum
Transparencia
Los aspectos significativos del

proceso deben ser visibles para
aquellos que son responsables del
resultado.
La transparencia requiere que dichos
aspectos sean definidos por un
estándar común, de tal modo que los
observadores compartan un
entendimiento común de lo que se
están viendo.
Inspección
Los usuarios de Scrum deben

inspeccionar frecuentemente los
artefactos de Scrum y el progreso

hacia un objetivo para detectar
variaciones indeseadas.
Su inspección no debe ser tan
frecuente como para que interfiera
en el trabajo.
Las inspecciones son más
beneficiosas cuando se realizan de
forma diligente por inspectores
expertos en el mismo lugar de
trabajo.
Teoría de Scrum
Adaptación
Uno de los tres pilares del control del

proceso empírico; la
retroalimentación se usa para hacer
un ajuste al producto de trabajo que
se está desarrollando o al proceso
por el cual se está desarrollando.

Sprint
Sprint Planning Daily Scrum Sprint Review Retrospective
Meeting Meeting Meeting
Backlog Refinement
Meeting
Teoría de Scrum
Los Valores de Scrum
• Compromiso
• Coraje
• Foco
• Apertura
• Respeto
Los miembros del Equipo Scrum aprenden y exploran estos valores a medida que
trabajan en los eventos, roles y artefactos de Scrum.
COMPROMISO CORAJE

FOCO APERTURA RESPETO
Teoría de Scrum
La esencia de Scrum
La esencia de Scrum es un pequeño equipo de personas. El equipo individual es

altamente flexible y adaptativo. Estas fortalezas continúan operando en un
equipo, en varios, en muchos y en redes de equipos que desarrollan, liberan,
operan y mantienen el trabajo y los productos de trabajo de miles de personas.
Cuando las palabras “desarrollar” y “desarrollo” se usan en la Guía de Scrum se

esta haciendo referencia a trabajo complejo, tales como estos identificados
anteriormente.
Agile PLANNING
Strategy
Portfolio
Product
Release

Sprint
Daily
Roles
VERSION 04 - 2018
www.certiprof.com
Roles
Un conjunto cohesivo de responsabilidades que pueden ser cumplidas por una o

más personas.
Los tres roles de Scrum son Propietario del producto, Scrum Master y equipo de
desarrollo.
Scrum Team
El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo

de Desarrollo (Development Team) y un Scrum Master.
Los Equipos Scrum son autoorganizados y multifuncionales.
El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la
creatividad y la productividad.
El equipo de Scrum ha demostrado ser cada vez más efectivo para todos los usos
anteriores y cualquier trabajo complejo.
Los Equipos Scrum entregan productos de forma iterativa e incremental,
maximizando las oportunidades de obtener retroalimentación. Las entregas
incrementales de producto “Terminado” aseguran que siempre estará disponible
una versión potencialmente útil y funcional del producto.
Roles
Product Owner
El Product Owner (PO) representa la voz del cliente, y es el encargado de

maximizar el valor del producto.
• Un PO siempre debe mantener una visión dual.

• El debe entender y apoyar las necesidades e intereses de todos los
Stakeholders.
• Comprende las necesidades y el funcionamiento del Development Team.
Roles
Responsabilidades del Product Owner
Determinar las Ayudar en la Asegurar los

actividades definición de la recursos financieros
generales de inicio visión del proyecto del proyecto
de un proyecto
Centrarse en la Evaluar la viabilidad Representar al

creación de valor y y garantizar la usuario o cliente
en la generación del entrega del producto
ROI o servicio
Ayudar en la elección Responsable por la Ayudar a crear y a

del Scrum Master y administración del aprobar los User

de los miembros del Product Backlog Story
Development team
Explicar los User Definir los criterios Participar en la

Story al de aceptación retrospectiva del
Development Team Sprint y el proyecto
Roles
Características de un Product Owner
Conocimiento Excelentes Conocimiento de

del negocio habilidades de procesos de
comunicación Scrum
Habilidades de Decisivo Proactivo

negociación

Accesible Orientado a
las metas
Roles
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.
El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum
Master ayuda a las personas externas al Equipo Scrum a entender qué
interacciones con el Equipo Scrum pueden ser útiles y cuáles no.
El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el
valor creado por el Equipo Scrum.
Roles
Responsabilidades del Scrum Master con el Product Owner
Asegurar que los

Objetivos, el alcance y Fomenta la necesidad
Facilitar técnicas para
el dominio del de contar con
gestionar el Product
producto sean elementos de lista de
Backlog de manera
entendidos por todos productos claros y
eficiente
en el Equipo Scrum concisos
Asegurar que el
Entender la dueño del producto
planificación del conozca como Entender y practicar la
producto en un ordenar la lista de agilidad
entorno empírico producto para
maximizar valor

Explica cómo realizar
un levantamiento de
requerimientos ágiles
Roles
Responsabilidades del Scrum Master con la Organización
Planifica la Ayuda al Scrum Team

Lidera y guía a la
implementación de (PO y DT) y Stakeholders
organización en la
Scrum en la a entender y llevar a
adopción de Scrum
organización cabo Scrum
Motiva cambios que Trabaja de la mano de

incrementen la otros Scrum Master
productividad del para incrementar la

Scrum Team (PO y DT) efectividad de Scrum
Roles
Responsabilides del Scrum Master con el Development Team
Asegura que el Ayuda al Development

Guía al equipo en ser ScrumBoad Team para crear
auto-organizado y permanezca productos de alto
multifuncional actualizado valor.
Elimina Asiste al Development

impedimientos para el Facilitar los eventos Team en el desarrollo
de Scrum según se
progreso de la del Sprint Backlog y el
requiera o necesite

construcción Sprint Burdown Chart
Roles
Development Team
El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de

entregar un Incremento de producto “Terminado” que potencialmente se pueda
poner en producción al final de cada Sprint.
Un Incremento “Terminado” es obligatorio en la Revisión del Sprint.
Solo los miembros del Equipo de Desarrollo participan en la creación del
Incremento.
La organización es la encargada de estructurar y empoderar a los Equipos de
Desarrollo para que estos organicen y gestionen su propio trabajo. La sinergia
resultante optimiza la eficiencia y efectividad del Equipo de Desarrollo.
Tamaño del Development Team
El tamaño óptimo del Equipo de Desarrollo es lo suficientemente pequeño como

para permanecer ágil y lo suficientemente grande como para completar una
cantidad de trabajo significativa.
Tener menos de tres miembros en el Equipo de Desarrollo reduce la interacción
y resulta en ganancias de productividad más pequeñas.
Los Equipos de Desarrollo más pequeños podrían encontrar limitaciones en

cuanto a las habilidades necesarias durante un Sprint, haciendo que el Equipo de
Desarrollo no pudiese entregar un Incremento que potencialmente se pueda
poner en producción.
Tener más de nueve miembros en el equipo requiere demasiada coordinación.
Roles
Responsabilidades del Development Team
Asegurar una Estimar los User

Crear entregables de
comprensión clara de Stories aprobados
alta calidad
los requerimentos por el PO
Desarrollar la lista de
tareas basada en las Calcular el esfuerzo
User Stories para las tareas
aprobadas identificadas
Desarrollar el Sprint Identificar el riesgo y

Backlog y el Sprint Crear los entregables ejecutar acciones para
Burdown Chart su mitigación
Identificar Participar en la
oportunidades de retrospectiva del
mejora proyecto y Sprint
Roles
Características Development Team
Conocimiento de Altamente
Scrum Colaboración Motivados
Expertos Auto
Proactivos Técnicos organización
Buen miembro

Independientes Responsables
de equipo
Intuitivos Orientados a los

objetivos
Roles
Stakeholders
Una persona, grupo u organización que afecta o puede verse afectado por las
acciones de una organización.
Stakeholders se dividen en:
Cliente: El cliente es la persona o la organización que adquiere el producto del

proyecto, servicio o cualquier otro resultado.
Usuarios: El usuario es el individuo o la organización que utiliza directamente el

producto del proyecto, servicio, o cualquier otro resultado; también, en algunas
industrias el cliente y los usuarios puede ser lo mismo.
Patrocinador: El patrocinador es la persona o la organización que provee

recursos y apoyo para el proyecto, el patrocinador también es el Stakeholder a
quien todos le deben rendir cuentas al final.

Customer Development Team
El Development Team le demuestra el
El Customer le proporciona sus
incremento de producto al Product Owner
requisitos al Product Owner
durante el Sprint Review Meeting
El Product Owner le ofrece valor al

negocio del Customer a través del
Incremental Product Release
Product Owner
El Product Owner les comunica los

requerimientos del negocio priorizados os
a l to
al Development Team, crea el Prioritized cre oyec
am r un
Product Backlog y define los Acceptance Te l p ra o
r u m s de e gu cuad
Criteria e s
Sc bl r a de
El trega ste jo a eam
en Ma raba m T
Scrum Master rum de t Scru
Sc l
El torno ra e
en pa
Conceptos
Claves en Scrum
VERSION 04 - 2018
www.certiprof.com
Conceptos Claves en Scrum
Product
Idea
Sprint Product Backlog

Retrospective
Sprint Planning
Sprint Review

Potentially Shippable
Product Sprint Backlog
Increment
Daily Scrum Sprint Execution
Product Backlog Sprint Planning
Épicas: Es una historia de usuario que es demasiado grande para caber en un

sprint. A menudo, este término se utiliza para describir una gran historia de
usuario que tendrá que ser dividido en historias más pequeñas.
User Stories: Es una representación de un requisito del usuario en forma escrita,

de una o dos frases, utilizando el lenguaje común del usuario.
Task: 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.
Nivel de detalle
REQUISITOS ÁGILES
Épicas Historias de Usuario Tareas
TAREAS
VISIÓN PILA DEL PRODUCTO PILA DEL SPRINT DIARIAS
¿Cómo está conformada una User Story?
Una historia de usuario debe estar Características: modelo INVEST.

conformada por las 3C:

� Independencia
Card (tarjeta): Descripción escrita de lo � Negociables
que necesita el usuario. � Valiosa
Convesación: El PO y el DT aclaran � Estimable
los detalles. � Pequeña
Confirmación: Sirve para determinar � Verificable
lo que se espera.
Estructura de User Story
Título ID
Descripción:
Quién Quiero Beneficio
Prioridad Estimación
Criterios de
Aceptación
Task
El trabajo técnico que realiza un equipo de desarrollo para completar un ítem de

retraso acumulado del producto.

La mayoría de las tareas se definen como pequeñas, lo que representa no más de
unas pocas horas a un día más o menos de trabajo.
¿Cómo está conformada una Task?
Características modelo SMART:

Identificación:
S: Specific (Especifico)
Responsable:
M: Measurable (Medible)
A: Achievable (Alcanzable) Descripción:
R: Relevant (Relevante)
Estimación:
T: Time-boxed (Tiempo-caja)
Definición de Done
Son los acuerdos del PO con los Stakeholders que contiene todas las
condiciones que deben de cumplir los ítems del Product Backlog para considerar
un Sprint completado o finalizado.

Los criterios de Done
aceptación Done es un conjun-
Son los componentes to de reglas que se
objetivos por los cuales aplican a todas las User
se juzga la funcionali- Stories en un
dad de un User determinado Sprint
Story.
Time-Boxing
Todos los eventos son bloques de tiempo (duración máxima de tiempo), de tal
modo que todos tienen una duración máxima.
15 Minutes
Daily Scrum
Meetieng
24 Hours
2-4 Weeks
Potentially Shippable
Product Backlog Product
Sprint Backlog Increment
Ventajas de Time-Boxing

Time-boxing es una práctica crítica en Scrum y debe aplicarse con cuidado.
Un Time-boxing arbitrario puede llevar a la desmotivación del equipo y puede
tener como consecuencia la creación de un entorno opresivo, por lo que
Time-boxing debe ser utilizado de manera apropiada.
Beneficios:
� Procesos de desarrollo eficiente.
� Menos gastos generales.
� Alta velocidad para los equipos.
� Ayuda a gestionar eficazmente la planificación y ejecución de proyectos.
¿Dónde se utilizan los Time-Boxing?
Sprint
Retrospect
Sprint
Meeting
Daily
TIME-BOXING Standup
Meeting
Sprint

Review
Meeting Sprint
Planning
Meeting
Eventos formales
Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la
inspección y adaptación:
� Planificación del Sprint (Sprint Planning)

� Scrum Diario (Daily Scrum)
� Revisión del Sprint (Sprint Review)
� Retrospectiva del Sprint (Sprint Retrospective)
Time-box
Scrum Event (for 1-month Sprint) Participants
Scrum Master, Product Owner,

Sprint Planning 8 Hours
Development Team
Scrum Master (optional), Product Owner

Daily Scrum 15 Minutes
(optional), Development Team
Scrum Master, Product Owner,

Sprint Review 4 Hours Development Team and all key stakeholders
Sprint Scrum Master, Product Owner,

Retrospective 3 Hours Development Team
Sprint
Duración
1 a 4 Semanas
Definición Sprint
Es el corazón de Scrum, en
el cual se crea el
incremento del producto
“terminado“. Cada Sprint
puede considerase un
proyecto con un horizonte
no mayor de un mes Acción
Un Sprint contiene y consiste en:
•Sprint Planninig Meeting

•Daily Standup Meeting
•El trabajo de Desarrollo
•Sprint Review Meeting
•Sprint Retrospective Meeting
Cancelación de un 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.
Entorno Externo
Product Owner

Stakeholders Equipo
¿Es este cambio

urgente?
SI NO
Cancelar el Sprint Los cambios se

y reiniciar con harán en un
Sprint Planning futuro Sprint
No hacer nada
Reuniones o ceremonias de Scrum
Para que cualquier proyecto tenga éxito, la comunicación es importante. Los

equipos Scrum emplean una serie de reuniones clave para estructurar el trabajo
del equipo:
� Daily Standup Meeting

� Sprint Planning Meeting
� Sprint Review Meeting Sprint Planning
Meeting
� Retrospective Sprint Meeting
Backlog Refinement
Daily Scrum Meeting

Sprint Review
Meeting
Sprint
Retrospective
Meeting
Daily Standup Meeting
Duración:
15 Minutos
Daily
Definición Standup
Es una reunión para el Equipo de
Desarrollo, se lleva a cabo cada día del
Meeting
sprint. La Daily Scrum optimiza la
colaboración y el desempeño del
equipo inspeccionando el trabajo Acción
avanzado desde el último Scrum Diario El Equipo de Desarrollo planea el
y haciendo una proyección del trabajo trabajo para las siguientes 24 horas
del Sprint a realizar a continuación. se realiza a la misma hora y en el mismo lugar
todos los días para reducir la complejidad.

Algunos Equipos de Desarrollo usarán
preguntas como:
• ¿Qué hice ayer?
• ¿Qué haré hoy?
• ¿Veo algún impedimento?
Reunión diaria (Daily Sprint)
� Punto de inspección y adaptación en Scrum. Máx. 15 minutos.

� El equipo se reúne para comunicar y entender el estados.
� Esencial para conocer el progreso continuo y evitar bloqueos.
� No tiene como objetivo reportar progreso al Scrum Master Product Owner o
cualquier otro stakeholder.
� El Product Owner podrá participar siempre y cuando su participación sea
pasiva.
� El Scrum Master se asegura de que el Equipo de Desarrollo mantenga Ia
reunión, pero el Equipo de Desarrollo es el responsable de dirigir el Scrum Diario.
Daily Scrum
Sprint Planning Meeting
Duración
8 Horas por un
Sprint de un
mes
Sprint
Definición Planning
El trabajo a realizar durante el sprint Meeting
se planifica en esta ceremonia, este
plan se crea con la colaboración de
todo el Scrum Team. Al finalizar la
reunión de planificación, el
Developmet Team debería ser capaz Acción
de explicar al PO y SM como lograr el En esta ceremonia se formulan 2
objetivo del Sprint como un equipo preguntas:
auto-organizado • ¿Qué puede ser terminado en
este Sprint?
• ¿Cómo se conseguirá completar

el trabajo seleccionado?
El resultado de estas preguntas es
definir el Sprint Goal, Sprint
Backlog, estimación de esfuerzo
¿Qué puede ser terminado?
Esta pregunta nos ayuda para que el

Development Team (DT) trabaje para SPRINT
proyectar la funcionalidad que se GOAL
desarrollará durante el Sprint, donde se
define objetivo del Sprint (Sprint Goal).
El número de elementos del Product

Backlog seleccionados para el Sprint
depende únicamente del Development
Team (DT).
Sprint Goal
SPRINT GOAL

Why are you doing this iteration?
� El Objetivo del Sprint es una meta establecida para el Sprint que puede
lograrse mediante la implementación de la Lista de Producto.
� El objetivo del Sprint brinda al equipo de desarrollo cierta flexibilidad con
respecto a la funcionalidad implementada en el Sprint.
� El objetivo del Sprint puede representar otro nexo de unión que haga que el
Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas
¿Cómo se conseguirá completar el trabajo seleccionado?
Una vez que se ha establecido el objetivo y

seleccionado los elementos de la Lista de
Producto para el Sprint, el Equipo de
Desarrollo decide cómo construirá esta
funcionalidad para formar un Incremento
de producto “Terminado” durante el Sprint.
Los elementos de la Lista de Producto

seleccionados para este Sprint, más el plan
para terminarlos, recibe el nombre de Lista
Sprint Backlog
de Pendientes del Sprint (Sprint Backlog).
Estimación Planning Póker
Esta es una de las técnicas más reconocidas en Scrum, ya que es muy sencilla,
divertida y eficaz, donde el Development Team (DT) estima como grupo el
esfuerzo a realizar en el Sprint.
Sprint Review Meeting
Sprint 1 Done!!!
Team Product Owner

� Los asistentes son el Equipo Scrum y los interesados clave invitados por el
Dueño de Producto.
� El Dueño de Producto explica qué elementos de la Lista de Producto se han
“Terminado” y cuales no se han “Terminado”
� El Equipo de Desarrollo habla acerca de qué estuvo bien durante el Sprint, qué
problemas aparecieron y cómo fueron resueltos esos problemas.
� El Equipo de Desarrollo hace una demostración del trabajo que ha“Terminado”
y responde preguntas acerca del Incremento.

� El Dueño de Producto habla acerca de la Lista de Producto en su estado actual.
Proyecta objetivos probables y fechas de entrega en el tiempo basándose en el
progreso obtenido hasta la fecha (si fuera necesario).
� El grupo completo colabora acerca de qué hacer a continuación, de modo que
la Revisión del Sprint proporcione información de entrada valiosa para
Reuniones de Planificación de Sprints subsiguiente.
� Revisión de cómo el mercado o el uso potencial del producto podría haber
cambiado lo que es de más valor para hacer a continuación.
� Revisión de la línea de tiempo, presupuesto, capacidades potenciales y
mercado para las próximas entregas de funcionalidad o capacidad prevista del
producto.
Sprint Retrospective
� La Retrospectiva de 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.
� La Retrospectiva de Sprint tiene lugar después de la Revisión de Sprint y antes
de la siguiente Planificación de Sprint.
� Se trata de una reunión de, a lo sumo, tres horas para Sprints de un mes.
El propósito de la Retrospectiva de Sprint es:
� Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones,

procesos y herramientas.
� Identificar y ordenar los elementos más importantes que salieron bien y las
posibles mejoras.
� Crear un plan para implementar las mejoras a la forma en la que el Equipo
Scrum desempeña su trabajo.
Sprint
Retrospective
Las 5 Etapas de una Retrospectiva
The 5 stages
of a retrospective
Close
Action
Insights
Gather 5
data 4
Open 3
2
1
Artefactos

Los artefactos de Scrum representan trabajo o valor en diversas formas que son
útiles para proporcionar transparencia y oportunidades para la inspección y
adaptación.
Los artefactos definidos por Scrum están diseñados específicamente para
maximizar la transparencia de la información clave, necesaria para asegurar que
todos tengan el mismo entendimiento del artefacto.
� Product Backlog
� Sprint Backlog
� Incremento del producto
Product Backlog
� La Lista de Producto es una lista ordenada de todo lo que se conoce que es

necesario en el producto.
� Es la única fuente de requisitos para cualquier cambio a realizarse en el
producto. El Dueño de Producto (Product Owner) es el responsable de la Lista de
Producto, incluyendo su contenido, disponibilidad y ordenación.
� La Lista de Producto es dinámica; cambia constantemente para identificar lo
que el producto necesita para ser adecuado, competitivo y útil
� La Lista de Producto enumera todas las características, funcionalidades,
requisitos, mejoras y correcciones que constituyen cambios a realizarse sobre el
producto para entregas futuras.
Release 1 Release 2
Product Backlog
Refinamiento del Product Backlog
� El refinamiento (refinement) de la Lista de Producto es el acto de añadir detalle,

estimaciones y orden a los elementos de la Lista de Producto.
� Durante el refinamiento de la Lista de Producto, se examinan y revisan sus
elementos.
� El Equipo Scrum decide cómo y cuándo se hace el refinamiento.
� Este usualmente consume no más del 10% de la capacidad del Equipo de
Desarrollo. Sin embargo, los elementos de la Lista de Producto pueden
actualizarse en cualquier momento por el Dueño de Producto o a criterio suyo.
Sprint Estimation
Insert Items
PRIORITY

Refine Items
Deleted Item
Sprint Backlog
� La Lista de Pendientes del Sprint es el conjunto de elementos de la Lista de

Producto seleccionados para el Sprint, más un plan para entregar el Incremento
de producto y conseguir el Objetivo del Sprint.
� La Lista de Pendientes del Sprint es una predicción hecha 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”.
� La Lista de Pendientes del Sprint hace visible todo el trabajo que el Equipo de
Desarrollo identifica como necesario para alcanzar el Objetivo del Sprint.
SPRINT
GOAL

Project Backlog Sprint Planning
Priorización
El Dueño de Producto es una única persona, no un comité.

El Dueño de Producto podría representar los deseos de un comité en la Lista del
Producto, pero aquellos que quieran cambiar la prioridad de un elemento de la
Lista deben hacerlo a través del Dueño de Producto.
Para que el Dueño de Producto pueda hacer bien su trabajo, toda la organización
debe respetar sus decisiones.
Las decisiones del Dueño de Producto se reflejan en el contenido y en la
priorización de la Lista del Producto.
Nadie puede forzar al Equipo de Desarrollo a que trabaje con base en un
conjunto diferente de requisitos.
Product Backlog
Request Priority

1
Product Owner
Seguimiento
Seguimiento del Progreso Hacia los Objetivos

Seguimiento del Progreso del Sprint
Sprint Burn down Chart

120
100
80
Story Points
60
40
20
0
1 2 3 4 5 6 7 8 9
Days
Total Story Points Planned

Total Story Points Actual
Sprint Burn up Chart

120
100
80
Story Points
60
40
20
0
1 2 3 4 5 6 7 8 9
Days
Total Story Points Planned

Total Story Points Actual
Incremento
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.
Al final de un Sprint el nuevo Incremento debe estar “Terminado”.
Un incremento es un cuerpo de trabajo inspeccionable y terminado que respalda
el empirismo al final del Sprint.
El incremento debe estar en condiciones de utilizarse sin importar si el Dueño de
Producto decide liberarlo o no.
Product
Product Backlog Increment
SCRUM
SCRUM
MASTER
PROFESSIONAL
CERTIFICATE
(SMPC)
VERSION 04 - 2018
www.certiprof.com

Basic Student Material For CertiProf Scrum Master Professional Certificate Espanol V42018A PDF

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

Basic Student Material For CertiProf Scrum Master Professional Certificate Espanol V42018A PDF

Cargado por

Copyright:

Formatos disponibles

SCRUM

Preséntese en el siguiente formato:

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

El manifiesto Ágil está conformado por 12 principios asociados a 4 aspectos o

Aspectos o Pilares del Maniﬁesto

� A los individuos y su interacción, por encima de los procesos y las herramientas.

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Colaboración Respuesta ante

Principios detrás del Maniﬁesto Ágil

� La mayor prioridad es satisfacer al cliente a través de la entrega temprana y

Sa�sfacción Cambio a los

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Construir los proyectos Trabajo conjunto

� El software funcionando es la medida de progreso.

El so�ware Los procesos ágiles

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Equipos La simplicidad es arte

La Declaración de interdependencia en la gestión de proyectos fue escrita a

[©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair

Los 6 valores Declaración de interdependencia

1. Aumentamos el retorno de inversión, al enfocarnos en el flujo continuo de

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

“Agilidad es la capacidad de crear y responder al cambio con el fin de obtener

“La agilidad es la capacidad de equilibrar la flexibilidad y estabilidad”.

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

¿Cómo debemos ver a la agilidad?

La gestión de proyectos Agile especialmente, implica la adaptabilidad durante la

¿Por qué metodologías ágiles?

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Gestión de Proyectos tradicional

Requirements Ventajas: Orden Lógico

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Scrum es un marco de trabajo de adaptación iterativa e incremental, rápido,

Scrum fue desarrollado inicialmente para gestionar y desarrollar productos.

Scrum se ha usado para desarrollar software, hardware, software embebido,

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Scrum demostró ser especialmente efectivo en la transferencia iterativa e

Scrum se basa en la teoría de control de procesos empírica o empirismo.

El empirismo asegura que el conocimiento procede de la experiencia y de tomar

Scrum emplea un enfoque iterativo e incremental para optimizar la

Tres pilares de Scrum

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Los aspectos significativos del

Los usuarios de Scrum deben

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Uno de los tres pilares del control del

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Los Valores de Scrum

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

La esencia de Scrum es un pequeño equipo de personas. El equipo individual es

Cuando las palabras “desarrollar” y “desarrollo” se usan en la Guía de Scrum se

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Un conjunto cohesivo de responsabilidades que pueden ser cumplidas por una o

El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

El Product Owner (PO) representa la voz del cliente, y es el encargado de

• Un PO siempre debe mantener una visión dual.

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Responsabilidades del Product Owner

Determinar las Ayudar en la Asegurar los

Centrarse en la Evaluar la viabilidad Representar al

Ayudar en la elección Responsable por la Ayudar a crear y a

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)