Scrum

Ernesto Calvo
PMP | PMI-RMP | PMI-SP | PMI-ACP | ITIL | P6
CSP | RUP | MCTS | COBIT | PRINCE2 | SAFe
SCRUM

La palabra SCRUM procede

del vocabulario del rugby y
significa melé; es decir, que
los compañeros del equipo
se amontonan, forman una
piña y empujan todos en la
misma dirección.
 Resumen Ejecutivo
Scrum es un proceso ágil que
Nos permite rápidamente y en
nos permite centrarnos en
repetidas ocasiones
ofrecer el más alto valor al
inspeccionar software real de
negocio en el menor tiempo
trabajo (2 a 4 semanas).
posible.

El negocio fija las prioridades.

Cada dos semanas o un mes,
Los equipos se auto-organizan
cualquiera puede ver el
a fin de determinar la mejor
software real funcionando y
manera de entregar las
decidir si liberarlo o seguir
funcionalidades de más alta
mejorándolo en otro sprint.
prioridad.
 Pilares de Scrum
Scrum, se basa en la teoría del control empírico de procesos, emplea un enfoque iterativo
e incremental para optimizar la previsibilidad y controlar los riesgos

Transparencia
Los aspectos del proceso que
afectan al resultado, deben ser
visibles para aquellas personas que
administran dicho resultado.
Inspección
Se debe inspeccionar con la
frecuencia suficiente los diversos
aspectos del proceso para que
puedan detectarse variaciones
inaceptables en el mismo.
Adaptación
Si el inspector determina, a través
de la inspección, que uno o más
aspectos del proceso están fuera de
los límites aceptables, y que el
producto resultante será
inaceptable, debe ajustar el proceso
o el material procesado.
El ajuste debe realizarse lo más
rápidamente posible para minimizar
una desviación mayor.
 Historia de Scrum
• Nonaka y Takeuchi
– Campos de Scrum

• Jeff Sutherland
– Scrums iniciales en Easel Corp en 1993
– IDX 500 personas haciendo Scrum
• Ken Schwaber
– ADM
– Se presenta Scrum en OOPSLA 96 con Sutherland
– Autor de tres libros sobre Scrum
• Mike Beedle
– Patrones Scrum en PLoPD4
• Ken Schwaber and Mike Cohn
– Fundaron conjuntamente la Scrum Alliance en 2002, inicialmente dentro
de la Agile Alliance
 Características
• Equipos auto-organizados.
• El producto avanza en una serie de
«Sprints» de dos semanas a un mes de
duración.
• Los requisitos son capturados como
elementos de una lista de «Product
Backlog».
• No hay prácticas de ingeniería prescritas.
Scrum
 Sprint
• En Scrum los proyectos avanzan en una
serie de “Sprints”, análogo a las iteraciones
en XP.
• La duración típica es 2–4 semanas o a lo
mucho un mes calendario.
• La duración constante conduce a un mejor
ritmo.
• El product es diseñado, codificado y
testeado durante el Sprint.
 Desarrollo secuencial vs
Superpuesto
Requisitos Diseño Código Test

En lugar de hacer todo de una cosa a la vez ...

Los equipos Scrum hacen un poco de todo, todo el

tiempo
 Cambios
Cambios

Cambios

Sprint

Cambios

Planee la duración del sprint en torno a cuánto tiempo usted

puede comprometerse a mantener los cambios fuera del sprint
 Framework Scrum

Roles Bloques de Tiempo Artefactos

• Propietario del Producto • Planificación de la • Product backlog
• ScrumMaster Entrega • Sprint backlog
• El Equipo • Planificación del Sprint • Burndown charts
• Sprint
• Revisión del Sprint
• Retrospectiva del Sprint
• Scrum Diario
 Framework Scrum

Roles Bloques de Tiempo Artefactos

• Propietario del Producto • Planificación de la • Product backlog
• ScrumMaster Entrega • Sprint backlog
• El Equipo • Planificación del Sprint • Burndown charts
• Sprint
• Revisión del Sprint
• Retrospectiva del Sprint
• Scrum Diario
Propietario del Producto (1 de 2)
Responsable de maximizar el valor del trabajo realizado por el Equipo
Scrum.

Define las funcionalidades del producto.

Decide sobre las fechas y contenidos de los releases.

Es responsable por la rentabilidad del producto (ROI).

Prioriza funcionalidades de acuerdo al valor del mercado/negocio.

Ajusta funcionalidades y prioridades en cada iteración si es necesario.

Acepta o rechaza los resultados del trabajo del equipo.

Propietario del Producto (2 de 2)
El propietario del producto puede ser un miembro del equipo, que también participe
en las tareas de desarrollo.

Esta responsabilidad adicional puede disminuir la capacidad del Propietario del

Producto de trabajar con los interesados del proyecto o producto.

El propietario del producto no puede ser nunca el ScrumMaster.

Mantiene el Product Backlog y asegura la visibilidad del mismo para todos.

Para desarrollo comercial, el Propietario del Producto podría ser el gerente de

producto.

Para los desarrollos o proyectos internos, el Propietario del Producto podría ser el
gerente de la función empresarial que se esté automatizando.

El Propietario del Producto es una persona, no un comité.

 ScrumMaster (1 de 2)
Representa a la «gestión» del proyecto.

Responsable de promover los valores y prácticas de Scrum.

Responsable de asegurar que el proceso es comprendido y seguido.

Su rol principal es de remover impedimentos.

Se asegura de que el equipo es completamente funcional y productivo.

Permite la estrecha cooperación en todos los roles y funciones.

Escudo del equipo de interferencias externas.

ScrumMaster (2 de 2)
Trabaja con los clientes y la gerencia para identificar y nombrar al Propietario del
Producto

Explica al Propietario del Producto cómo hacer su trabajo

Se espera que los Propietarios del Producto sepan cómo gestionar para
optimizar el valor utilizando Scrum. Si esto no se cumple, la responsabilidad
podría recaer en el ScrumMaster.

Puede ser un miembro del Equipo, por ejemplo, un desarrollador realizando

tareas del Sprint.

El ScrumMaster nunca debe ser el Propietario del Producto.

El Equipo (1 de 2)
Convierten el Product Backlog en incrementos de funcionalidad potencialmente
entregables en cada Sprint.

Típicamente de 5 a 9 personas.

Multi-funcional, con las habilidades necesarias para crear un incremento de

trabajo: Programadores, testers, analistas, diseñadores, etc.

Los miembros deben ser full-time, puede haber excepciones (Ej.:

Infraestructura, SCM, etc.)

Los equipos son auto-organizativos.

Solo puede haber cambio de miembros entre los sprints (recomendable).

Formado por personas con los conocimientos para convertir los requerimientos en
un incremento potencialmente utilizable del producto al final del Sprint.
El Equipo (2 de 2)
A menudo tienen habilidades especializadas, como la programación, el control
de calidad, el análisis de negocio, la arquitectura, el diseño de la interfaz de
usuario o el diseño de bases de datos.

Sin embargo, las habilidades que el miembro del Equipo comparte - es

decir, la habilidad de tratar con un requisito y convertirlo en un producto
utilizable - tienden a ser más importantes que aquellas que no comparte.

Las personas que se niegan a escribir código, ya que son arquitectos o

diseñadores, no se ajustan bien a los Equipos.

No hay títulos en los Equipos, y no hay excepciones a esta regla. Los

equipos tampoco contienen sub-Equipos dedicados a áreas particulares,
como pruebas o análisis de negocio.

La composición del Equipo puede cambiar al final de un Sprint. Cada vez que se
cambian los miembros del Equipo, la productividad obtenida de la auto-
organización se ve disminuida.
 Framework Scrum

Roles Bloques de Tiempo Artefactos

• Propietario del Producto • Planificación de la • Product backlog
• ScrumMaster Entrega • Sprint backlog
• El Equipo • Planificación del Sprint • Burndown charts
• Sprint
• Revisión del Sprint
• Retrospectiva del Sprint
• Scrum Diario
Planificación de la Entrega
El propósito es establecer un plan y unas metas que los Equipos Scrum y el resto de las organizaciones puedan
entender y comunicar

Las preguntas clásicas son: ¿Cómo podemos convertir la visión en un producto ganador, de la mejor
manera posible? ¿Cómo podemos alcanzar o mejorar la satisfacción del cliente deseada y el Retorno de
la Inversión?

El plan de entrega establece el objetivo de la entrega, el Product Backlog de mayor prioridad, los
principales riesgos, y las características generales y la funcionalidad que va a contener la entrega.

También establece una fecha probable de entrega, y el costo, que debería mantenerse si no cambia
nada.

La organización puede inspeccionar el avance y hacer cambios a este plan de entrega en cada Sprint.

La planificación de entrega es completamente opcional. Si los Equipos Scrum empiezan a trabajar sin esta
reunión, la ausencia de los artefactos generados en ella se revelará en la forma de impedimentos que hay que
resolver.
 Planificación del Sprint

Capacidad del Priorización

Equipo
Objetivo
• Analizar y evaluar el Product
del Sprint
Backlog
Product Backlog
• Seleccionar el objetivo del
Sprint

Condiciones del
Negocio Planificación

• Decidir como alcanzar el Sprint

Producto Actual objetivo del Sprint (diseño) Backlog
• Crear el Sprint Backlog (tareas)
en base a los temas del Product
Backlog (user stories / features)
Tecnología • Estimar Sprint Backlog en horas
Planificación del Sprint (1 de 2)

Durante Reunión de Planificación del Sprint la iteración es planificada

La reunión se restringe a un bloque de tiempo de ocho horas para un Sprint de un

mes.

Consta de dos partes.

•Un bloque de cuatro horas, es cuando se decide lo que se hará durante el Sprint.
•Cuatro horas, para que el equipo determine cómo se va a convertir esta funcionalidad en un incremento del producto
durante el Sprint.

La cantidad de Backlog que el Equipo selecciona es una decisión del Equipo. Sólo
el Equipo puede evaluar lo que puede lograr en el próximo Sprint.

Una vez seleccionado el Product Backlog, se define un Objetivo para el Sprint(meta

que se alcanzará mediante la implementación del Product Backlog), el Objetivo del
Sprint es un subconjunto del objetivo de la entrega.

Las Tareas se deben descomponer para que se puedan completar en menos de un día.
Planificación del Sprint (2 de 2)
El Equipo se organiza para asignar y realizar el trabajo contenido en el Sprint Backlog,
ya sea durante la Reunión de Planificación del Sprint, o sobre la marcha durante el
Sprint.

El Equipo también puede invitar a otras personas a estar presentes, con el fin de
proporcionar asesoramiento técnico o de dominio.

En esta reunión, un Equipo nuevo a menudo se da cuenta de que, o bien se

hundirá, o saldrá a flote como un equipo, no individualmente.

El Equipo se da cuenta de que debe apoyarse en sí mismo. Al aceptar esto, comienza a

auto-organizarse para llegar a tener las características y el comportamiento de un
verdadero equipo.

Codificar la capa intermedia (8 hrs)

Visualizar informacion de Clientes Codificar la interfaz de usuario (4)
VIP Escribir los casos de prueba (4)
Codificar la clase clientes (6)
Actualizar test de performance (4)
 Sprint (1 de 2)
Es el corazón de Scrum.

Los Sprints están limitados en bloques de tiempo, es una iteración de un mes de

duración o menos.

La duración de cada Sprint se mantiene constante a lo largo de todo el esfuerzo de

desarrollo.

Durante el Sprint, el ScrumMaster asegura que no se realizan cambios que

afecten al Objetivo del Sprint.

Todos los Sprints utilizan el mismo marco de referencia de Scrum.

Proporcionan un incremento de funcionalidad potencialmente utilizable al producto

final.

Cada Sprint se inicia inmediatamente después del anterior.

 Sprint (2 de 2)
Tanto la composición del Equipo como los objetivos de calidad se mantienen constantes durante todo el
Sprint.

Si el Equipo siente que se ha comprometido a demasiado trabajo, se reúne con el Propietario del
Producto para eliminar o reducir el alcance del Product Backlog seleccionado para el Sprint.

Si el Equipo siente que puede tener tiempo de sobra, puede trabajar con el Propietario del
Producto para seleccionar elementos adicionales del Product Backlog.

Un Sprint puede ser cancelado antes de que el bloque de tiempo del Sprint se haya terminado.
Sólo el Propietario del Producto tiene la autoridad para cancelar el Sprint, aunque puede
hacerlo bajo la influencia de los interesados, del Equipo, o del ScrumMaster.

Cuando un Sprint se cancela, cualquier elemento del Product Backlog que haya sido completado y
"hecho", es revisado. Estos elementos son aceptados si representan un incremento
potencialmente entregable.

Las cancelaciones de Sprints son a menudo traumáticas para el equipo, y muy poco frecuentes.
Historias de Usuario (1 de 2)

Manera simple de describir una tarea concisa que agrega valor al usuario o negocio

Las historias de usuario es una invitación a la conversación

No se detallan mas hasta que se vayan a implementar

Consta de 3 partes:
• Tarjeta: Descripción escrita en lenguaje de negocio.
• Conversación: Dialogo entre los miembros del equipo y PO para aclarar dudas.
• Confirmación: Que pruebas se llevaran a cabo para decir que la HU esta completa.

Las podemos agrupar de la siguiente manera:

• Temas, Epics, Historias de Usuario, Tareas.
Historias de Usuario (2 de 2)
Independien
te

Testeable Negociable:

Modelo
INVEST

Pequeña Valiosa

Estimable
 User Stories
 Como <rol de usuario>, quiero
<función de sistema> para lograr
<valor de negocio>

 Consiste de:
Descripción escrita
Conversación (detalle, documentos,…)
Pruebas de aceptación (def. completo)
Historia de Usuario
Scrum Board
Historias de Usuario vs Casos de Uso
Product Backlog
 Formas de estimar

 Expertos
 Analogía
 Dividir
 Planning Poker
Cartas con 1, 2, 3, 5, 8, 20, 40, 100
Aprendizaje
Timeboxed
 Daily Scrum
• Parámetros
– Diaria
– Dura 15 minutos
– Parados
• No para la solución de problemas
– Todo el mundo está invitado
– Sólo los miembros del equipo, ScrumMaster y
Product Owner, pueden hablar
– Ayuda a evitar otras reuniones innecesarias
 Scrum Diario
• Todos responden 3 preguntas:
¿Qué hiciste
ayer? 1

¿Qué vas a
hacer hoy? 2

¿Hay
obstáculos en 3
tu camino?

• Los Scrums Diarios mejoran las comunicaciones, eliminan otras reuniones, identifican y eliminan los
impedimentos al desarrollo, destacan y promueven la rápida toma de decisiones y mejoran el nivel de
conocimiento de los proyectos.
• El ScrumMaster se asegura de que el Equipo mantiene la reunión. El Equipo es responsable de conducir el
Scrum Diario.
Revisión del Sprint (1 de 2)
Se realiza al final del Sprint.

Esta es una reunión restringida a un bloque de tiempo de cuatro horas para un

Sprint de un mes.

Durante la Revisión de Sprint, el Equipo Scrum y las partes interesadas

debaten sobre lo que se acaba de hacer.

El equipo presenta lo realizado durante el sprint.

Normalmente adopta la forma de una demo de las nuevas características o

la arquitectura subyacente.
Se trata de una reunión informal, en la que la presentación de la funcionalidad
está destinada a fomentar la colaboración para determinar qué hacer a
continuación.

Todo el equipo participa.

Revisión del Sprint (2 de 2)

El Propietario del Producto identifica lo que se ha hecho y lo que no se ha hecho.

El Equipo analiza lo que salió bien durante el Sprint y cuáles son los problemas
que encontró, y cómo resolvió estos problemas.

El Equipo entonces muestra el trabajo que ha sido completado y responde

preguntas.

El Propietario del Producto a continuación, analiza el Product Backlog en su estado

actual.
Herramienta de Control
Retrospectiva del Sprint
Después de la Revisión del Sprint, y antes de la próxima Reunión de Planificación de Sprint, el Equipo
Scrum mantiene una reunión Retrospectiva del Sprint

Es una reunión restringida a un bloque de tiempo de tres horas para Sprints de un mes

En esta reunión, el ScrumMaster alienta al Equipo Scrum a revisar, en el marco de proceso y

prácticas de Scrum, su proceso de desarrollo, para mejorar el próximo Sprint.

El propósito de la Retrospectiva es inspeccionar cómo fue el último Sprint en lo que

respecta a las personas, relaciones, procesos y herramientas.

Al final de la Retrospectiva del Sprint, el Equipo Scrum debería haber identificado acciones
concretas de mejora que se implementarán en el próximo Sprint.

Estos cambios se convierten en la adaptación derivada de la inspección empírica.

Todo el equipo participa

• ScrumMaster, Product owner, Equipo, Posiblemente clientes y otros
Retrospectiva del Sprint

Comenzar
Dejar de a hacer
hacer

Seguir
Hay muchas
haciendo
maneras de hacer
retrospectiva, esta
seria una
posibilidad

Todo el equipo se reúne y

discute lo que les gustaría
 Framework Scrum

Roles Bloques de Tiempo Artefactos

• Propietario del Producto • Planificación de la • Product backlog
• ScrumMaster Entrega • Sprint backlog
• El Equipo • Planificación del Sprint • Burndown charts
• Sprint
• Revisión del Sprint
• Retrospectiva del Sprint
• Scrum Diario
Product Backlog (1 de 2)
Los requisitos para el producto, que los Equipos están elaborando, están listados
en el Product Backlog.

Lista priorizada de todo lo que podría ser necesario en el producto.

Una lista de todos los trabajos deseados en el proyecto

Idealmente cada tema tiene valor para el usuario o el cliente

El Propietario del Producto es responsable del Product Backlog, de su

contenido, disponibilidad y priorización.

Repriorizada al comienzo de cada Sprint

El Product Backlog nunca está completo.

Product Backlog (2 de 2)
El Product Backlog es dinámico, ya que cambia constantemente para identificar qué necesita el
producto para ser adecuado, competitivo y útil.

Mientras existe un producto, el Product Backlog también existe.

Los elementos del Product Backlog deben tener los siguientes atributos: una descripción, una
prioridad, y una estimación. La prioridad está guiada por el riesgo, el valor y la necesidad.

El Product Backlog está ordenado por prioridad. La parte más prioritaria del Product Backlog
determina las actividades de desarrollo que se llevarán a cabo de forma inmediata.

Las pruebas de aceptación se utilizan a menudo como un atributo más del Product Backlog.
 Ejemplo de Product Backlog

Backlog item Estimación

Permitir que un invitado a hacer una reserva. 3

Como invitado, quiero cancelar una reserva. 5

Como invitado, quiero cambiar las fechas de una

3
reserva.

Como un empleado de hotel, puedo ejecutar informes

8
de los ingresos por habitación disponible

Mejorar el manejo de excepciones 8

... 30

... 50
Product backlog
 Práctica Scrum
• ¿Cómo funciona el ejercicio?
• Objetivo: Desarrollar un Producto en 2 sprints
de 3 días
• Armar grupos, definir un Product Owner,
ScrumMaster
• Cada día es de 10 min

Sprint
• Día 1: 5 min planificación + 5 min
• Día 2: 2 min Daily Scrum + 8 min
• Día 3: 2 min Daily Scrum + 6 min + 2 min demo
 Objetivo del Sprint
• Una breve declaración de cual será el foco
del trabajo durante el sprint.
• Por ejemplo:
– Permitir mantener actualizados los datos de
los clientes.
– Administrar paramétricamente las reglas de
negocio del producto de créditos hipotecarios.
 Sprint Backlog
Lista de tareas para convertir el Product Backlog correspondiente a un Sprint, en un incremento
del producto potencialmente entregable

Los individuos eligen las tareas

El trabajo nunca es asignado

La estimación del trabajo restante es actualizada diariamente

Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog

El trabajo para el Sprint emerge

Si el trabajo no está claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo
y subdividirla luego.
Burndown charts

Es una medida del backlog restante a través del tiempo

Un Burndown de Versión mide el Product Backlog restante

durante el tiempo correspondiente a una liberación de una
versión

Un Sprint Burndown mide los elementos restantes del Sprint

Backlog en el transcurso de un Sprint.
Tasks Mon Tues Wed Thur Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12

50
40
30
20
10
Hours

0
Mon Tue Wed Thu Fri
Product Backlog
Burn Down Chart
Escalabilidad

Normalmente los equipos son de 7 ± 2 personas

• La escalabilidad proviene de equipos de equipos

Factores a tener cuenta

• Tipo de aplicación
• Tamaño del equipo
• Dispersión del equipo
• Duración del proyecto

Scrum se ha utilizado en múltiples proyectos de más de 500 personas

Los roles
Las personas que tienen relación directa o indirecta con el proyecto, se
clasifican en dos grupos: comprometidos e implicados.
En Scrum se les llama a los primeros “cerdos” y a los segundos “gallinas”.
El origen de estos nombres es esta metáfora que ilustra de forma gráfica la
diferencia entre “compromiso” e “implicación” con el proyecto:
Una gallina y un cerdo paseaban por la carretera. La gallina preguntó al
cerdo: “¿Quieres abrir un restaurante conmigo?”.
El cerdo consideró la propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo
llamaríamos?”.
La gallina respondió: “Jamón con huevos”.
El cerdo se detuvo, hizo una pausa y contestó: “Pensándolo mejor, creo que
no voy a abrir un restaurante contigo. Yo estaría realmente comprometido,
mientras que tu estarías sólo implicada”.
Expansión a través de Scrum
de Scrums
Scrum de Scrums de Scrums
 1 In Agile methods, project planning may take place at 3 levels, such as visioning,
release planning, and iteration planning. These 3 levels are examples of what?

A. Rolling wave refactoring

B. Progressive elaboration.
C. Root-cause analysis
D. The Kanban process

2 The INVEST model guides writing a good user story. For the project business case, which
Letter and Characteristic reflect the customer's benefit?

A. S, Sellable
B. V, Valuable.
C. E, Effective
D. S, Significant
3 What tactic has the primary purpose of helping the team coordinate work and communicate issues?

A. Information radiators
B. Kanban board
C. Iteration planning meetings
D. Daily standup meetings.

4 Which of the following lists best describes the attributes of a good user story?
A. Small, estimable, dependent, negotiable
B. Testable, estimable, renewable, valuable
C. Negotiable, small, explainable, validatable
D. Valuable, estimable, independent, small.
5. Which of the following is a key objective of conducting Agile retrospectives?

A) Identify what went well to repeat it

B) Identify what went wrong to address it
C) Both the above.
D) None of the above

6 Of the following, which statement about sprints or iterations is least valid?

A. Each sprint should deliver incremental value

B. A longer iteration provides more competitive advantage for the customer.
C. One or several iterations may comprise a release
D. An iteration should include planning as well as reflection
7 How are the values of the stakeholders used in shaping an Agile project using Scrum?

A. Stakeholder focus groups provide input to the team in a collaborative manner

B. The Scrum Planning meetings allow the opportunity for the Product Owner, the
ScrumMaster, and the Team to hear from the invited stakeholders
C. The Product Owner serves as the voice of the users and stakeholders.
D. The team decides how to deliver exactly what the organization needs or desires

8 Who should manage the list of items that is to be completed during an iteration or
Sprint?

A. The Product Owner

B. The team.
C. The project manager
D. The team captain
9 In an Agile project using Scrum, the role of the ScrumMaster is:

A. To maintain control, access, and expectations of the Product Owner

B. To maintain the team's adherence to Scrum methods.
C. To report progress against the plan to the Scrum council
D. Very similar to that of a traditional project manager

10 Which statement is the most valid about burn up and burn down charts?

A. Burn up charts are used in sprints and burn down charts are used in backlogs
B. Burn down charts indicate the velocity of the release and burn up charts indicate the velocity of
the iteration
C. Burn down charts indicate a reduction in unfulfilled story points while burn up charts indicate
accumulation of completed story points.
D. Burn down charts are used in iterations and burn up charts are used in releases
ernesto.calvo@pmi.org.pe

www.linkedin.com/in/ernestocalvo

998-679257