SCRUM

MSc. Lic. Carla Salazar Serrudo

Departamento de Informtica y Sistemas
Universidad Mayor de San Simn
Cochabamba, 2016

SCRUM
Scrum es una framework para la gestin de proyectos, expuesta por
Hirotaka Takeuchi e Ikujiro Nonaka, en el artculo The New Product
Development Game[Harvard Business Review Ene-Feb 1986] en el que
ponen de manifiesto que:
El mercado competitivo de los productos tecnolgicos, adems de los conceptos
bsicos de calidad, coste y diferenciacin, exige tambin rapidez y flexibilidad.
Los nuevos productos representan cada vez un porcentaje ms importante en el
volumen de negocio de las empresas.
El mercado exige ciclos de desarrollo ms cortos.

Definicin de SCRUM
SCRUM es un marco de trabajo que permite resolver problemas complejos
y se caracteriza porque es
gil
Fcil de entender
Difcil de dominar, aplicar o tener un completo conocimiento

SCRUM ha sido creado para la gestin de procesos de desarrollo de

software, pero puede ser utilizado en diferentes tipos de proyectos, con
requisitos inestables, que requieren rapidez y flexibilidad.
SCRUM NO es un proceso o tcnica para construir productos, ms bien es
un marco de trabajo en el que se puede incluir procesos y tcnicas.

Origen de SCRUM
El rugby es un tipo de ftbol, que se juega con una pelota ovalada y es un
deporte de fuerte contacto fsico
En el rugby se respetan mucho las reglas, tanto por parte de los jugadores,
como del pblico.
Se fomenta la sociabilidad, compaerismo, la honestidad, el respeto, la
disciplina, la lealtad, el sacrificio y el altruismo.
Las decisiones del rbitro, en general, son respetadas
El Scrum o la mel, una de las formaciones ms reconocibles del rugby, es
una puja frente a frente, de un grupo de cada equipo formado por un
mximo de ocho y un mnimo de cinco jugadores en tres lneas que se
enfrentan agazapados y asidos entre s, para comenzar a empujar con el fin
de obtener el baln que ha sido lanzado en medio de ellos y sin tocarlo con
la mano.

Orgenes de SCRUM

Historia de SCRUM
Jeff Sutherland aplic el modelo SCRUM al desarrollo de software en
1993 en Easel Corporation (Empresa de macro-juegos de compras),
en Informix y en Ascential Software.
En 1995 lo present junto con Ken Schwaber como proceso formal
para la gestin de desarrollo de software en OOPSLA 95.
El 2001 seran dos de los promulgadores del Manifiesto gil.

Modelo de SCRUM

Pilares de SCRUM
SCRUM se basa en lo emprico.
El empirismo afirma que el conocimiento viene de la experiencia y la
toma de decisiones se basa en lo que es conocido.
Los tres pilares de todo proceso emprico son:
Transparencia
Inspeccin
Adaptacin

Transparencia
Los aspectos significantes del proceso deben ser visibles para todos
Los observadores deben compartir un entendimiento comn del
proceso.
Por ejemplo:
Se debe compartir un lenguaje comn entre todos los participantes
Debe existir una definicin comn de Done (terminado) tanto para los
desarrolladores como para los que deben aceptar el producto.
Los problemas deben ser conocidos por todo el equipo
La informacin debe estar disponible para todo el equipo

Ejemplo de tablero Kanban

Tablero Kanban, unos das despus

Inspeccin
Se debe inspeccionar frecuentemente los aspectos del proceso
SCRUM para detectar variaciones que no son permitidas al tiempo de
alcanzar la meta.
Las inspecciones no deberan ser tan frecuentes que consigan
informacin acerca de cmo se est haciendo el trabajo
Deben realizarse con inspectores que sean diligentes y expertos en el
tema.

Adaptacin
Si despus de la inspeccin se determina que uno o ms aspectos del
proceso SCRUM se han desviado ms all de los lmites aceptables, el
proceso o el material que est siendo procesado debe ser ajustado.
Los ajustes deben hacerse lo mas antes posible, para minimizar el desvo.
SCRUM incluye cinco oportunidades para transparencia, inspeccin y
adaptacin:

Sprint Planning
Daily Scrum
Sprint Review
Sprint Demonstration
Sprint Retrospective

Componentes de SCRUM
Roles
SCRUM Team
SCRUM Master
Product Owner

Artefactos
Product Backlog
Sprint Backlog
Burn Down

Actividades

Planning Sprint
Daily meeting
Sprint
Sprint demostration
Sprint review

Roles de SCRUM: Product Owner

Product Owner (Dueo del producto): Es el responsable de obtener
el mximo valor del producto y el mximo desempeo del equipo.
El Product Owner es la nica persona responsable por administrar el
Product Backlog.
La administracin del Product Backlog incluye:
Escribir claramente los items del Product Backlog;
Priorizar los items del Product Backlog para alcanzar las metas de la mejor
forma posible
Garantizar el valor del trabajo que el equipo de desarrollo est realizando
Asegurar que el Product Backlog sea visible, transparente y claro para todos
Asegurar que el Team entienda los items del Product Backlog en el nivel
necesario

Product Owner (2)

El Product Owner es una persona, no un comit. El Product Owner
representa los deseos de un comit en el Product Backlog.
El Product Owner tiene xito si toda la empresa respeta sus
decisiones. Las decisiones del Product Owner se reflejan en el
contenido y orden del Product Backlog
Solo el Product Owner puede cambiar el conjunto de requisitos.

Product Owner en Scrum

El equipo de desarrollo: Team

El Team consiste de profesionales que deben realizar el trabajo de entrega
del incremento resultante al final de cada Sprint. Slo los miembros del
equipo pueden crear el incremento.
Los equipos deben organizar y gestionar su propio trabajo. La sinergia del
equipo ayuda a la eficiencia y efectividad del equipo.
Los equipos de trabajo tienen siguientes caractersticas:

Auto-organizados: Nadie puede decir al equipo cmo transformar el Product Backlog

en incrementos. Solo los del equipo pueden decidir
Multidisciplinarios: Los equipos incluyen todas las habilidades necesarias para crear
el incremento
Misma categora: Todos los miembros del equipo son Desarrolladores
Unidad: Si bien cada desarrollador tiene sus habilidades y destrezas, el resultado del
trabajo pertenece al equipo.
El equipo no contiene sub-equipos dedicados a trabajos especializados

Tamao del Equipo

El tamao ptimo de un equipo debe ser pequeo para mantener la
agilidad y lo suficientemente grande para completar el trabajo.
Se recomienda por lo menos 3 desarrolladores para que exista
interaccin y produccin
Equipos con ms de 9 desarrolladores requieren demasiado trabajo
de coordinacin.
El Product Owner y el Scrum Master no deben ser incluidos dentro
del tamao del equipo.

Scrum Master
El Scrum Master es responsable de garantizar el entendimiento y
conocimiento de SCRUM
Scrum Master garantiza que el equipo aplica la teora, prctica y
reglas de SCRUM
Scrum Master ayuda al equipo a entender cules interacciones son
tiles y cules no lo son.

Scrum Master: apoyo al Product Owner

Buscar tcnicas para gestionar el Product Backlog de manera efectiva
Facilitar la comunicacin con el equipo
Ensear a crear las historias de usuario de manera clara y concisa
Comprender la planificacin del producto a largo plazo
Entender y practicar la agilidad
Facilitar el desarrollo de eventos Scrum

Scrum Master: apoyo al equipo

Entrenar al equipo en la auto-organizacin y el trabajo
multidisciplinario.
Eliminar los impedimentos del progreso del equipo
Facilitar eventos Scrum
Entrenar al equipo en aspectos de Scrum que no estn bien
adoptados y entendidos

Scrum Master: apoyo a la organizacin

Guar y entrenar para la adopcin de Scrum en la organizacin
Planificar la implementacin de Scrum
Ayudar a los empleados y a los empleados en el entendimiento y
aplicacin de Scrum
Apoyar el incremento de productividad del equipo
Trabajar con otros Scrum Masters para incrementar la efectividad de
la aplicacin de Scrum en la organizacin

Actividades de Scrum
SCRUM incluye eventos pre-establecidos para crear regularidad y
minimizar la necesidad de realizar reuniones extras
SCRUM incluye eventos que tienen un mximo de duracin. Esto
garantiza una planificacin y uso de tiempo apropiados, sin
desperdicio de tiempo.
Los eventos de SCRUM se constituyen en una oportunidad para
inspeccionar y adaptar. Estos eventos tambin estn diseados para
permitir la transparencia y la inspeccin
Sino se los realiza, no existir transparencia, inspeccin y adaptacin.

El Sprint
El corazn de SCRUM es un Sprint.
Un Sprint es un evento de tiempo delimitado, de mas o menos un
mes de duracin, en el cual se crea un producto (incremento)
Los Sprints deben tener una duracin consistente en el desarrollo del
producto. Un nuevo Sprint debe comenzar inmediatamente despus
de la conclusin del previo Sprint.
Sprint contiene y consiste de:

Sprint Planning
Daily Scrums
Desarrollo del trabajo
Sprint Review
Sprint Retrospective.

El Sprint
Durante el Sprint:
.

No se pueden realizar cambios que afecten la meta del Sprint

La composicin del equipo de desarrollo debe mantenerse
Los aspectos de Calidad se deben cuidar
El alcance puede ser clarificado y re-negociado entre el Product Owner y el Equipo, si es
necesario.

Cada Sprint puede ser considerado como un proyecto de un mes de duracin.

Cada Sprint tiene una definicin de qu tiene que ser construido, un diseo y un
plan flexible que debera guiar su construccin y el desarrollo del producto final
Cada Sprint debe durar un mes calendario. Cuando un Sprint es demasiado largo,
la definicin de lo que se est construyendo puede cambiar, la complejidad
puede aumentar y el riesgo puede crecer. Los Sprints necesitan ser predecibles
para asegurar inspeccin y adaptacin y para controlar el costo.

Cancelar un Sprint
Un Sprint puede ser cancelado antes de que se cumpla su plazo de tiempo.
Solo el Product Owner tiene la autoridad para cancelar el Sprint.
A Sprint debera ser cancelado si el objetivo del Sprint se vuelve obsoleto. Esto
podra ocurrir si la compaa cambia de directrices o si el mercado o las
condiciones de tecnologa cambian. Rara vez ocurre, dado el corto tiempo del
Sprint
Cuando se cancela un Sprint, se deben revisar todos los Done y los tems del
Product Backlog tambin deben ser revisados.
Se puede entregar el trabajo realizado y los tems no completados deben ser reestimados y puestos en el Product Backlog.
La cancelacin de Sprints consume recursos, puesto que hay que re-agrupar los
tems en otros Sprints, durante el Sprint Planning.
Las cancelaciones de Sprint pueden ser muy traumticas para el Scrum Team

Reunin Sprint Planning

El trabajo a realizarse durante el Sprint se planifica en la reunin
Sprint Planning. Se elabora un plan con todo el equipo de Scrum
La reunin de Sprint Planning tiene un lmite de 8 horas para 1 mes
de Sprint. Para Sprints mas cortos, se debe acortar
proporcionalmente la duracin de la reunin. Ej: 2 semanas de Sprint,
entonces 4 horas de reunin
La reunin de Sprint Planning tiene 2 partes, cada una de las cuales es
la mitad de toda la duracin de la reunion. Cada parte responde lo
siguiente:
Cul debera ser el incremento resultante del Sprint?
Qu trabajo debera hacerse para alcanzar el incremento?

Parte 1: Qu debera hacerse en el Sprint?

El equipo de desarrollo debe trabajar prediciendo la funcionalidad que
debe desarrollarse durante el Sprint. El Product Owner presenta una lista
ordenada de los items del Product Backlog y el equipo completo colabora
en el entendimiento del trabajo del Sprint
La entrada a esta reunin es el Product Backlog, el ltimo incremento, la
capacidad proyectada de desarrollo del equipo durante el Sprint y el
desempeo pasado del equipo de desarrollo. La seleccin de los tems a
desarrollarse es decisin nica del Equipo de Desarrollo.
Despus que el Equipo de Desarrollo selecciona los items del Product
Backlog a desarrollar durante el Sprint, el Equipo elabora el objetivo del
Sprint. El objetivo del Sprint debera guiar la construccin del incremento.

Parte 2: Cmo debera hacerse el trabajo?

El Equipo decide cmo debera construir la funcionalidad solicitada para tener el
DONE. Los tems seleccionados para el Sprint + el plan para entregarlos se llama
Sprint Backlog
El Equipo empieza diseando los tems del Product Backlog. Pueden existir
variaciones en el tamao o en el esfuerzo estimado durante la reunin de
Planificacin del Sprint. El trabajo planificado se debe descomponer en unidades
de un da o menos (enginnering task). El equipo se auto-organiza para entender el
trabajo
El Product Owner puede estar presente durante la segunda parte de la Reunin
de Planificacin para aclarar los tems seleccionados para el Sprint. Si el Equipo
determina que tiene poco o mucho trabajo, se puede re-negociar el Sprint
Backlog con el Product Owner. El Equipo tambin puede invitar a otras personas
para tener opiniones tcnicas o del dominio de la aplicacin.
Al final de la Reunin de Planificacin del Sprint, el equipo debera ser capaz de
explicar al Product Owner y al Scrum Master cmo puede alcanzar la meta del
Sprint.

Objetivo del Sprint

El Objetivo del Sprint permite al Equipo tener alguna flexibilidad para
conseguir la funcionalidad solicitada durante el Sprint.
El objetivo del Sprint puede ser un hito del gran propsito del plan del
producto.
A medida que el equipo trata de alcanzar el objetivo del Sprint,
pueden existir diferencias respecto a lo planificado. Entonces, se debe
negociar con el Product Owner para cambiar el alcance del Sprint
Backlog

Reunin Daily Scrum

El Daily Scrum es una reunin de 15 minutos que realiza el Equipo
para sincronizar sus actividades y para elaborar un plan para las
siguientes 24 horas.
El Daily Scrum debe realizarse en el mismo lugar y hora, cada da.
Durante la reunin, cada miembro del Equipo debe explicar:
Qu hizo desde la ltima reunin?
Qu debe hacer hasta la prxima reunin?
Qu obstculos hay en el camino?

El Equipo usa el Daily Scrum para evaluar su progreso rumbo el

objetivo del Sprint. Esta reunin optimiza la probabilidad de que el
Equipo alcance el objetivo del Sprint, dado que los miembros del
Equipo pueden replantear el resto de su trabajo del Sprint.

Reunin Daily Scrum (2)

El Scrum Master se asegura que el Equipo efectivice la reunin diaria de 15
minutos, pero el equipo de desarrollo es responsable por conducir la
reunin.
Cada da, el Equipo debe explicar al Product Owner y al Scrum Master
cmo piensan trabajar para alcanzar el Objetivo del Sprint y crear el
Incremento.
El Scrum Master refuerza la regla que en la reunion diaria solo pueden
participar miembros del Equipo de desarrollo.
La reunin diaria mejora la comunicacin, elimina otras reuniones,
identifica y remueve impedimentos de desarrollo, enfatiza y promueve la
rpida toma de decisiones y mejora el nivel de conocimiento del Equipo.
Es clave para inspeccionar y adaptar.

Sprint Review
Es una reunin que se realiza al finalizar el Sprint para inspeccionar el
Incremento y adaptar el Product Backlog, si es necesario.
El Equipo Scrum presenta a la gente del negocio lo desarrollado
durante el Sprint. Basado en este desarrollo, se determina qu es lo
prximo a desarrollarse.
Es una reunin informal donde se presenta el Incremento para
conseguir retroalimentacin y fomentar la colaboracin del Product
Owner
Es una reunin de 4 horas para un Sprint de 1 mes. Si el Sprint es ms
corto, la reunin debera durar proporcionalmente menos. Ejemplo: 2
semanas de Sprint debera tener 4 horas de Sprint Review.

Sprint Review (2)

El Sprint Review incluye los siguientes elementos:

El Product Owner identifica qu ha sido terminado (Done) y qu no se ha terminado.

El Equipo expone el trabajo que ha sido terminado (Done) y responde a las consultas
acerca del Incremento
El Equipo expone qu ha ido bien durante el Sprint, qu problemas tuvieron y cmo
se fueron solucionando los problemas.
El Product Owner discute el Product Backlog actual y proyecta la probable conclusin
del proyecto, basado en el progreso actual
El grupo entero discute que ser lo prximo a desarrollar con vistas a la siguiente
reunin Sprint Planning

El resultado del Sprint Review es el Product Backlog revisado, de manera

que se definen los tems a desarrollarse el siguiente Sprint. En general, el
Product Backlog puede ser cambiado para conseguir nuevas oportunidades

Sprint Retrospective
Esta reunin es una oportunidad para que el Equipo Scrum
inspeccione lo hecho y cree un plan de mejoras para el siguiente
Sprint.
Esta reunin se realiza despus del Sprint Review y antes del siguiente
Sprint Planning. Es una reunin de 3 horas para un Sprint de 1 mes.
Los propsitos del Sprint Retrospective son:
Inspeccionar cmo fue el ltimo Sprint respecto a las personas, relaciones,
procesos y herramientas.
Identificar y ordenar los tems que salieron bien
Crear un plan para implementar mejoras al trabajo desarrollado por el Equipo
Scrum

Sprint Retrospective
The Scrum Master alienta al Scrum Team a mejorar el proceso Scrum para
el siguiente Sprint.
El Scrum Team, durante cada reunin de Retrospective, planifica cmo
mejorar la calidad del producto redefiniendo el concepto de Done, como
sea adecuado.
El Scrum Team deberan identificar las mejoras que deberan
implementarse en el siguiente Sprint.
Implementar las mejoras significa aplicar la Adaptacin a partir de la
Inspeccin
La reunin de Retrospective provee una oportunidad formal para enfocar
en la inspeccin y la adaptacin

Artefactos de Scrum
Los artefactos de Scrum representan una valiosa manera de brindar
transparencia y oportunidades para inspeccin y adaptacin
Los artefactos de Scrum maximizan la transparencia para garantizar
xito al Scrum Team en la entrega del incremento (Done)

Product Backlog
El Product Backlog es una lista ordenada de todo lo que puede ser necesario para
el producto, es decir es una fuente de requisitos para construir el producto.
El Producto Owner es responsable por el Product Backlog: contenido,
disponibilidad y orden.
El Product Backlog nunca est completo. Los primeros desarrollos se basan en el
conocimiento inicial del producto. El Product Backlog evoluciona a la par del
producto y del ambiente.
El Product Backlog es dinmico: cambia constantemente para identificar qu
necesita el producto para ser apropiado, competitivo y til. Mientras existe el
producto, el Product Backlog tambin existe.
El Product Backlog es una lista de todas las caractersticas, funciones, requisitos,
mejoras y correcciones que se debe hacer para las futuras entregas. Los tems de
Product Backlog tienen atributos de descripcin, orden y estimacin

Product Backlog (2)

El Product Backlog se puede ordenar por valor, riesgo, prioridad y necesidad. Los tems
que se encuentran en la cima de la pila del producto son aquellos que inmediatamente
se desarrollarn. Se supone que estos tems han sido los ms considerados y los que ms
consenso tienen acerca de su valor.
Los tems de la cima del Product Backlog son mas claros y ms detallados que los que
estn abajo. Por lo tanto, se pueden estimar mejor que los tems menos detallados
Los tems del Product Backlog que pueden ser Done (terminados) en el Sprint, se
consideran listos para seleccionarse durante la reunin de Sprint Planning
El producto gana valor a medida que se usa y esto produce retroalimentacin del
mercado. Por lo tanto, el Product Backlog cada vez llega a ser una lista muy grande y
exhaustiva. Los requisitos no dejan de cambiar, por lo que el Product Backlog se
convierte en un artefacto con vida.
Los requisitos cambian de acuerdo a los cambios del negocio, del mercado y de la
tecnologa.

Orden en el Product Backlog

Ejemplo de Product Backlog

Backlog item

Estimacin

Permitir que un invitado a hacer una reserva.

Como invitado, quiero cancelar una reserva.

Como invitado, quiero cambiar las fechas de

una reserva.

Como un empleado de hotel, puedo ejecutar

informes de los ingresos por habitacin
disponible

Mejorar el manejo de excepciones

...

30

...

50

Ejemplo de Product Backlog

Historias de usuario = tems Product Backlog

Ms ejemplos de historias de usuario

Y ms ejemplos HU

Ejemplos de HU

Mas ejemplos de historias de usuario

Ms ejemplos de historias de usuario (2)

Product Backlog con prioridades y

estimaciones

Product Backlog Grooming

El refinamiento del Product Backlog (grooming) es el acto de aadir
detalles, estimar y ordenar los tems en el Product Backlog.
Es un proceso continuo en el cual el Product Owner y el Equipo
colaboran en detallar los tems del Product Backlog. Sin embargo, el
Product Owner los puede cambiar, en cualquier momento.
El refinamiento se realiza durante el Sprint, aunque el Scrum Team
debe decidir cmo y cundo hacerlo.
El Equipo es responsable por todas las estimaciones. Aunque el
Producto Owner puede influir ayudando a entender la complejidad de
cada tem.

Monitorear el progreso hacia la meta

El trabajo restante debe ser examinado. El Product Owner hace
seguimiento al trabajo faltante con vista al Sprint Review. El Product
Owner compara esta cantidad con el trabajo restante en un previo
Sprint Review para evaluar el progreso y completar el trabajo en el
tiempo deseado. Esta informacin es transparente para todo el
personal.
Se usan diagramas de burndown o burnup para predecir el progreso
debido a su gran utilidad. La experiencia tambin juega un papel muy
importante para este monitoreo.

Grfico Burn - Down

Sprint Backlog
Es el conjunto de tems seleccionados del Product Backlog para
desarrollarse durante el Sprint adems de un plan de entrega del
producto y la realizacin del objetivo del Sprint.
Sprint Backlog es la funcionalidad o que el Team debe desarrollar
durante el Sprint.
Sprint Backlog define el trabajo a desarrollar por el Team para
convertir los tems del Product Backlog en un Incremento Done
Sprint Backlog es un plan bastante detallado que cambia a medida
que se comprende mejor durante el Daily Scrum. El Team modifica el
Sprint Backlog durante el Sprint y el Sprint Backlog surge durante el
Sprint.

Sprint Backlog (2)

Si se requiere un nuevo trabajo, el Team lo aade al Sprint Backlog
Cuando un trabajo es ejecutado o terminado, se actualiza la
estimacin de lo restante.
Si los elementos de un plan se consideran innecesarios, se eliminan.
Solo el Team puede cambiar el Sprint Backlog, durante el Sprint.
Sprint Backlog es una imagen visible y en tiempo real del trabajo que
el Team ha planeado llevar a cabo durante el Sprint.
Sprint Backlog solo pertenece al Team.

Ejemplo de Sprint Backlog

Tareas
Codificar UI
Codificar negocio
Testear negocio
Escribir ayuda online
Escribir la clase foo
Agregar error logging

16

12

10

16

16

11

12
8

Ejemplo de Sprint Backlog

Ejemplo de tarea a partir de Historia Usuario

Monitorear progreso del Sprint

Se puede examinar el trabajo restante en el Sprint Backlog.
El Team hace seguimiento del trabajo restante en las reuniones
diarias para pronosticar la probabilidad de alcanzar el Sprint Goal.
Al hacer el seguimiento, el equipo gestiona su progreso.
Scrum no toma en cuenta el tiempo gastado en desarrollar los tems
del Sprint Backlog. El trabajo restante y la fecha son las nicas
variables de inters.

Tablero de mando - Kanban

Hours

Un Sprint Burndown Chart

Tareas

Codificar UI
Codificar Negocio
Testear Negocio
Escribir ayuda online

16

12

10

16

16

11

12

50
40
30

Hours

20
10
0

Mon

Tue

Wed

Thu

Fri

Incremento
El incremento es la suma de todos los tems del Product Backlog
terminados durante el Sprint y en todos los Sprints previos.
Al final del Sprint, el nuevo incremento deber ser Done, lo que
significa que debe ser usable y debe cumplir con las condiciones de la
definicin de Done establecidos por el Scrum Team, a menos que el
Product Owner decida liberarlo tal cual.

Definicin de Done
Todo el Scrum Team debe entender de la misma forma el concepto de
Done para asegurar transparencia
El concepto de Done es usado para garantizar que el trabajo est
completo para ser el Incremento del producto
Esta definicin gua al Team en conocer cuntos tems del Product Backlog
puede seleccionar durante la reunin de Sprint Planning.
El propsito de cada Sprint es entregar Incrementos que cumplan la
definicin de Done. Cada incremento debe ser usable. Cada incremento
es adicionado a los incrementos anteriores a travs de pruebas exhaustivas
para asegurar que todos los incrementos trabajan juntos.
A medida que el Scrum Team madura, el concepto de Done se vuelve
mas amplio y riguroso para conseguir mayor calidad.

Conclusin
Scrum es libre de usar.
Los roles, artefactos, reuniones y reglas de Scrum son INMUTABLES y
aunque se puede aplicar parte de Scrum, el resultado NO ES SCRUM
Scrum solo existe con todos sus elementos y funciones y tambin
como contenedor de otras tcnicas, mtodos y prcticas.

Bibliografa
Sebastin Priolo, Mtodos giles, Ed. Banfield, 2009
Wikipedia, SCRUM, mayo 2012
Jeff Sutherland, Ken Schwaber, The SCRUM GUIDE: The rules of the game,
October 2011.
Manuel Trigas Gallego, Ana Cristina Domingo Troncho, Metodologa
SCRUM Desarrollo detallado de la fase de aprobacin de un proyecto
informtico mediante metodologas giles, Curso Gestin de proyectos
Informticos,
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtriga
sTFC0612memoria.pdf (septiembre 2014)
Jorge Abad, Introduccin a SCRUM, diapositivas, 2015.