Scrum Master Datalaticaec- Guia para certificado

CursoOnline
Certificación
SCRUM
Dataliticaec 2020

Dataliticaec
En Dataliticaec somos expertos en manejo y visualización de
datos. Obtenemos información! No datos!. Somos expertos en
Optimización de Operaciones usando metodologías como Lean
Six Sigma y Modelos de Optimización
Nuestro Expertiz
• Manejo de Datos
• Análisis de datos
• Visualización de Datos
• Inteligencia de Negocios (BI)
• Gestión y Manejo de Información (DMS)
• Cadena de Suministro
• Lean Manufacturing / Six Sigma
• Optimización de Operaciones
• Gestión de Procesos
• Gestión de Proyectos
2

3
CERTIFICACIÓN SCRUM
MÓDULO 1
• Introducción a
Marcos de trabajo
• Kanban
• XP
• TDD
• DSDM
• Crystal
• Diferencias
Cascada- Agile
• Quees Agilidad
MÓDULO 2
• Valores Manifiesto
Agile
• Principios
Manifiesto Agile
• Contexto y teoría
Scrum
• Pilares Scrum
• Valores Scrum
• Mejora Continua
MÓDULO 3
• Flujo marco de
trabajo
• Scrum Roles y
responsabilidades
• Scrum Team
• Scrum Master
• Product Owner
• Stakeholder

4
CERTIFICACIÓN SCRUM
MÓDULO 4
• Eventos Scrum
• Sprint Sprint
• Planning meeting
• Daily Scrum
• Sprint Review
• Sprint
Retrospective
MÓDULO 5
• Artefactos Scrum
• Product Backlog
• Product Backlog
• Refinement Sprint
• Backlog
Increment
• Sprint Goal
• DOD
MÓDULO 6
• Examen de
Certificación

Nivel de Complejidad Proyectos
• Proyecto simple: Se conocen
todos los elementos (llave de un
auto)
• Complejo: No se tiene el
conocimiento completo pero es
previsible el determinar las
características (Tráfico)
• Caótico: No se tiene conocimiento
ni predictibilidad (Movilidad de
una ciudad)
5

Tipos de Proyectos
• 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.
6

CASCADA VS ÁGIL
CASCADA
• Documentación compleja
• Las fases se completan una a una,
sin traslapar
• Requisitos bien pensados
• Fecha de entrega fija
• Equipos grandes
7
ÁGIL
• Permite hacer cambios después de
la fase de planeación
• Entregas incrementales
• Flexible, negociable, justo a
tiempo
• Equipos más pequeños

MARCOS DE TRABAJO ÁGIL
CRYSTAL
• Se enfoca en seis aspectos principales:
personas, interacción, comunidad,
comunicación, habilidades y talentos.
• El proceso se considera secundario. Los
métodos son muy flexibles y evitan procesos
rígidos debido a que están centrados en la
gente.
• Hay siete propiedades comunes en Crystal
que indican una mayor posibilidad de éxito y
que incluyen:
• La entrega frecuente
• La mejora de la reflexión
• La comunicación osmótica
• Un fácil acceso a los usuarios expertos
9

Programación Extrema (XP)
Es un método para equipos pequeños y medianos. XP
propone 12 prácticas (reglas) que tienen como objetivo
reducir el costo del cambio y están agrupados en las
siguientes 4 categorías:
• Retroalimentación.
• Proceso continuo en lugar de por bloques.
• Propiedad intelectual compartida.
• Entendimiento compartido.
Esta basada en prueba y error por lo que enumera las
siguientes actividades en ciclo continuo
• Planificar
• Diseñar
• Codificar
• Hacer pruebas
• Escuchar
10

Desarrollo Dirigido por Características (FDD)
• El Desarrollo Dirigido por Características se
basa en ciclos de vida cortos, iterativos,
basados en características.
1. Se debe hacer un modelo general del
sistema con una lista de características
informales y notas sobre alternativas.
2. Construir una lista categorizada de
características.
3. Elaborar un plan de desarrollo teniendo
en cuenta la lista categorizada de
características
4. Inicia un ciclo iterativo de diseño y
construcción
11

Desarrollo Dirigido por Pruebas (TDD)
• Es un modelo de desarrollo rápido de
software que se basa fundamentalmente en
dos prácticas de la ingeniería del software:
1. Pruebas unitarias de cada requerimiento
funcional del software
2. Refactorización
La refactorización del código fuente se refiere
a la reestructuración, modificación o limpieza
del código fuente sin afectar su
comportamiento.
12

Método de Desarrollo de Sistemas Dinámicos (DSDM)
El Método de Desarrollo de Sistemas Dinámicos
(DSDM) consta de seis etapas:
1. Pre-proyecto
2. Estudio de Factibilidad
3. Estudio de Negocios
4. Iteración de Modelos Funcionales
5. Iteración de Diseño y Construcción
6. Implementación y Postproyecto.
Su principio fundamental es el siguiente:
• En lugar de fijar la cantidad de funcionalidad en un
producto y luego ajustar el tiempo y los recursos
para llegar a esa funcionalidad, se prefiere fijar el
tiempo y los recursos para después ajustar la
cantidad de funcionalidad que puede incluirse.
13

Kanban
• Es un método visual que permite
conocer y gestionar el estado de las
tareas.
• Hay que crear un tablero visible y
accesible para todos los miembros del
equipo.
• En las columnas se anotará el estado de
las tareas, incluyendo todos los estados
de las tareas que existan desde su
comienzo hasta su finalización.
14
Tablero Kanban. Recuperado de https://beagilemyfriend.com/kanban/

AGILIDAD
Agilidad es la capacidad de crear y responder al cambio con el fin de obtener
ganancias en un entorno empresarial turbulento.
• La forma correcta de adoptar ágil es de izquierda a derecha
15
Pensamiento Ágil, Imagen recuperada de http://www.gazafatonarioit.com/2020/04/diez-comportamientos-atipicos-en-agil-
y.html

¿Por qué Metodologías Ágiles?
• Retorno de inversión temprano y mensurable a través
de la entrega definida e iterativa de incrementos del
producto
• Alta visibilidad del progreso del proyecto, que permite
identificar y resolver o supervisar los problemas en
forma temprana
• Participación continua del cliente a lo largo del ciclo de
desarrollo del producto
• Mayor autonomía para que el responsable del negocio
tome las decisiones necesarias para alcanzar las metas
• Adaptación a necesidades cambiantes del negocio, lo
que da una mayor influencia sobre los cambios de
requerimientos
• Menos derroches en el producto y en el proceso
Fuente: PMI
17

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.
Está conformado por 12 principios asociados a 4 aspectos o pilares.
“El movimiento ágil no es anti-metodología, de hecho, muchos de nosotros queremos devolverle credibilidad a la
palabra metodología. Queremos restablecer el equilibrio. Adoptamos el modelado, pero no para archivar algún
diagrama en un repositorio corporativo polvoriento. Aceptamos la documentación, pero no cientos de páginas de
tomos que nunca se mantienen y que rara vez se usan. Planificamos, pero reconocemos los límites de la
planificación en un entorno turbulento. Aquellos que calificarían a los defensores de XP o SCRUM o cualquiera de las
otras metodologías ágiles como "hackers" ignoran tanto las metodologías como la definición original del término
hacker”
https://agilemanifesto.org/iso/es/manifesto.html
18

MANIFIESTO ÁGIL
Pilares
• 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.
19

MANIFIESTO ÁGIL
Principios
20
• 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.

MANIFIESTO ÁGIL
Principios
21
• 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.

MANIFIESTO ÁGIL
Principios
22
• 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.

MANIFIESTO ÁGIL
Principios
23
• 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

MANIFIESTO ÁGIL
Declaración de Interdependencia en la gestión de proyectos
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.
“Se denomino declaración de interdependencia ya
que se basa en que los miembros del equipo son
parte de un todo interdependiente y no un grupo
de personas ajenas, esto para poder tener éxito en
la conclusión del proyecto”
24

MANIFIESTO ÁGIL
Declaración de Interdependencia en la gestión de proyectos
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.
25
Resultados
Fiables
Aumentar ROI
Anticipación
y Adaptación
Creatividad e
Innovación
Mejorar
eficacia y
fiabilidad
Aumentar
Rendimiento

SCRUM
¿Qué es Scrum?
Es un marco de trabajo que ayuda a las personas, equipos y organizaciones a generar valor a través
de soluciones adaptables para problemas complejos.
Scrum es:
• Ligero.
• Fácil de entender.
• Extremadamente difícil de llegar a dominar.
En lugar de proporcionar a las personas instrucciones detalladas, las reglas de Scrum guían sus
relaciones e interacciones.
26

SCRUM
¿Qué es Scrum?
27
En pocas palabras, Scrum requiere un Scrum Master para fomentar un entorno donde:

SCRUM
Teoría de Scrum
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
previsibilidad y el control del riesgo.
28

SCRUM
Pilares Scrum
29
Transparencia
El proceso y el trabajo emergentes deben ser
visibles para aquellos que realizan el trabajo,
así como para los que reciben el trabajo. Con
Scrum, las decisiones importantes se basan en
el estado percibido de sus tres artefactos
formales. Los artefactos que tienen poca
transparencia pueden conducir a decisiones
que disminuyen el valor y aumentan el riesgo.
• La transparencia permite la inspección. La inspección
sin transparencia es engañosa y derrochada.

SCRUM
Pilares Scrum
30
Inspección
Los artefactos de Scrum y el progreso hacia
objetivos acordados deben ser
inspeccionados con frecuencia y
diligentemente para detectar varianzas o
problemas potencialmente indeseables.
Su inspección no debe ser tan frecuente
como para que interfiera en el trabajo.
• La inspección permite la adaptación. La inspección
sin adaptación se considera inútil.

SCRUM
Pilares Scrum
31
Adaptación
Si algún aspecto de un proceso se desvía fuera de
los límites aceptables o si el producto resultante
es inaceptable, el proceso que se está aplicando o
los materiales que se producen deben ajustarse.
El ajuste debe realizarse lo antes posible para
minimizar la desviación adicional.
• La adaptación se vuelve más difícil cuando las personas
involucradas no están empoderadas o no poseen
capacidad para autogestionarse.

MEJORA CONTINUA
Paso 1. Inspeccionar: Hacemos nuestro mejor
esfuerzo para comprender el estado actual del
proyecto con nuestro nivel actual de conocimiento
y comprensión al respecto.
Paso 2. Adaptar: Definimos una dirección y visión
sobre los próximos pasos de nuestro proyecto y
luego elaboramos estrategias y ejecutamos
nuestra visión.
Paso 3. Aprender: Observamos, aprendemos y
enseñamos cuidadosamente unos a otros
mientras lo hacemos. Registramos continuamente
lo que funciona y lo que no funciona mientras
hacemos nuestro trabajo.
Paso 4. Reiniciar: comience de nuevo desde el
Paso 1. 32
Según la norma ISO 9000 la definición de mejora continua es la actividad recurrente para mejorar el desempeño

SCRUM
Mejora Continua
33
¿Cómo podemos hacer mejor lo que
trabajamos?
¿Que cambios podemos hacer en la
forma como realizamos el trabajo?
¿Cual es nuestro principal riesgo?

MARCO DE TRABAJO SCRUM
Flujo de trabajo
35

ROLES SCRUM
SCRUM TEAM
• El Scrum Team consiste en un Product Owner,
Desarrolladores y un Scrum Master.
• El Scrum Team es autoorganizado y multifuncional.
• Dentro de un equipo Scrum no hay sub-equipos ni
jerarquías
• El modelo de equipo en Scrum está diseñado para
optimizar la flexibilidad, la creatividad y la
productividad.
• El Scrum Team es lo suficientemente pequeño como
para seguir siendo ágil y lo suficientemente grande
como para completar un trabajo significativo dentro de
un Sprint (10 o menos)
• Todo el equipo de Scrum es responsable de crear un
incremento valioso y útil en cada Sprint
• Trabajar en Sprints a un ritmo sostenible mejora el
enfoque y la consistencia del equipo de Scrum.
36

ROLES SCRUM
MODELO TUCKMAN
37
Recuperado de https://recursoshumanos89.wordpress.com/2016/09/01/el-trabajo-en-equipo-modelo-tuckman/

ROLES SCRUM
DESARROLLADORES
38
Los Desarrolladores son 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.
La organización es la encargada de
estructurar y empoderar a los
desarrolladores para que estos organicen y
gestionen su propio trabajo.

ROLES SCRUM
DESARROLLADORES
39
Las habilidades específicas que necesitan los
desarrolladores son a menudo amplias y
variarán con el dominio del trabajo. Sin
embargo, los desarrolladores siempre son
responsables de:

ROLES SCRUM
Responsabilidades de los Desarrolladores
40

ROLES SCRUM
Responsabilidades de los Desarrolladores
41

ROLES SCRUM
PRODUCT OWNER
• El Product Owner (PO) representa la voz del
cliente, y es el encargado de maximizar el
valor del producto.
• El Dueño de Producto es la única persona
responsable de gestionar la Lista del
Producto (Product Backlog)
• El debe entender y apoyar las necesidades e
intereses de todos los Stakeholders.
• Comprende las necesidades y el
funcionamiento de los desarrolladores.
42

ROLES SCRUM
Responsabilidades del Product Owner
43

ROLES SCRUM
Responsabilidades del Product Owner
44

ROLES SCRUM
SCRUM MASTER
45
• El Scrum Master es responsable de promover y
apoyar Scrum como se define en la Guía de
Scrum. Lo consigue ayudando a todos a
comprender la teoría y la práctica de Scrum, tanto
dentro del Equipo como en toda la organización.
• Los Scrum Masters son verdaderos líderes que
sirven al equipo Scrum y a toda la organización.
• El Scrum Master ayuda a todos a modificar las
interacciones para maximizar el valor creado por
el Scrum Team.

ROLES SCRUM
Responsabilidades Scrum Master con el Equipo Scrum
46

ROLES SCRUM
Responsabilidades Scrum Master con el Product Owner
47

ROLES SCRUM
Responsabilidades Scrum Master con la Organización
48

ROLES SCRUM
SCRUM MASTER
49
• Líder de servicio cuyo enfoque está en las necesidades de los
miembros del equipo y aquellos a quienes sirven (el cliente), con el
objetivo de lograr resultados acordes con los valores, principios,
objetivos comerciales.
• Facilitador preparando el escenario y proporcionando límites claros
en los que el equipo puede colaborar.
• Entrenador que entrena al individuo con un enfoque en la
mentalidad y el comportamiento, de la mejora continua y logrando
una verdadera colaboración con el Scrum Team.
• Navegador de conflictos para abordar actitudes improductivas y
comportamientos disfuncionales.
• Gerente responsable de gestionar impedimentos, eliminar
desperdicios, gestionar el proceso, gestionar la salud del equipo,
gestionar los límites de la autoorganización y gestionar la cultura.
• Mentor que transfiere conocimientos y experiencias ágiles al
equipo.
• Maestro para asegurar que Scrum y otros métodos relevantes sean
entendidos y promulgados.

Stakeholders
Persona, grupo u organización que afecta o
puede verse afectado por las acciones de
una organización.
Se divide en:
• Cliente
• Usuario
• Patrocinador
50

PIRAMIDE DE MASLOW
Esta pirámide diseñada por el psicólogo estadounidense Abraham Maslow, muestra las necesidades
de las que se ocupan primero los seres humanos y luego las que se vuelven mas apremiantes una vez
satisfechas las inferiores.
Los individuos que llegan alto en esta pirámide no solo son más felices sino también más eficientes e
innovadores.
52

EVENTOS SCRUM
Time-Boxing
53
Todos los eventos son bloques de tiempo (duración máxima de tiempo), de tal modo que
todos tienen una duración máxima.

EVENTOS SCRUM
SPRINT
54
Los Sprint son ciclos de trabajo o para
desarrollar incrementos de servicios o
productos de Software.
También se denominan iteraciones
Este termina una vez su Time-box acaba,
así es que una vez que comienza un
Sprint, su duración es fija y no puede
acortarse o alargarse

EVENTOS SCRUM
SPRINT
55
Durante el Sprint:
● No se hacen cambios que pongan en peligro el
Objetivo Sprint
● La calidad no disminuye
● El trabajo pendiente del producto se refina
según sea necesario
● El alcance se puede clarificar y renegociar con
el Propietario del Producto a medida que se
aprende más.

EVENTOS SCRUM
SPRINT
56
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.

EVENTOS SCRUM
Sprint Planning Meeting
57
Durante la reunión de planificación del
Sprint, el equipo Scrum decide qué y cuántos
requisitos implementarán, se construye
sprint backlog viable, que determina las
historias de usuario y las tareas que el
equipo presentará hasta el final de este
Sprint (Incremento de producto).

EVENTOS SCRUM
58
• Se debe planificar solo lo necesario, no es útil proyectar todo con años de anticipación.
• No se debe evaluar en términos absolutos, como seres humanos no somos bueno calculando.
• Se debe pensar en el trabajo como historias (Quién recibirá valor, qué es y por qué lo necesita), los
humanos pensamos en forma de relatos.
• Una vez se conoce la velocidad del equipo es posible saber cuando se llegará a la meta.

CONCEPTOS CLAVES
59
Es una representación de un requisito del usuario en forma escrita, de una o dos frases, utilizando el lenguaje
común del usuario.
Tienen 3 elementos importantes o las 3 C
Card (Tarjeta), Conversation (Conversación), Confirmation (Criterios de aceptación)
HISTORIA DE USUARIO UH

CONCEPTOS CLAVES
60
Cada historia de usuario debe cumplir con el siguiente modelo en su definición
HISTORIA DE USUARIO
IN
VE
ST
INDEPENDIENTE
NEGOCIABLE
VALIOSA
ESTIMABLE
PEQUEÑA
VERIFICABLE

CONCEPTOS CLAVES
61
• Son frases cortas de las condiciones que se deben cumplir para que la historia sea aceptada
• Hacen posible un mejor entendimiento de lo que quiere el cliente y realizar los casos de prueba para el QA
CRITERIOS DE ACEPTACIÓN

CONCEPTOS CLAVES
62
ÉPICA
Una épica es una historia de usuario que no puede ser entregada tal y como se ha
definido dentro de una sola iteración, o que es suficientemente grande como para
ser partida en historias de usuario más pequeñas.

CONCEPTOS CLAVES
63
STORY POINTS
Esta estimación debe realizarse pensando en la dificultad, esfuerzo o incertidumbre que represente
cada historia de usuario, esto se realiza para saber con cuanto puede comprometerse un equipo en
un sprint. (Velocidad del equipo)
Para realizar esta medición es necesario o recomendable que se tenga una historia de usuario pivot
que todo el equipo conozca. (unidad de medida)
Recuperada de https://tech.xing.com/when-story-points-misfire-88b068bfc97c

CONCEPTOS CLAVES
64
PLANNING POKER
Esta es una de las técnicas más reconocidas en Scrum, ya que es muy sencilla, divertida y eficaz,
donde los desarrolladores estiman como grupo el esfuerzo a realizar en el Sprint.
Recuperado de https://agilestationery.co.uk/products/estimation-cards-planning-poker

CONCEPTOS CLAVES
65
PLANNING POKER ¿Cómo Jugar?
1. Cada integrante del Equipo posee en sus manos una baraja de cartas
con los números correspondientes a la sucesión de Fibonacci
2. El Product Owner presenta una historia de usuario para ser
estimada, realizando la descripción correspondiente y si hay dudas
se resuelven
3. Todos los participantes proceden a realizar su estimación en forma
secreta, sin influenciar al resto del Equipo, poniendo su carta elegida
boca abajo sobre la mesa. (poker face)
4. Una vez que todos los integrantes han estimado, se dan vuelta las
cartas y se discuten principalmente los extremos, para conocer la
razón de la diferencia
5. Al finalizar la discusión se levantan las cartas y se vuelve a estimar,
esta vez con mayor información que la que se tenía previamente (par
este punto ya las estimaciones deben ser muy parecidas.
6. Las rondas siguen hasta que se logra consenso en el Equipo y luego
se continúa desde el punto número uno con una nueva historia de
usuario
Recuperado de https://agilestationery.co.uk/products/estimation-cards-planning-poker

CONCEPTOS CLAVES
66
Los ítems del backlog de producto, deben guardar un orden de prioridad, basado en:
• Beneficios de implementar una funcionalidad
• Pérdida o costo que demande posponer la implementación de una funcionalidad
• Riesgos de implementarla
• Coherencia con los intereses del negocio y del cliente
PRIORIZACIÓN HISTORIAS DE USUARIO

CONCEPTOS CLAVES
67
PRIORIZACIÓN HISTORIAS DE USUARIO
TÉCNICA MoSCoW
TÉCNICA MATRICES
NOVEDAD/IMPACTO
CRITICIDAD/INCERTIDUMBRE

EVENTOS SCRUM
Daily Standup Meeting o Daily Scrum
68
• Time - box de 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 equipo
mantenga Ia reunión, pero son los
desarrolladores los responsables de dirigir el
Scrum Diario.

EVENTOS SCRUM
Sprint Review Meeting
69
Al final del Sprint se lleva a cabo una
Revisión de Sprint para inspeccionar el
Incremento y adaptar la Lista de Producto si
fuese necesario. Durante la Revisión de
Sprint, el Equipo Scrum y los interesados
colaboran acerca de lo que se hizo durante
el Sprint.
Se trata de una reunión de, a lo sumo, cuatro
horas para Sprints de un mes. Para Sprints
más cortos, el evento usualmente más corto.

EVENTOS SCRUM
Sprint Review Meeting
70
• 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 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)
• 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

EVENTOS SCRUM
Sprint Retrospective
71
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.
Para el final de la Retrospectiva de Sprint el Equipo
Scrum debería haber identificado mejoras que
implementará en el próximo Sprint.
Se trata de una reunión de, a lo sumo, tres horas para
Sprint de un mes.

EVENTOS SCRUM
72
PREPARAR EL MOMENTO: Analizar al
equipo, realizar alguna dinámica para
que todos participen y despertar la
creatividad.
RECOLECTAR DATOS: Pensar un futuro
ideal.
REFLEXIONAR: Detectar que hace falta
para lograrlo.
DECIDIR QUE HACER: Acción de mejora
para lo identificado (Se debe escoger lo
más significativo máximo dos).
CIERRE: Generar los compromisos y
actividades para lograr la mejora.

ARTEFACTOS SCRUM
PRODUCT BACKLOG
73
• 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.
• Es dinámico; cambia constantemente para
identificar lo que el producto necesita para ser
adecuado, competitivo y útil.
• Enumera todas las características,
funcionalidades, requisitos, mejoras y
correcciones que constituyen cambios a realizarse
sobre el producto para entregas futuras.

ARTEFACTOS SCRUM
PRODUCT BACKLOG REFINEMENT
74
• 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.
• Los elementos de la Lista de Producto de orden
más alto son generalmente más claros y
detallados que los de menor orden.
• Este usualmente consume no más del 10% de la
capacidad del equipo. Sin embargo, los
elementos del Product Backlog pueden
actualizarse en cualquier momento por el criterio
del Product Owner.
• DEEP(Detailed appropiately, estimated, emergent
and prioritized).

COMPROMISO
Objetivo del producto
75
• El objetivo del producto describe un estado futuro
del producto que puede servir como objetivo para
el equipo de Scrum contra el cual planificar
• El objetivo del producto se encuentra en el trabajo
pendiente del producto.

ARTEFACTOS SCRUM
SPRINT BACKLOG
76
• 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 del Sprint hace visible todo
el trabajo que los desarrolladores identifican
como necesario para alcanzar el Sprint Goal.
• Solo el Equipo de Desarrollo puede cambiar
su Lista de Pendientes del Sprint durante un
Sprint.

COMPROMISO
SPRINT GOAL
77
• El Sprint Goal es una meta establecida
para el Sprint que puede lograrse
mediante la implementación del Product
Backlog.
• El Sprint Goal brinda a los desarrolladores
cierta flexibilidad con respecto a la
funcionalidad implementada en el Sprint.
• El Sprint Goal crea coherencia y enfoque
animando al equipo de Scrum a trabajar
juntos en lugar de en iniciativas
separadas.

ARTEFACTOS SCRUM
INCREMENTO
78
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”, lo cual significa que está en
condiciones de ser utilizado y que cumple la
Definición de “Terminado” del Equipo Scrum.

COMPROMISO
Definición of Done (DOD)
79
Los factores que deﬁnen cuando una característica está completa y cuando cumple con los estándares de
calidad requeridos se establecen mediante Deﬁnicion de Terminado.
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 puede variar significativamente para cada
Equipo Scrum, los miembros del equipo deben tener un entendimiento compartido de lo que significa que
el trabajo esté completado para asegurar la transparencia.

SCRUM MASTER
CARACTERISTICAS
81
• El Scrum Master debe ser una persona observadora, lo que
le permitirá identificar con facilidad los impedimentos que
se pueden presentar en cualquier punto del proceso,
buscando una mejora continua.
• Debe ser una persona positiva y con habilidades de
coaching para potenciar las habilidades de cada integrante
del equipo.
• Capacidad para resolver problemas y/o conocimiento de
técnicas para una resolución pronta (Mediador y
comunicación asertiva)
• Es un Líder Servicial

SCRUM MASTER
Scrum Diario (Daily Scrum)
82
• Se asegura de que el evento se lleve a cabo pero
es el Equipo de Desarrollo el responsable de
dirigir el Scrum Diario
• Enseña al Equipo Scrum a mantenerse dentro
del bloque de tiempo
• Actualiza el tablero de tareas (Scrum Taskboard)
• Actualiza la lista de impedimentos
• El Scrum Diario es una reunión interna del
Equipo de Desarrollo. Si otras personas están
presentes, el Scrum Master se asegura de que
no interrumpan la reunión.

SCRUM MASTER
83
• Asegura que el evento se lleve a cabo
• Enseña al Equipo Scrum a mantenerse dentro del
bloque de tiempo
• Asiste al Equipo Scrum en estimar el esfuerzo
necesario para completar las tareas acordadas para
el Sprint
• Asiste al Equipo Scrum en el desarrollo del Sprint
backlog y gestiona el Burndown chart del Sprint

SCRUM MASTER
Sprint Review
84
• Se asegura de que el evento se lleve a cabo
• Enseña al Equipo Scrum a mantenerse dentro del
bloque de tiempo
• Facilita la presentación de los Entregables por el
Equipo Scrum para la aprobación del Product
Owner y stakeholders

SCRUM MASTER
85
• Se asegura de que el evento se lleve a cabo
• Enseña al Equipo Scrum a mantenerse dentro
del bloque de tiempo
• Participa como un miembro más del equipo
Scrum en busca de mejoras
• El Scrum Master se asegura de que la reunión
sea positiva y productiva
• Alienta al equipo para que mejore, dentro del
marco de proceso Scrum, su proceso de
desarrollo y sus prácticas para hacerlos más
efectivos y amenos para el siguiente Sprint.

SCRUM MASTER
Tablero de Tareas
86
Con el fin de facilitar la Transparencia y la gestión de las tareas, es posible que se use un tablero dividido con
los diferentes status tal como lo indica la metodología Kanban.
La exposición de las tareas facilita la detección temprana de problemas al monitorizar continuamente la
evolución del proyecto.

SEGUIMIENTO
BURNDOWN CHART
87
El "Scrum Burndown Chart" es una herramienta de medición visual que muestra el trabajo
completado por Sprint contra la tasa de finalización proyectada para la versión actual del
proyecto.
Mide La velocidad / tasa de progreso de un equipo Scrum es decir, expresa el número total de
puntos de historia completados que el equipo Scrum entrega por Sprint.
La estrategia ágil para el
seguimiento del proyecto se
basa en: Medir el trabajo que
falta, no el realizado.

SEGUIMIENTO
BURNUP CHART
88
• El gráfico de producto o gráfico “burn up”
es una herramienta de planificación
propia del product owner, que presenta
visualmente la evolución del producto.
• Proyecta en el tiempo la construcción del
producto, en base a la velocidad del
equipo.
• En el eje X se grafica el esfuerzo estimado
para construir las diferentes historias de
la pila del producto, y en el eje Y el
tiempo medido en sprints. Recuperada de https://www.scrummanager.net/bok/index.php/Gr%C3%A1fico_de_producto

Scrum Master Datalaticaec- Guia para certificado

Más contenido relacionado

Similar a Scrum Master Datalaticaec- Guia para certificado

Último

Scrum Master Datalaticaec- Guia para certificado