SCRUM

Transformación
Ágil
 Evolución en la Industria
 Productos repetitivos
 Management 1.0
1850
1
Productos hechos  Fuerza de Trabajo
en fábricas  Productividad
 Estructuras rígidas jerárquicas

 Productos diferenciadores
 Management 2.0
 Fuerza de Trabajo Semi-
Calificada

2
 Eficiencia
Bienes asequibles
1960 producidos en fábricas


Producción en Serie
Lean, TQM…

 Pro-sumer
 Management 3.0
Bienes altamente

3
 Trabajo con Conocimiento
2000 asequibles y 

Complejidad
Personalización
personalizados  Agilidad
Actividad
Hagamos el mayor número de puntos
 ¡La pelota tiene que pasar en la mano de todos!
 ¡La pelota tiene que tener un tiempo en aire!
 No es posible pasar la pelota para derecha o
izquierda
 ¡La pelota tiene que terminar donde partió!
 Product Owner
ROLES SCRUM

Punto Justo

Equipo de desarrollo
Scrum master
  Determinar la visión del producto, hacia dónde va el
equipo de desarrollo
 Gestionar las expectativas de los stakeholders
 Recolectar los requerimientos
 Determinar y conocer en detalle las características
funcionales de alto y de bajo nivel
 Generar y mantener el plan de entregas (release plan):
fechas de entrega y contenidos de cada una
 Maximizar la rentabilidad del producto
 Determinar las prioridades de cada una de las
características por sobre el resto
 Cambiar las prioridades de las características según
ProductOwner avanza el proyecto, acompañando así los cambios en el
negocio
(PO)  Aceptar/rechazar el producto construido durante el
Sprint y proveer feedback valioso para su evolución
 Participar de la revisión del Sprint junto a los
miembros del Equipo de Desarrollo para obtener
feedback de los stakeholders.
Actividad
Ordenar al equipo_
 Todos participan como un solo grupo
 Definir un gerente de proyecto
 El gerente de proyecto ordena al equipo por
nombre (de A a Z) y se incluye en la fila
Actividad
Ordenar al equipo_
 Sin rol de gerente de proyecto
 Todos participan activamente en ordernarse por
apellido (de A a Z)
¡NINGUNO
DE NOSOTROS
ES MEJOR QUE TODOS
NOSOTROS JUNTOS!

RAY KROC, FUNDADOR DE MCDONALD’S

 El equipo de desarrollo está formado por todos los
individuos necesarios para la construcción del
producto en cuestión.
 Es el único responsable por la construcción y calidad
del producto.
 El equipo de desarrollo es auto-organizado. Esto
significa que no existe un líder externo que asigne las
tareas ni que determine la forma en la que serán
resueltos los problemas.
 El equipo de desarrollo tiene tres responsabilidades:
La primera es proveer las estimaciones de cuánto
esfuerzo será requerido para cada una de las
características del producto. La segunda
responsabilidad es comprometerse al comienzo de
Equipode Desarrollo
cada Sprint a construir un conjunto determinado de
características en el tiempo que dura el mismo. Y
finalmente, también es responsable por la entrega del
producto terminado al finalizar cada Sprint.
 Ordenar al equipo
Actividad
 De forma individual
Número  Escriban en 3 columnas los siguientes enunciados:
Número Letra
Romano números (naturales), números romanos y letras
1 I A  Completar de forma HORIZONTAL hasta llegar al
número 10
 Fíjate en el cronómetro cuánto tiempo duraste en
completar hasta el número 10
 Ordenar al equipo_
Actividad
 Repite el ejercicio de forma VERTICAL, cuando el
Número
Número
Letra
coach lo indique
Romano

1 I A
 El ScrumMaster es el Coach del equipo y es quien lo ayuda
a alcanzar su máximo nivel de productividad posible.

Entre sus responsabilidades esta:

 Velar por el correcto empleo y evolución de Scrum
 Facilitar el uso de Scrum a medida que avanza el
tiempo. Esto incluye la responsabilidad de que todos
asistan a tiempo a las daily meetings, reviews y
retrospectivas
 Asegurar que el equipo de desarrollo sea multifuncional
y eficiente
 Proteger al equipo de desarrollo de distracciones y
trabas externas al proyecto
 Detectar, monitorear y facilitar la remoción de los
ScrumMaster impedimentos que puedan surgir con respecto al
proyecto y a la metodología
 Asegurar la cooperación y comunicación dentro del
equipo
Madurez de un Equipo Ágil
Modelo de Tuckman
 Ciclo de vida Scrum Daily Stand up

Time-boxed
Test/Develop
(No changes)

(Discovery) (Inception) Product Backlog Sprint Backlog Backlog Sprint Retrospective

Refinement Sprint Review
Sprint Planning

Ciclo de vida SCRUM

 Ciclo de Sprint Semanal
Lunes Martes Miércoles Jueves Viernes

Sprint
1 Sprint planning Planning
2 Horas

Daily Daily Daily Daily Daily

2 Daily stand-up Stand-Up Stand-Up Stand-Up Stand-Up Stand-Up
15 minutos 15 minutos 15 minutos 15 minutos 15 minutos

Backlog
Backlog
3 Refinamiento
refinamiento
1 Hora

Sprint
4 Sprint reviews Review
30 min

Sprint Sprint Retro

5
retrospectiva 45 min
 Versión inicial del roadmap de acuerdo con la priorización de épicas
Product Backlog de
Historias Épicas
El Backlog es un conjunto de trabajo priorizado con enfoque en generación de
valor
 Épicas – Historias de usuario – tareas
Épica

Historias de Usuario
Muy larga,
dividámosla
Tarea

VISIÓN Historias de Usuario

Tarea

Tarea
Historias de Usuario
Historias de Usuario
Historias de Usuario
Tarea
Historias de Usuario

Historias de Usuario
Historias de Usuario
Tarea
 Elementos de una Historia de usuario
• Que sean 3C «Card, Confirmation, Conversation»
• Que sean I.N.V.E.S.T
• Que cumplan la definición de Listo (Definition of Ready)
• Que tengan asociada una Definición de Terminado (Definition of Done)
3C´s - INVEST

Tarjeta
(Card)

Conversación

Confirmación
 Card «Tarjeta - Descripción»

- Card: Hace alusión a la descripción de la historia de

usuario «Una historia de usuario debe tener una
descripción que hable claramente de lo que se pretende
hacer»

- YO COMO …..
- NECESITO …..
- PARA …..
 Conversation «Explicación»

- Conversation: La explicación que tiene el Dueño

de producto con el equipo de desarrollo.
 Confirmation «Criterio de
aceptación»
- Confirmation: Un criterio de aceptación es el
criterio por el cual se define si una historia de
usuario fue desarrollada según la expectativa
del PO y se si puede dar como hecha.
 Product Owner?
Hagamos
SCRUM

Identifiquemos: Punto Justo

• Dueño de producto
• Equipo de desarrollo
• Scrum Master

Equipo de desarrollo?
Scrum master?
Ciudad Soñada
Individualmente escribir acerca de sus viajes
favoritos
 ¿Cuál es el lugar que más me gustó?
 ¿Qué es lo que más me gustó de ese lugar?
¿Cuáles son 3 atributos que valoro de ese EJ:
Orlando (Disney)
Product Owner? Los parques de diversiones
Divertido
Familiar
Organizado
Equipo de desarrollo?
2. Identificar atributos comunes del equipo

3. Identificar las grandes características físicas

Scrum master? que van a formar esta ciudad
 ¿Qué debería tener su ciudad para cumplir estos
atributos?
 Generar backlog por características
 Cultura y
Educación

Colegios
Muy larga,
partimola
Cancha Futbol

VISIÓN Colegios
Edificio

Ciudad en la Sala comida

Teatros
luna
Teatros
Cine
Ambulancias
Edificio
Museos
Ambulancias
Museos

Edificio
Historias de usuario
Actividad
(Persona)
Vamos a crear las historias de usuario para
Como nuestros Atributos de la ciudad soñada
(Proceso)
Necesito
(Resultado) Ejemplo
Para que
• Como padre, necesito un colegio para que mis
hijos puedan estudiar
Criterio de Aceptación

Actividad
Historia de Usuario

Yo como padre, necesito

un colegio para que mis
hijos puedan estudiar • Definir
los criterios de aceptación para
cada historia de usuario
Criterio de
Aceptación
Edificio infantil
Piscina
Cancha de Futbol
Edificio principal
Casino
Estimación
Tenemos la siguiente lista de animales:

• León

• Perro
Estimación
• Gato
XL XXL
S M L
XS
• Jirafa

• Vaca
 Estimación
• Estimar el trabajo
• Utilizar Fibonacci modificado (0-20, empezando con el 2)
Product Owner? • Estimar todo el backlog

Equipo de desarrollo?

Scrum master?
Release Planning

Actividad DEFINAMOS EL PLAN DE ENTREGAS

Sprints • PO revisa el backlog y prioriza
Product
Backlog 1 2
• El equipo planifica las historias que
pueden entregar en cada uno de los
sprints
Tablero Kanban
Release Planning

Actividad HAGAMOS SCUM

Sprints • Cada sprint tiene 20 min de time box
Product
Backlog 1 2
• Planeación: 6 Minutos
• Daily 2 Minutos
• Revisión 2 minutos
• Retrospectiva: 2 minutos
• Minutos de ejecución: 8
SPRINT PLANING
Definición de Listo -Definition of Ready

Conjunto de características que una

Historia de Usuario debe cumplir para que
el Equipo de Desarrollo pueda
comprometerse a su entrega, es decir,
incluirla en un Sprint Backlog.

Una típica definición de listo podría ser:

• La Historia de Usuario debe ser INVEST
• Todos sus pre-requisitos están
resueltos (ej: dependencias con otros
Equipos)
DAILY SCRUM
SPRINT REVIEW
Al finalizar cada Sprint se realiza una
reunión de revisión del Sprint (Sprint
Review), donde se evalúa el incremento
funcional potencialmente entregable
construido por el equipo de desarrollo (el
“qué”).

En esta reunión el Equipo Scrum y los

Stakeholders revisan el resultado del Sprint.
Al hablar de “resultado” es “producto
utilizable” y “potencialmente entregable” que Definición de Terminado - Definition of Done
el los interesados utilizan y evalúan durante Conjunto de características que una Historia de Usuario debe
esta misma reunión, aceptando o cumplir para que el equipo de desarrollo pueda determinar si ha
rechazando así las funcionalidades terminado de trabajar en ella.
construidas. Un típico criterio de “Terminado” podría ser:
• Todos los criterios de aceptación funcionan correctamente
• Todos los archivos fuentes están en el repositorio de código
fuente y el build se ejecutó exitosamente
RETROSPECTIVA
PREPARA EL ESCENARIO
Armar la agenda y las actividades , coordinar la
charla, controlar el tiempo, cierra y documenta

"Es una reunión especial en la cual RECOLECTAR DATOS

Los miembros del equipo
un equipo decide hacer una pausa deberán presentar hechos que ocurrieron
durante la iteración
para reflexionar sobre el trabajo
realizado, ver qué lecciones pueden REFLEXIONAR/ INDAGAR: el equipo analiza
los hechos y busca responder:
capitalizar y decidir cómo aplicar lo ¿por qué pasó lo que pasó?
¿cómo mejorar?
que aprendieron en el futuro
cercano.“ DECIDIR QUE HACER: El equipo
deberá armar un plan de acción para
- Diane Larsen- concretar alguno de los experimentos
planteados en la reflexión.

CERRAR LA RETROSPECTIVA
Asegurar que los miembros del equipo se
retiren con acciones concretas y
experimentos para aplicar durante la
próxima iteración.

Es importante evitar las retrospectivas de "hacer

nada", porque pierden justamente el sentido de la
reunión: las retrospectivas son para experimentar,
para buscar mejoras y seguir progresando.
5 PASOS DE UNA RETROSPECTIVA:
Armar el escenario: Lograr que las personas se focalicen en los objetivos de la reunión, en el tiempo
estipulado y con una dinámica productiva.
Recolectar datos: Lograr una visión común de la situación a analizar, tanto con datos objetivos como
subjetivos. Es la base común de hechos, eventos, sentimientos que permitirá tener una comunicación
efectiva el resto de la reunión
Indagar: Entender el porqué, tanto de lo que anduvo mal como lo que anduvo bien. Ir más allá de la
primera apariencia, para encontrar las causas profundas que hay que sostener y mejorar o cambiar.
Decidir qué hacer: teniendo una lista de posibles experimentos que el equipo puede realizar para mejorar,
es el momento de elegir, ya que no todo se puede hacer para el siguiente sprint.
Cerrar la retrospectiva: finalizar claramente la retrospectiva, con una nota positiva y ganas de realizar
los experimentos que se encontraron.

Ayuda:
• Retr-o-mat (www.plan-for-retrospectives.com )
• Funretrospectives.com (www.funretrospectives.com )
• Técnicas para la realización de Retrospectivas (http://www.kleer.la/publicamos)
• Retrospective Wiki (http://retrospectivewiki.org)
• El próximo paso (http://thomaswallet.blogspot.com.ar/search/label/retrospectiva)
Practicas
On
Contrato Social Stories To Do Doing Hold Done
Mood Marble

Lun
Mar

Mie

Jue
Vie

Impedimentos Matriz de Riesgo

Menos
Crítico Impacto

Más
Crítico Probabilidad
¿Cómo me Siento con la Agilidad?

Entusiasmado

Confundido Seguro

Atemorizado