Este documento presenta una introducción a Scrum, un marco ágil para el desarrollo de software. Scrum se basa en iteraciones cortas llamadas sprints durante las cuales los equipos trabajan para completar elementos de una lista de producto priorizada. Los roles clave son el product owner, quien es responsable de la lista de producto, el equipo de desarrollo auto-organizado, y el scrum master, quien ayuda al equipo a seguir las reglas de Scrum. Al final de cada sprint, el equipo demuestra el incremento de funcionalidad completado y busca formas

1. Introducción a Scrum
Rodrigo Corral
rcorral@plainconcepts.com
http://geeks.ms/blogs/rcorral
Twitter: r_corral
MVP Team System / CSM / CSP / PSDT
Plain Concepts

2. El manifiesto ágil
Individuos e iteraciones sobre Procesos y Herramientas
Sofware que funciona sobre documentación exhaustiva
Colaboración con el cliente sobre negociación de contratos
Responder al cambio sobre seguir un plan
Aunque hay valor en los elementos de la derecha ,
valoramos más los elementos de la izquierda.
“La agilidad es un marco común las metodologías
implementaciones”

3. Principios ágiles
Satisfacer al cliente.
Los cambios son bienvenidos.
Las entregas son frecuentes.
Trabajamos en equipo.
Motivamos a la gente.
Nos gusta la comunicación cara a cara.
Medida de progreso: Software que funciona.
Mantenemos un ritmo sostenido y sostenible.
La calidad no es opcional.
Primamos la simplicidad.
Evolucionamos nuestros diseños.
Reflexionamos con regularidad.

4. ¿Por qué queremos ser ágiles?
La aproximación ágil al desarrollo de software a
demostrado ser mejor para lograr:
Reaccionar frente a cambios (en los requisitos, en el mercado, en las
prioridades, en la arquitectura…)
Priorizar el desarrollo para logra maximzar el retorno de la inversión
Controlar en tiempo real el progreso del desarrollo, la calidad y los
impedimientos.
Involucrar y motivar a los desarrolladores.

5. ¿Quién usa Scrum?
Fuente: TFS Adoption within EMEA – A Process Perspective
http://processmentor.com/Community/blogs/carl_rogers/archive/2008/02/29/481.aspx

6. ¿Quién usa Scrum?
Fuente: Scrum Alliance – Firms using Scrum
http://scrumcommunity.pbworks.com/Firms+Using+Scrum

7. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
• Scrum permite que equipos de desarrolladores sean productivos
en entornos con incertidumbre y cambios.
• Es un marco simple y poderoso, con reglas claras, que permite a
los equipos y sus clientes adaptar y controlar el desarrollo de los
proyectos.
• Proporciona una alto grado de claridad, visibilidad y
transparencia.
• Scrum hace visibles rápidamente los problemas y permite y exige
mejorar continuamente los resultados.
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)

8. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• El Product Owner decide que se debe producir para lograr
el éxito del proyecto y asegura el ROI.
• El Product Owner recoge la información proporcionada por
usuarios finales, gestores, ‘stakeholders’, ejecutivos,
expertos etc… y elabora una visión unificada.
• Esta visión unificada se recoge en una lista priorizada
atendiendo al ROI y riesgo.
• Esta lista se llama Product Backlog.

9. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• El Product Backlog el la lista única y maestra de requisitos.
• Recoge requisitos funcionales y no funcionales priorizados
según el valor para el negocio y el riesgo según el criterio
del Product Owner.
• El orden dentro de la lista deja clara la prioridad.
• El Product Backlog es revisado constantemente y refinado
constantemente por el Product Owner y se añaden,
eliminan o modifican los elementos para maximizar el valor
para el negocio de esfuerzo del equipo.

10. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• Descripción de una funcionalidad atómica desde el punto
de vista del negocio.
• La descripción debe ser ‘suficiente buena’ para permitir a
los desarrolladores primero estimarla y después dividirla en
tareas y desarrollarla.
• Debe incluir criterios de aceptación.
Product Backlog Item /
Historia de usuario

11. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• El tamaño ideal es de unos 7 miembros.
• El equipo es multidisciplinar y tiene todos las capacidades
necesarias para desarrollar el proyecto. Todo el mundo
contribuye según su capaciada, no según su puesto.
• El equipo es autoorganizado y auto gestionado.
• El equipo es responsible de realizar compromisos basados
en estimaciones realista y alcanzar sus propios objetivos.

12. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• El Scrum Master trabaja al servicio del equipo (elimina
impedimentos), protege al equipo (de ruido,
interrupciones, o interferencias) y les guía y enseña a usar
Scrum.
• El Scrum Master es un facilitador (una jardinero, un
apicultor…)
• Es el responsable de que todas las liturgias de Scrum
ocurran.

13. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• El equipo trabaja en periodos fijos de tiempo llamados
Sprints.
• Los Sprints duran entre 1 y 4 semanas. Nunca más.
• Los Sprints se suceden de manera continua.
• Nada ocurre fuera de un Sprint (salvo Spikes puntuales).

14. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• El Product Owner propone el trabajo a realizar en cada sprint.
• El Product Owner describe verbalmente el trabajo que el equipo
ha de realizar en el próximo sprint.
• El equipo divide el trabajo a realizar el próximo sprint en tareas.
• El equipo compromete el trabajo que estima que es posible
realizar.
• Todo el equipo forma parte de este proceso.
• Problema: todos los equipos comprometen más de lo que son
capaces de hacer en los primeros sprints.

15. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• Durante el Sprint no cambia el alcance del trabajo comprometido
por el equipo, ni la duración del spring (máximo 30 días)
• Esto permite al equipo mantener sus compromisos y permite
que trabaje enfocado.
• Duarnte el sprint el PO trabaja para preparar el siguiente Sprint.
• Si ocurre una circustancia anomala el Scrum Master puede
cancelar el sprint. Esto es un mecanismo de protección.

16. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• En compensación por no hacer cambios durante el Sprint el
Produc Owner puede hacer los cambios que considere
necesarios antes de comenzar el siguiente Sprint.
• El Product Owner puede añadir, quitar, o reordenar
elementos del Producto Backlog.

17. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• Cada día el equipo mantiene una reunión corta de seguimiento
(15 min. max.)
• Típicamente de pié cada miembro contesta tres preguntas:
• ¿Qué hiciste ayer?
• ¿Qué vas ha hacer hoy?
• ¿Qué te impide avanzar?
• Es labor del Scrum Master actuar sobre los impedimentos
detectados.

18. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• El afán del equipo es completar el 100% del trabajo
comprometido.
• Completado significa completado: funcionalidad totalmente
diseñada, implementada y probada, sin defectos aparentes.
• Deplegar los incrementos de funcionalidad potencialmente
entregables es opcional, pero siempre debería ser posible.

19. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• Al final del Sprint el Product Owner, el equipo , el Scrum
Master y todos los stakeholders que lo deseen se reúnen
para ver una demostración de lo que el equipo a producido.
• El Product Owner recoge el ‘feedback’ de todo el mundo
con el fin de mejorar los resultados del proyecto.
• El ‘feedback’ se incorpora al Producto Backlog y el Product
Owner es quien lo prioriza.

20. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
• El equipo, el Product Owner, y el ScrumMaster se reunen al final
de cada Sprint y revisan cómo trabajan buscando maneras de
mejorar su efectividad.
• Este es el mecanísmo de mejora continua y la manera de
detectar problemas que deben ser corregidos y comunicados a
gestores o clientes.

21. Scrum
2.
3.
4.
5.
1.
7.
8.
9.
10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de
funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios
(ni en duración, ni en
alcance)
Tiempo
Recursos Alcance
Calidad

22. Flujo acumulado de proyecto
¿Cuándo
terminaremos?
¿Cuánto han
cambiado los
requisitos?

23. Sprint burndown chart
¿Cuánto retraso
tenemos
acumulado?

24. ¿Qué ha cambiado?
• Visibilidad total de como ‘funciona la fabrica’.
• Implicar a todos en:
– La cultura de excelencia y calidad.
– La gestión de los proyectos.
– La inquietud por la mejora continua.
– El servicio al cliente.
• Gestión basada en métricas claras y simples.
• Todos el mundo tiene un modelo claro de como se
desarrolla software.
• Todo el mundo trabaja contra objetivos claros, realistas
y a corto plazo.

26. Q&A, Recursos
Calendario e información http://bit.ly/xc3rPE
May 7-8 Professional Scrum Foundations
May 9-11 Professional Scrum Developer (.NET)
jlsoria@plainconcepts.com
http://geeks.ms/blogs/jlsoria
@jlsoriat

27. ¡GRACIAS!