ROLES Y EVENTOS

SCRUM

2023
 Roles Equipos Scrum
Team Member
Profesionales encargados de construir el
producto o servicio, la pieza de valor. Los
Equipos de Desarrollo son multifuncionales,
contando como equipo con todas las
habilidades necesarias para crear un
Incremento de producto.
Product Owner
Es el responsable del producto y maximizar
el valor del mismo y del trabajo del Equipo
de Desarrollo, es la única persona
responsable de gestionar la Lista del
Producto (Product Backlog).
Scrum Master
Ayuda a todos a entender la teoría,
prácticas, reglas y valores de Scrum, su
objetivo es actuar como facilitador, un
eliminador de impedimentos, un líder que
sirve tanto a la Organización, como al
Equipo Scrum.
Product Manager
El PM es quien tiene clara la estrategia y la
visión del cliente, lo que se quiere lograr.
Prioriza y actualiza el backlog de épicas y
debe tener la mirada integral de todo el
Ecosistema.
 Scrum
El equipo Scrum
7
Scrum
Responsabilidades del Scrum Master
4

1 Actuar como un agente de cambio 4 Entrena al P.O y al equipo

2 Sirve al Product O wner y al equipo 5 Protege al equipo

3 Remueve los impedimentos 6 G uía al equipo

6
8

The Product Owner

Autoridad
Autoridad para decidir sobre lo Q UE
hay que hacer.

Conocimiento
Conocimiento del producto y de las
necesidades del cliente,
Disponibilidad
Debe que estar disponible para
clarificar cualquier duda al equipo y
para entender las necesidades del
cliente.
6
9
Responsabilidades del Product Owner

1 Encamina el éxito del producto 4 Colabora con el equipo

2 Construir un mapa para 5 Colabora con los Stakeholders

desarrollar su visión.

3 C rea y mantiene el Product Backlog 6 Participa en las reuniones del Sprint

7
1
La autoridad del PO sobre el Backlog

Claramente Valor Visible y

Ordenada Entendida
expresada optimizado transparente

Expresar claramente los Ordenar los puntos del Optimizar el valor del Asegurarse de que el Asegurar que el equipo de
puntos del Backlog Product Backlog para trabajo que desempeña Product Backlog sea desarrollo entienda los
alcanzar las metas y las el equipo de desarrollo visible, transparente y puntos del Product
misiones de una mejor del producto. claro para todos, y Backlog al nivel necesario.
manera. mostrar el siguiente
trabajo del equipo Scrum.
Responsabilidades del equipo

Participa en las reuniones del Sprint

Auto organizarse y responsabilizarse
1 4 (Planeación, Revisión, Diaria y
como equipo
Retrospectiva)

2 Entregar un incremento del producto 80Autoridad

• El equipo tiene poder para tomar cualquier

decisión requerida para alcanzar el éxito.

Administra el Sprint Backlog y rastrea el

• El equipo tiene poder para solicitar cualquier
3 recurso que necesite (incluyendo
progreso del Sprint
entrenamiento adicional)
Eventos Scrum ¿qué hice ayer? ¿qué voy a
hacer hoy? ¿Impedimentos?
[Daily]
Reunión diaria de 15 minutos en
[DoR] que participa todo el equipo con
el fin de conocer los avances e
impedimentos. [Daily]
[Planning]
[Refinamiento]
Reunión al principio del sprint [Objetivo]
en la cual participa todo el Reunión al final del sprint en la cual
equipo con el objetivo generar Sprint participa todo el equipo con el objetivo
compromisos que permita la 2 semanas de asegurar el entendimiento de las
entrega del valor. HU.
[Backlog
]
[DoD]
[Review]
[Retrospectiva] [Daily]
Reunión al final del sprint en la cual
Reunión al final del sprint en la cual participa todo el equipo y se
participa todo el equipo con el presenta el incremento generado.
objetivo de identificar oportunidades
mejora o aspecto positivos
 Entregables de cada Evento
[Refinamiento]
Responsable: product owner agendar,
gestionar y dirigir esta reunión.
Entregable: Nivel de granularidad aceptado
por el equipo y prioridad por cada HU.
[Planning]
Responsable: Es organizada y liderada por el
product owner
Entregable: Compromisos del equipo para
el sprint en curso..
[Daily]
Responsable: Equipo Scrum
Entregable: Compromisos para remover
impedimentos o avanzar en la generación de
valor.
[Review]
Responsable: Equipo Scrum y el Scrum Master
garantiza que el evento se realice y que los
participantes comprendan su finalidad
Entregable: incremento terminado para su
inspección y adaptación, correspondientes.
[Retrospectiva]
Responsable: Única persona que guía
(cualquier integrante del equipo Scrum).
Entregable: Plan de acciones de mejora,
mejores prácticas, acuerdos de equipo,
impedimentos a escalar.
 Roles y Eventos Scrum

Agile
Sprint Daily/ejecución
Inception Refinamiento
Backlog sprint
Planning

Refinamient
o

Product Sprint
Backlog Planning Review

Incremento de
Producto
Retrospe
ctiva
 Otros momentos importantes.
INCEPTION
Reunión que tiene como objetivo alinear
las expectativas, definir roles, evidenciar
riesgos, disminuir incertidumbre del
equipo, respecto al proyecto.
VISUAL STORY MAPPING
Se usa para representar de forma visual
necesidades o una idea de producto,
brindando como resultado versiones del
producto y plan de entregas, ayudando a
tener un panorama más claro de lo que se
va a construir.
MPV
Es un producto muy básico, con las
funcionalidades esenciales y que permite
probar la reacción que tiene el público
objetivo. Con su feedback, es posible
reconstruir y mejorar el producto, para
lanzar una nueva versión: el MPV2, y
realizar el mismo proceso.
RELEASE PLANNING
Mirar hacia adelante unos cuantos Sprints
y hacer una predicción de lo que se
entregará en cada uno de ellos
AGILE INCEPTION
USER STORY MAPPING

2023
 Agile Inception

Definición

Es un conjunto de técnicas que permiten a los

equipos empezar a desarrollar un producto de
manera coherente y eficaz. Esta metodología
reduce la incertidumbre vinculada a los nuevos
proyectos ya que permite identificar los riesgos
principales y aúna las expectativas de todos los
stakeholders.
Agile Inception
Agile Inception

Cómo preparar un Inception

Reunir a todas las personas necesarias

Conocerse:
Conocer a todos los de la sala
Sus motivaciones y expectativas para el
proyecto/producto
Su experiencia previa
Su rol en el proyecto
Agile Inception

Objetivos a lograr

¿Qué queremos?

¿Cómo?

¿Por qué?

Se pretende responder a la visión del producto

Agile Inception

Discurso del elevador (Geoffrey Moore)

Agile Inception

Discurso del elevador - Ejemplo

Agile Inception

Presentar la caja del producto

¿Si ojeáramos una revista y viéramos la publicidad de mi

producto, qué diría?,¿Lo compraríamos?

• Presentación proceso de negocio TO BE

Agile Inception

Crear una lista de Noes

Para los involucrados está claro lo que se quiere hacer en este proyecto. Seamos más
claros aún y pensemos ¿qué NO haríamos?
Agile Inception

Conocer a tus vecinos: Este ejercicio se trata de conocer a todos los

interesados que rodean al proyecto.
 Agile Inception

Muestra la solución

Dibujemos diagramas de arquitectura, despliegue (u otros) de la solución para asegurarnos de que estamos
pensando lo mismo.

• Establecer las
expectativas
tecnológicas y de
herramientas

• Visualizar el
alcance
 Agile Inception

Riesgos: ¿Qué nos quita el sueño?

Esta dinámica nos hace pensar en las peores pesadillas que podrían suceder. Hora de identificar los riesgos que
cada uno podemos identificar para nuestro proyecto.

• Riesgo 1
• Riesgo 2
• Impedimento 1
• Impedimento 2
 Agile Inception

Mide el proyecto

Se define la duración del proyecto en 3, 6 o 9 meses, no en términos exactos. El objetivo es inferir la magnitud y
ver si es costeable con los recursos de los que disponemos.

Linea de Tiempo La primera entrega

Agile Inception

Conclusiones

• Qué estamos construyendo y por qué.

• Qué es diferenciador en nuestro proyecto/producto/iniciativa.
• Que está dentro del alcance.
• Quiénes son los interesados.
• Cómo construiremos nuestra solución.
• Cuáles son los riesgos e impedimentos a los que nos
enfrentamos.
• Cuán grande vemos el proyecto
• Dónde debemos ser firmes y donde flexibles.
• Aproximadamente cuánto nos costará una primera entrega
Agile Inception

Preguntas anteriores Impact Mapping

[Discurso del elevador]
Vecindario
User Story Mapping
Lo que se incluye en el
alcance
Lo que no se incluye Product Vision Board
Lo que está en duda
Riesgos
USER STORY MAPPING

Definición

Es una técnica que consiste en organizar el Product Backlog en dos

dimensiones con el objetivo de construir un Roadmap. Este mapa se
compone de dos ejes, en uno de ellos las releases(vertical) y en el otro las
funcionalidades (horizontal).

Es por ello que tras la fase de Agile Inception, vamos a construir el mapa
utilizando un tablero de post-its, en el que identificamos la prioridad de las
historias de usuario, y el orden de implementación agrupado en releases.
Esto permite mejorar la visión de producto y construir una hoja de ruta clara
y compartida por el equipo.
 USER STORY MAPPING

https://www.researchgate.net/figure/Structure-of-User-Story-Mapping-USM_fig2_340281270
USER STORY MAPPING

https://agile-od.com/mmdojo/3112/kanban-user-story-mapping
USER STORY MAPPING
USER STORY MAPPING

Definición
 USER STORY MAPPING

PASOS
1. Identificar Lo primero que debemos de realizar es definir nuestros objetivos,
para ello escribimos en tarjetas las ideas a muy alto nivel, de lo que
objetivos representa el producto para negocio.

A continuación identificar las actividades de alto nivel a partir de los

2. Identificar objetivos definidos en el punto anterior. Estas actividades denominadas
Actividades “épicas”, deben de posicionarse horizontalmente de tal manera que
sigan un orden literario, como si de un storytelling se tratara. Esto nos
proporciona una primera foto del producto.

Seguimos descomponiendo las épicas en historias de usuario más

3. Describir pequeñas, que sean más concretas y definan funcionalidades más

específicas. Estas historias compondrán nuestras releases, las que
el timeline iremos seleccionando en cada Sprint.
Para ello se colocan las historias debajo de su épica y las ordenamos en
un orden lógico desde la perspectiva del usuario.
 USER STORY MAPPING

PASOS
4. Ordenar Una vez descompuestas y ordenadas debemos desplazarlas a lo largo

las historias del eje vertical, quedando arriba las más importantes y abajo las menos
importantes. Para ello se puede usar métodos como MoSCoW

Una vez descompuestas y ordenadas, debemos de focalizarnos en las

5. Identificar historias superiores que definirán el conjunto de funcionalidades
necesarias para definir el mínimo producto viable (MVP). De esta manera
Releases trazamos líneas horizontales, agrupando las historias de usuario en
“releases” que marcarán nuestra hoja de ruta y aquellas entregas de
funcionalidad que debemos de ir desarrollando. Se pueden mover historias
para que el “release” tenga sentido y sea consistente. Esto nos proporciona
una primera foto del producto.
 MoSCoW
Método de priorización

https://blog.ganttpro.com/en/prioritization-techniques-and-methods-for-projects-with-advantages-of-moscow-model/