¿Qué es Scrum?

Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP

Visual Developer - Visual Basic
http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx
 ¿Qué es exactamente?
• Scrum es una metodología

• ¿Y para que se utiliza?

– Se utiliza, en el desarrollo del Software
concretamente, aunque hay gente por ahí que la
usa o la quiere usar en otras profesiones y áreas.
¿Y para eso del desarrollo del Software tenéis
que usar ese tal Scrum?
• No es estrictamente necesario
• Scrum por sus características no es válido para cualquier
proyecto.
• Es óptima para equipos de trabajo de hasta 8 personas,
– Yo diría que para el 90% de los proyectos y empresas, es una
metodología válida, pero no es una metodología válida al 100%.
• Scrum es por lo tanto, una metodología más de las
muchas que hay, y ésta en concreto, se basa en la filosofía
del desarrollo ágil que fue expuesto por dos japoneses
alrededor del año 1986
has dicho desarrollo ágil varias veces... ¿que
es eso exactamente?
• En el desarrollo del Software se pide básicamente
rapidez, calidad y reducción de costos, pero para
asumir estos retos, es necesario tener agilidad y
flexibilidad.
• Los ciclos de desarrollo por otro lado,
acostumbran a ser largos, y lo que se exige por
otra parte, es que esos ciclos sean lo más cortos
posibles.
• Para mas detalle sobre metodologías Agiles ver Manifiesto ágil y
Desarrollo ágil de Software
¿en qué consiste exactamente eso de Scrum?

• Scrum es como decía antes, una metodología ágil.

• Obedece a una necesidad realmente demandada
en el desarrollo del Software.
• Scrum no es ni la mejor metodología ni la única,
pero sí, es una metodología que está empujando
muy fuerte por
– la facilidad de implantación y por
– su agilidad en cuanto a cambios y lo que propiamente
– aporta en comparación con otras metodologías.
¿en qué consiste exactamente eso de Scrum?

• Por un lado, Scrum evita la generación

documental burocrática. ¿Qué opinan?
• Con Scrum por otro lado, la idea principal es la
de ponerse a trabajar prácticamente desde el
primer momento y empezar a sacar frutos de
ese trabajo muy pronto.
¿cómo muestras al cliente esos progresos en
el trabajo?.
• En Scrum diferenciamos dos aspectos importantes, los
actores y las acciones
• Los actores son los que ejecutarán obviamente las acciones.
• Estos de forma general, serán:
– Product Owner
– Scrum Master
– Scrum Team
– Usuarios o Clientes
• Para que un proyecto Software tenga éxito, el Usuario
• o Cliente, debe involucrarse sí o SÍ.
 Los roles de los actores
• El Product Owner conoce y marca las prioridades del proyecto o
producto.
• El Scrum Master asegura el seguimiento de la metodología
guiando las reuniones y ayudando al equipo ante cualquier
problema que pueda aparecer. Su responsabilidad es entre otras,
controlar las presiones externas.
• El Scrum Team son las personas responsables de implementar la
funcionalidad o funcionalidades elegidas por el Product Owner.
• Los Usuarios o Cliente, son los beneficiarios finales del producto, y
son quienes viendo los progresos, pueden aportar ideas,
sugerencias o necesidades.
 ¿Y lo de las acciones?
• Las acciones tienen relación directa con los actores.
Sin ellas, todo sería un caos.
• En Scrum se indican claramente las acciones a
acometer y como acometerlas.
– hacerlo siempre de una forma adecuada y algo rígida
para asegurar resultados.
• Las acciones de Scrum forman parte de un ciclo
iterativo repetitivo,
– objetivo minimizar el esfuerzo y maximizar el
rendimiento en el desarrollo.
Las acciones fundamentales de Scrum son:

• El Product Backlog corresponde con todas las

tareas, funcionalidades o requerimientos a
realizar.
– el Product Owner es la persona que se encarga de
marcar las prioridades, y es la persona que
mantiene y actualiza la lista de tareas.
Product Backlog
(Pila de Producto)
Con qué se cuenta
 A la hora de hacer una estimación
1. Las estimaciones son estimaciones, es decir,
aunque le dediques mucho tiempo, no llegaremos
a una precisión del 100%
2. Las estimaciones se deciden colaborativamente,
incluyendo a quienes harán la tarea ( esto último
es muy importante)
3. Se deben realizar como la combinación de:
• Opinión del experto
• Analogía: comparar con otras tareas ya estimadas
• Disgregación: separar una tarea en varias
 Sprint Backlog
• Corresponde con una o más tareas que provienen del Product
Backlog.
– se saca una o más tareas que van a formar parte del Sprint Backlog.
• Las tareas del Sprint Backlog se recomienda realizarlas en unas 2 ó 4
semanas.
– Hay Sprint Backlogs de 2 semanas y hay Sprint Backlogs de 4 semanas.
– Eso debe de ser marcado antes de iniciar el Sprint Backlog, de hecho, del
Product Backlog se sacará la tarea o tareas realistas para acometer el Sprint
Backlog.
• Cuando un Sprint Backlog se inicia, éste NO puede ser alterado o
modificado.
– Hay que esperar a que concluya el Sprint Backlog para realizar la
modificación cuya tarea, formaría parte de otro Sprint Backlog.
Generando el Sprint Backlog
 Daily Scrum Meeting
• Es una tarea iterativa realizada todos los días que dure el
Sprint Backlog con el equipo de trabajo. Es una reunión
operativa, informal y ágil, de un máximo de 30 minutos,
en la que se le hace 3 preguntas a cada integrante del
equipo.
– Qué tareas ha realizado desde la última reunión (que he
hecho).
– Sobre qué va a trabajar en el día actual (que voy a hacer hoy).
– Identificación de obstáculos o riesgos que impiden o pueden
impedir el normal avance (que ayuda necesito). El Scrum
Master, debe eliminar aquí cualquier obstáculo que encuentre.
Actualización diaria del Sprint
Gráfica de Trabajo Restante del Sprint
 ¿que se hace cuando una tarea del Sprint
Backlog se finaliza?
• Sprint Backlog, una vez que se inicia, no se toca. Es
decir, que una tarea se acaba, y punto
– Se continúa con otra tarea del Sprint Backlog y así hasta
que se acaben
• Lo que debemos tener claro, es que al finalizar un
Sprint Backlog (ya sea de 2 ó 4 semanas), debemos
haber acabado las tareas del Sprint Backlog.
• Recordar: Las tareas del Sprint Backlog deben de
ser realistas.
 Al finalizar un Sprint Backlog
• Deberíamos tener algo, un entregable o algo
que se pueda mostrar y que enseñe los avances
acometidos en el Sprint.
• En el Product Backlog tendremos más tareas, y
es posible incluso que
– hayan salido nuevas tareas o que
– otras hayan desaparecido,
• Cuando se acaba el Sprint Backlog, debemos
hacer varias cosas importantes
 Sprint Planning Meeting
• Es una reunión Entre el Product Backlog y el Sprint Backlog que
tiene por objetivo, planificar el Sprint a partir del Product
Backlog.
• El objetivo de esta reunión es la de mover las tareas del Product
Backlog al Sprint Backlog.
• En esta reunión, suelen participar el
– Product Owner (quien prioriza las tareas),
– El Scrum Master y
– El Scrum Team.
• Del Sprint Planning Meeting, sale también el Sprint Goal, que es
un pequeño documento o una breve descripción que indica lo
que el Sprint intentará alcanzar.
 Sprint Review
• Se revisa en unas 2 horas como máximo el Sprint finalizado.
• Al llegar a este punto, debemos tener "algo" que el Cliente
o el Usuario pueda ver y tocar.
• En esta reunión, suelen asistir
– Product Owner,
– Scrum Master,
– Scrum Team y
– personas que podrían estar involucradas en el proyecto.
• El Scrum Team es quién muestra los avances realizados en
el Sprint.
 Sprint Retrospective
• Se inicia al finalizar un Sprint Backlog y el Sprint
Review,
• El Product Owner revisará con el equipo los
objetivos marcados inicialmente en el Sprint
Backlog concluido,
– Se aplicarán los cambios y ajustes si son necesarios, y
– Se marcarán los aspectos
• positivos (para repetirlos) y los aspectos
• negativos (para evitar que se repitan)
– del Sprint.
 Pila de Entrega
(subconjunto de la Pila de Producto)
Gráfica de Trabajo Restante de la Entrega
¿Y porque es eso de las 2 ó 4 semanas?

• Cada equipo, cada empresa, cada proyecto,

puede poner la franja horaria y frecuencia
temporal que considere oportuno así como
cambiar aspectos de Scrum,
– Pero es mejor hacer esto así que de otra forma.

¿Porqué?
 El ajuste temporal de 2 ó 4 semanas
• En término medio que está basado en la experiencia de
muchas personas en muchos proyectos.
• No es lo mismo reconducir el proyecto perdiendo 2 ó 4
semanas, que reconducirlo perdiendo 6 meses por
ejemplo.
• La idea de la metodología ágil es que
– adopte los cambios, que se pueda reconducir el proyecto en
un momento dado, y que afecte lo menos posible a
• los costos,
• los tiempos y
• al equipo de trabajo
Resultados encuesta
 referencias
• http://geeks.ms/blogs/jorge/archive/2007/05/
09/explicando-scrum-a-mi-abuela.aspx
• http://scrumtraininginstitute.com/home/strea
m_download/scrumprimer-es