Material Estudiantes - ScrumMaster (18082019) SP

SCRUM MASTER
PROFESSIONAL CERTIFICATE
(SMPC)
O NAL CER
S SI TI
FI
FE
CA
PRO
TE
SCRUM MASTER
(SMPC) VERSIÓN 022019
SMPC
Objetivos
●● Alcance, propósito, términos y definiciones claves para Scrum Master Professional Certificate
(SMPC) y cómo puede ser utilizado.
●● Certificación profesional.
¿Quién es CertiProf®?
CertiProf® ofrece una amplia gama de certificados profesionales para personas y empresas. Nuestra
misión es preparar a los profesionales de la más alta calidad reconocidos a nivel internacional.
Con un equipo internacional que se especializa en la implementación de material, nuestro instituto es

uno de los proveedores líderes que no solo brinda educación excepcional en el mercado de los EE.UU.,
sino que también se está expandiendo a las regiones de América Latina.
Potenciamos a las personas y las ayudamos a alcanzar su nivel óptimo al proporcionarles las herramientas
y capacitación necesaria para aumentar su desempeño, habilidades y mejorar su desarrollo profesional.
¿Quién debe atender este taller de certificación?
Cualquier persona que esté interesada en ampliar sus conocimientos en Scrum Master.
Presentación y Logística
¡Bienvenido!
Preséntese en el siguiente formato:
SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)
●● Nombre.
●● Empresa.
●● Cargo y experiencia.
●● Familiaridad con los conceptos y la práctica de Scrum.
●● Expectativas de este curso.
©2019 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.
2
Agenda
Introducción 5
Tipos de Proyectos 6
Manifiesto Ágil 6
Aspectos o Pilares del Manifiesto 7
Principios Detrás del Manifiesto Ágil 7
Declaración de Interdependencia 9
Los 6 Valores Declaración de Interdependencia 9
¿Qué es Agilidad? 9
¿Cómo debemos ver a la Agilidad? 10
¿Por qué Metodologías Ágiles? 10
Gestión de Proyectos Tradicional 10
¿Qué es Scrum? 11
Usos de Scrum 11
Teoría de Scrum 12
Iterativo 13
Tres Pilares de Scrum 13
Transparencia 14
Inspección 14
Adaptación 14
Los Valores de Scrum 15
La Esencia de Scrum 16
Roles 17
Scrum Team 18
Product Owner 18

Responsabilidades del Product Owner 19
Características de un Product Owner 20
Responsabilidades del Scrum Master con el Product Owner 21
Responsabilidades del Scrum Master con la Organización 21
Responsabilides del Scrum Master con el Development Team 22
Development Team 22
Responsabilidades del Development Team 23
Características Development Team 24
Stakeholders 24
Stakeholders se Dividen en: 24
3
Conceptos Clave 26
Nivel de Detalle 28
¿Cómo está conformada una User Story? 28
Estructura de User Story 29
Task 29
¿Cómo está conformada una Task? 30
Definición de Done 30
Time-Boxing 31
Ventajas de Time-Boxing 31
¿Dónde se utilizan los Time-Boxing? 32
Eventos Formales 32
Sprint 33
Cancelación de un Sprint 34
Reuniones o Ceremonias de Scrum 34
Reunión Diaria (Daily Sprint) 35
Sprint Planning Meeting 36
¿Qué puede ser terminado? 36
Sprint Goal 37
¿Cómo se conseguirá completar el trabajo seleccionado? 37
Estimación Planning Póker 37
Sprint Review Meeting 38
Sprint Retrospective 39
Las 5 Etapas de una Retrospectiva 39
Artefactos 40
Product Backlog 40
Refinamiento del Product Backlog 41
Sprint Backlog 41
Priorización 42
Seguimiento 42
Increment 43
4
Introdução
Introducción
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.
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
6
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.

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.
7
●● 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.
8
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 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.
¿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”
9
¿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.
¿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.
Gestión de Proyectos Tradicional

Ventajas: Orden lógico.
Desventaja: Asume predictibilidad.

10
¿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.
11
Teoria do Scrum
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.
Tres Pilares de Scrum
●● Transparencia.
●● Inspección.
●● Adaptación.
13
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.
Adaptación
Uno de los tres pilares del control del proceso

empírico; la retroalimentación se usa para
hacer un ajuste alproducto de trabajo que se
estádesarrollando o al proceso por el cual se está
desarrollando.
14
Los Valores de Scrum
●● Compromiso.
●● Coraje.
●● Foco.
●● Apertura.
●● Respeto.
Los miembros del Scrum Team aprenden y exploran estos valores a medida que trabajan en los eventos,
roles y artefactos de Scrum.
15
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 “develop” y “development” se usan en la Guía de Scrum se esta haciendo referencia
a trabajo complejo, tales como estos identificados anteriormente.
16
Papéis
Roles
Roles
Un conjunto cohesivo de responsabilidades que

pueden ser cumplidas por una o más personas.
Los tres roles de Scrum son Product Owner,
Scrum Master, y Development Team.
Scrum Team
●● El Scrum Team consiste en un Product Owner,

el Development Team y un Scrum Master.
●● El Scrum Team son autoorganizados y
multifuncionales.
●● El modelo de equipo en Scrum está diseñado
para optimizar la flexibilidad, la creatividad y la
productividad.
●● El Scrum Team ha demostrado ser cada vez más efectivo para todos los usos anteriores y cualquier
trabajo complejo.
●● El Scrum Team entregan productos de forma iterativa e incremental, maximizando las
oportunidades de obtener retroalimentación. Las entregas incrementales del producto “Done”
aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.
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.
18
Responsabilidades del Product Owner
19
Características de un Product Owner
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 Scrum Team. El Scrum Master ayuda a las
personas externas al Scrum Team a entender
qué interacciones con el Scrum Team pueden
ser útiles y cuáles no.
●● El Scrum Master ayuda a todos a modificar
estas interacciones para maximizar el valor
creado por el Scrum Team.
20
Responsabilidades del Scrum Master con el Product Owner
Responsabilidades del Scrum Master con la Organización
21
Responsabilides del Scrum Master con el Development Team
Development Team
El Development Team consiste en los profesionales que realizan el trabajo de entregar un Incremento
de producto “ Done” que potencialmente se pueda poner en producción al final de cada Sprint. Un
Incremento “Done” es obligatorio en el Sprint Review. Solo los miembros del Development Team
participan en la creación del Incremento. La organización es la encargada de estructurar y empoderar a
los Development Teams para que estos organicen y gestionen su propio trabajo. La sinergia resultante
optimiza la eficiencia y efectividad del Development Team.
El tamaño óptimo del Development Team 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 Development Team
reduce la interacción y resulta en ganancias de
productividad más pequeñas.
Los Development Teams más pequeños podrían

encontrar limitaciones en cuanto a las habilidades
necesarias durante un Sprint, haciendo que el
Development Team 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.
22
Responsabilidades del Development Team
23
Características Development Team
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.
24
25
Principais Conceitos
Conceptos
Claves
27
Conceptos Claves
●● É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énes van a participar.
Nivel de Detalle
¿Cómo está conformada una User Story?
Una historia de usuario debe estar conformada por las 3 C's:
●● Card (tarjeta): Descripción escrita de lo que necesita el usuario.

●● Conversación: El PO y el DT aclaran los detalles.
●● Confirmación: Sirve para determinar lo que se espera.
28
Características: modelo INVEST.
●● Independencia.
●● Negociables.
●● Valiosa.
●● Estimable.
●● Pequeña.
●● Verificable.
Estructura de User Story

Task
En Scrum se puede definir como el trabajo técnico

que realiza el Development Team para completar
un ítem del Product Backlog.
La mayoría de las tareas se definen como

pequeñas, lo que representa no más de unas
pocas horas de un día.
29
¿Cómo está conformada una Task?
Características modelo SMART:
S: Specific (Especifico).
M: Measurable (Medible).
A: Achievable (Alcanzable).
R: Relevant (Relevante).
T: Time-boxed (Bloque de tiempo).
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.
30
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.
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.
31
¿Dónde se utilizan los Time-Boxing?
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).
32
Sprint
33
Cancelación de un Sprint
Un Sprint puede ser cancelado antes de que el Time-Box 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.
Reuniones o Ceremonias de Scrum
Para que cualquier proyecto tenga éxito, la comunicación es importante. Los Scrum Teams emplean
una serie de reuniones clave para estructurar el trabajo del equipo:
●● Daily Standup Meeting.
●● Sprint Planning Meeting.
●● Sprint Review Meeting.
●● Retrospective Sprint Meeting.
34
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
los 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
Development Team mantenga Ia reunión, pero
el Development Team es el responsable de
dirigir el Scrum Diario.
35
Sprint Planning Meeting
¿Qué puede ser terminado?
Esta pregunta nos ayuda para que el Development

Team (DT) trabaje para proyectar la funcionalidad
que se 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).
36
Sprint Goal
●● El Sprint Goal es una meta establecida para el Sprint que puede lograrse mediante la
implementación del Product Backlog.
●● El Sprint Goal brinda al Development Team cierta flexibilidad con respecto a la funcionalidad
implementada en el Sprint.
●● El Sprint Goal puede representar otro nexo de unión que haga que el Development Team trabaje en
conjunto y no en iniciativas separadas.
¿Cómo se conseguirá completar el trabajo Estimación Planning Póker

seleccionado?
Una vez que se ha establecido el Sprint Goal Esta es una de las técnicas más reconocidas en
y seleccionado los elementos del Product Scrum, ya que es muy sencilla, divertida y eficaz,
Backlog para el Sprint, el Development Team donde el Development Team (DT) estima como
decide cómo construirá esta funcionalidad para grupo el esfuerzo a realizar en el Sprint.
formar un Incremento de producto “Done”
durante el Sprint.

Los elementos del Product Backlog seleccionados
para este Sprint, más el plan para terminarlos,
recibe el nombre de Sprint Backlog.
37
Sprint Review Meeting
●● Los asistentes son el Scrum Team y los stakeholders claves invitados por el Product Owner.
●● El Product Owner explica qué elementos del Product Backlog se han “Done” y cuales no se han
“Done”.
●● El Development Team habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecieron
y cómo fueron resueltos esos problemas.
●● El Development Team hace una demostración del trabajo que ha “Done” y responde preguntas
acerca del Incremento.
●● El Product Owner habla acerca del Product Backlog 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 el Sprint Review
proporcione información de entrada valiosa para el subsiguiente Sprint Planning.
●● 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.
38
Sprint Retrospective
●● El Sprint Retrospective es una oportunidad para el Scrum Team de inspeccionarse a sí mismo y de

crear un plan de mejoras que sean abordadas durante el siguiente Sprint.
●● El Sprint Retrospective tiene lugar después del Sprint Review y antes del siguiente Sprint Planning.
●● Se trata de una reunión de, a lo sumo, tres horas para Sprints de un mes.
El propósito del Sprint Retrospective 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 Scrum Team desempeña su
trabajo.
Las 5 Etapas de una Retrospectiva
39
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.
●● Increment.
Product Backlog
●● El Product Backlog 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 Product Owner
es el responsable del Product Backlog, incluyendo su contenido, disponibilidad y ordenación.
●● El Product Backlog es dinámica; cambia constantemente para identificar lo que el producto necesita
para ser adecuado, competitivo y útil.
●● El Product Backlog enumera todas las características, funcionalidades, requisitos, mejoras y
correcciones que constituyen cambios a realizarse sobre el producto para entregas futuras.
40
Refinamiento del Product Backlog
●● El refinamiento (refinement) del Product

Backlog es el acto de añadir detalle,
estimaciones y orden a los elementos del
Product Backlog.
●● Durante el refinamiento del Product Backlog,

se examinan y revisan sus elementos.
●● El Scrum Team decide cómo y cuándo se hace

el refinamiento.
●● Este usualmente consume no más del 10%

de la capacidad del Development Team. Sin
embargo, los elementos del Product Backlog
pueden actualizarse en cualquier momento
por el criterio del Product Owner.
Sprint Backlog
●● El Sprint Backlog es el conjunto de elementos del Product Backlog seleccionados para el Sprint,
más un plan para entregar el Incremento de producto y conseguir el Sprint Goal.
●● El Sprint Backlog es una predicción hecha por el Development Team acerca de qué funcionalidad

formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en
un Incremento “Done”.
●● El Sprint Backlog del Sprint hace visible todo el trabajo que el Development Team identifica como
necesario para alcanzar el Sprint Goal.
41
Priorización
●● El Product Owner es una única persona, no un

comité.
●● El Product Owner podría representar los
deseos de un comité en el Product Backlog,
pero aquellos que quieran cambiar la prioridad
de un elemento de la Lista deben hacerlo a
través el Product Owner.
●● Para que el Product Owner pueda hacer bien
su trabajo, toda la organización debe respetar
sus decisiones.
●● Las decisiones del Product Owner se reflejan
en el contenido y en la priorización del Product
Backlog.
●● Nadie puede forzar al Development Team a
que trabaje con base en un conjunto diferente
de requisitos.
Seguimiento
●● Seguimiento del Progreso Hacia los Objetivos.

●● Seguimiento del Progreso del Sprint.
42
Increment
El Increment es la suma de todos los elementos del Product Backlog completados durante un Sprint y
el valor de los incrementos de todos los Sprints anteriores.
Al final de un Sprint el nuevo Increment debe estar “Done”.
Un Increment es un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo al final

del Sprint.
El Increment debe estar en condiciones de utilizarse sin importar si el Product Owner decide liberarlo
o no.
43
44
Colaboradores en el desarrollo y revisión de
SCRUM MASTER
(SMPC)
Con su ayuda
logramos siempre
resultados extraordinarios.
¡Gracias!
SCRUM MASTER
(SMPC)
Certiprof_llc
www.certiprof.com

Material Estudiantes - ScrumMaster (18082019) SP

Cargado por

Copyright:

Formatos disponibles

Material Estudiantes - ScrumMaster (18082019) SP

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

Material Estudiantes - ScrumMaster (18082019) SP

Cargado por

Copyright:

Formatos disponibles

SCRUM MASTER

Con un equipo internacional que se especializa en la implementación de material, nuestro instituto es

¿Quién debe atender este taller de certificación?

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

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

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

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

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

Los 6 Valores Declaración de Interdependencia

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

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

“La agilidad es la capacidad

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

¿Por qué Metodologías Ágiles?

El 80% de todos los proyectos emplearán Métodos

Casi tres cuartas partes (71%) de las organizaciones

Fuente: Project Management Institute.

Gestión de Proyectos Tradicional

Desventaja: Asume predictibilidad.

Scrum demostró ser especialmente efectivo en la transferencia iterativa e incremental de conocimiento.

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

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

Tres Pilares de Scrum

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Los aspectos significativos del proceso deben ser

La transparencia requiere que dichos aspectos

Los usuarios de Scrum deben inspeccionar

Su inspección no debe ser tan frecuente como

Las inspecciones son más beneficiosas cuando

expertos en el mismo lugar de trabajo.

Uno de los tres pilares del control del proceso

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

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

Un conjunto cohesivo de responsabilidades que

●● El Scrum Team consiste en un Product Owner,

●● Un PO siempre debe mantener una

●● El Scrum Master es responsable de promover

y apoyar Scrum como se define en la Guía de

Responsabilidades del Scrum Master con la Organización

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

Los Development Teams más pequeños podrían

Stakeholders se Dividen en:

●● Usuarios: El usuario es el individuo o la organización que utiliza directamente el producto del

●● Patrocinador: El patrocinador es la persona o la organización que provee recursos y apoyo para el

●● Épicas: Es una historia de usuario que es

●● User Stories: Es una representación de un

●● Task: Es una representación del requisito que

¿Cómo está conformada una User Story?

Una historia de usuario debe estar conformada por las 3 C's:

●● Card (tarjeta): Descripción escrita de lo que necesita el usuario.

Estructura de User Story

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

En Scrum se puede definir como el trabajo técnico

La mayoría de las tareas se definen como

Características modelo SMART:

Time-Boxing es una práctica crítica en Scrum y debe aplicarse con cuidado.

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC)

●● Planificación del Sprint (Sprint Planning).