SCRUM

ESCUELA PROFESIONAL DE
INGENIERÍA DE SISTEMAS Y
TELEMÁTICA
CURSO : Gestión de Sistemas Informáticos.
DOCENTE : Ing. PORRO CHULLI , Marco Aurelio.
TEMA : SCRUM.
ESTUDIANTES :
AGUILAR CABRERA, Yosmer.
OCAÑA BUENO, Lisbeth.
CICLO : X
GRUPO : “A”
Bagua Grande, abril del 2019.

UNIVERSIDAD POLITÉCNICA AMAZÓNICA
ÍNDICE:
SCRUM………………………………………………………………………………………………………………………….1
1 Definición: ..................................................................................................................................................... 1
2 Caracteristicas: ............................................................................................................................................ 2
3 Beneficios: ..................................................................................................................................................... 3
4 Fases: ............................................................................................................................................................... 4
5 Roles: ............................................................................................................................................................... 5
6 Sprint:.............................................................................................................................................................. 6
7 Documentos de scrum:............................................................................................................................. 7
8 Resumen: ....................................................................................................................................................... 8
9 Summary:.................................................................................................................................................... 19
10 Conclusiones: ............................................................................................................................................ 28
11 Recomendaciones: .................................................................................................................................. 29
12 Apreciacion del equipo: ........................................................................................................................ 30
13 Glosario de términos: ............................................................................................................................ 31
14 Linkografia: ................................................................................................................................................ 32
Ingeniería de Sistemas y Telemática. i

SCRUM
1 DEFINICIÓN:
Es un proceso de la Metodología Ágil que se usa para minimizar los riesgos durante la
realización de un proyecto, pero de manera colaborativa.
Es ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es
maximizar el retorno de la inversión para su empresa (ROI).
Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los
principios de inspección continua, adaptación, auto-gestión e innovación.
Se suele planificar por semanas. Al final de cada Sprint o iteración, se va revisando el
trabajo validado de la anterior semana. En función de esto, se priorizan y planifican
las
actividades en las que invertiremos nuestros recursos en el siguiente Sprint.
Scrum se centra en ajustar sus resultados y responder a las exigencias reales y exactas
del cliente. De ahí, que se vaya revisando cada entregable, ya que los requerimientos
van variando a corto plazo. El tiempo mínimo para un Sprint es de una semana y el
máximo es de cuatro semanas.
Entre las ventajas que brinda Scrum se encuentran la productividad, calidad y que se
realiza un seguimiento diario de los avances del proyecto, logrando que los integrantes
estén unidos, comunicados y que el cliente vaya viendo los avances.
Ingeniería de Sistemas y Telemática.

1
2 CARACTERISTICAS:
❖ Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos,

prácticas de desarrollo, implementación y demás cuestiones técnicas.
❖ Hace uso de Equipos auto-dirigidos y auto-organizados.
❖ Puede ser aplicado teóricamente a cualquier contexto en donde un grupo de
gente necesita trabajar junta para lograr una meta común.
❖ Desarrollo de software iterativos incrementales basados en prácticas agiles.
❖ Iteraciones de treinta días; aunque se pueden realizar con más frecuencia, estas
iteraciones, conocidas como Sprint.
❖ Dentro de cada Sprint se denomina el Scrum Master al Líder de Proyecto quien
llevará a cabo la gestión de la iteración.
❖ Se convocan diariamente un “Scrum Daily Meeting” el cual representa una
reunión de avance diaria de no más de 15 minutos con el propósito de tener
realimentación sobre las tareas de los recursos y los obstáculos que se presentan.
En la cual se responden preguntas como: ¿Qué has hecho desde el último
encuentro? ¿Qué obstáculos hay para cumplir la meta? ¿Qué harás antes del
próximo encuentro?

2
3 BENEFICIOS:
▪ Cumplimento de Expectativas: El cliente establece sus expectativas indicando el

valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con
esta información el Product Owner establece su prioridad. De manera regular, en
las demos de Sprint el Product Owner comprueba que efectivamente los requisitos
se han cumplido y transmite se feedback al equipo.
▪ Flexibilidad a Cambios: Alta capacidad de reacción ante los cambios de
requerimientos generados por necesidades del cliente o evoluciones del mercado.
La metodología está diseñada para adaptarse a los cambios de requerimientos que
conllevan los proyectos complejos.
▪ Reducción del Time to Market: El cliente puede empezar a utilizar las
funcionalidades más importantes del proyecto antes de que esté finalizado por
completo.
▪ Mayor Calidad del Software: La metódica de trabajo y la necesidad de obtener
una versión funcional después de cada iteración, ayuda a la obtención de un
software de calidad superior.
▪ Mayor Productividad: Se consigue entre otras razones, gracias a la eliminación
de la burocracia y a la motivación del equipo que proporciona el hecho de que sean
autónomos para organizarse.

3
▪ Maximiza el Retorno de la Inversión (ROI): Producción de software únicamente

con las prestaciones que aportan mayor valor de negocio gracias a la priorización
por retorno de inversión.
▪ Predicciones de Tiempos: Mediante esta metodología se conoce la velocidad
media del equipo por sprint (los llamados puntos historia), con lo que
consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una
determinada funcionalidad que todavía está en el Backlog.
▪ Reducción de Riesgos: El hecho de llevar a cabo las funcionalidades de más valor
en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto,
permite despejar riesgos eficazmente de manera anticipada.
4 FASES:
A. Planteamiento: Un proyecto gestionado ajo el modelo SCRUM parte de los

objetivos que han trazado con anterioridad el cliente y la empresa. Lo primero es
fraccionarlo en entregas parciales, de manera que el cliente pueda replantear
aspectos a los que en principio no prestó la importancia debida o que simplemente
desconocía. Esos aspectos pueden ser sobre costes, estrategias, producción, etc.
B. Lista de Tareas: El equipo de trabajo elabora la lista de tareas que debe tener en
cuenta para cada entrega de resultados. Es muy importante hacer una estimación
del esfuerzo requerido para, de esta manera, fijas plazos proporcionados.
C. Reuniones: Lo ideal es que cada día el equipo dedique 15 minutos para reunirse y
ponerse al tanto de la evolución del plan. En estas sesiones, el líder del proyecto
(Scrum Master) debe encargarse de que cada miembro cumpla con las labores que
le han sido asignadas y de motivarles para que su productividad no descienda. En

4
caso de que detecte alguna incidencia dentro del grupo, es necesario que tome las
opciones más adecuadas, que pueden ir desde un relevo de la función hasta el
nombramiento de miembros de apoyo.
D. Demostración: Una vez ejecutadas las labores de cada fase, el equipo se reúne con
el cliente para mostrar los avances correspondientes. El cliente decide si replantea
los elementos del proyecto. Si es necesario, el equipo asume nuevos compromisos.
E. Retrospectiva: Los miembros del equipo se reúnen para valorar el proceso de
entrega de resultados y analizan los factores que podrían mejorar de cara al final
del proceso. La función del Scrum Master será eliminar dichos obstáculos.
5 ROLES:
A. Principales:
✓ Product Owner: El Product Owner se asegura de que el equipo Scrum trabaje
de forma adecuada desde la perspectiva del negocio. El Product Owner ayuda
al usuario a escribir las historias de usuario, las prioriza, y las coloca en el
Product Backlog.
✓ ScrumMaster o Facilitador: El Scrum es facilitado por un ScrumMaster,
cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo
alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque
ellos se auto-organizan), sino que actúa como una protección entre el equipo y
cualquier influencia que le distraiga. El ScrumMaster se asegura de que el
proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que
las reglas se cumplan.
✓ Team o Equipo de Desarrollo: El equipo tiene la responsabilidad de entregar
el producto. Es recomendable un pequeño equipo de 5 a 9 personas con las

5
habilidades transversales necesarias para realizar el trabajo (análisis, diseño,

desarrollo, pruebas, documentación, etc.).
B. Auxiliares:
Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol
formal y no se involucran
frecuentemente en el "proceso Scrum", sin embargo, deben ser tomados en cuenta.
Un aspecto importante
de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios,
expertos del negocio y
otros interesados ("stakeholders"). Es importante que esa gente participe y
entregue retroalimentación con
respecto a la salida del proceso a fin de revisar y planear cada sprint.
✓ Stakeholders: Son las personas que hacen posible el proyecto y para quienes
el proyecto producirá el beneficio acordado que justifica su desarrollo. Sólo
participan directamente durante las revisiones del "sprint".
✓ Managers o Administradores: Son los responsables de establecer el entorno
para el desarrollo del proyecto.
6 SPRINT:
Es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración

de los Sprints sea constante y definida por el equipo con base en su propia experiencia.
Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir
ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado.
Al final de cada sprint, el equipo deberá presentar los avances logrados, y el resultado
obtenido es un producto que, potencialmente, se puede entregar al cliente.

6
Así mismo, se recomienda no agregar objetivos al sprint o sprint backlog a menos que su
falta amenace al éxito del proyecto. La constancia permite la concentración y mejora la
productividad del equipo de trabajo.
Debemos recordar que los Sprint es la herramienta que usa Scrum, por lo tanto, maneja
las mismas fases:
• Reunión de planificación de Sprint.
• El Scrum Diario.
• Trabajo de desarrollo durante el Sprint.
• Revisión del Sprint.
• Retrospectiva del Sprint.
7 DOCUMENTOS DE SCRUM:
A. Product Backlog: Se trata como un documento de alto nivel para todo el proyecto. Es
el conjunto de todos los requisitos de proyecto, el cual contiene descripciones
genéricas de funcionalidades deseables, priorizadas según su retorno sobre la inversión
(ROI). Representa el qué va a ser construido en su totalidad. Es abierto y solo puede
ser modificado por el Product Owner. Contiene estimaciones realizadas a grandes
rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta
estimación ayuda al Product Owner a ajustar la línea temporal (KEV) y, de manera
limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen
el mismo valor de negocio la que requiera menor tiempo de desarrollo tendrá
probablemente más prioridad, debido a que su ROI será más alto.
B. Sprint Backlog: Es el subconjunto de requisitos que serán desarrollados durante el
siguiente sprint. Al definir el sprint backlog, se describe el cómo el equipo va a

7
implementar los requisitos durante el sprint. Por lo general los requisitos se subdividen
en tareas, a las cuales se asignan ciertas horas de trabajo, pero ninguna tarea con una
duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en
otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por
los miembros del equipo del modo que les parezca adecuado.
C. Burn Down Chart: Es una gráfica mostrada públicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.
Dibujando una línea que conecte los puntos de todos los Sprints completados,
podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente
(en casos en que todo va bien en el sentido de que los requisitos están bien definidos
desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual
el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en
el Backlog).
Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente
en determinados segmentos, y si se modifican algunos requisitos la pendiente variará
o incluso valdrá cero en algunos tramos.
8 RESUMEN:
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas
prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible
de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un
estudio de la manera de trabajar de equipos altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener resultados
pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la
competitividad, la flexibilidad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente
lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la
calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia,
cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar
y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un
proceso especializado en el desarrollo de producto.

8
Scrum es el marco de trabajo Ágil más conocido y difundido para el desarrollo de

software.
PRINCIPIOS:
Valores del Manifiesto Ágil:
Scrum es el marco de trabajo Ágil más conocido. Es la fuente de muchos de los valores
y principios detrás del Manifiesto Ágil, el cuál forma un ámbito común para todos estos
enfoques. Pueden leer el Manifiesto Ágil para tener más información.
Los valores del Manifiesto Ágil aplican directo a Scrum:
• Los individuos y sus interacciones por sobre los procesos y las herramientas.
Scrum, como estos marcos y métodos Ágiles, se basa en la confianza en los equipos,
los individuos en los equipos, y la forma en la cual interactúan. Los equipos
descubren lo que tiene que hacerse, cómo hacerlo, y lo hacen. Los equipos identifican
qué cosas se interponen en su camino, y asumen la responsabilidad de resolver todas
las dificultades que estén dentro de su alcance. Los equipos trabajan con otras partes
de la organización para resolver los temas que están fuera de su control. Esto es
crítico. Si intentan aplicar Scrum, pero le quitan el foco a la responsabilidad del
equipo generalmente va a generar problemas.
• Software que funciona por sobre la documentación exhaustiva. Scrum requiere
que el principal resultado de cada Sprint sea el incremento terminado del producto.
Obviamente que habrá tareas de análisis, de diseño, de testing, y todo esto se
documentará. Pero lo que guía el éxito del proyecto es el software que funciona. Esto
es crítico. Los equipos de Scrum tienen que producir un incremento del producto en
cada Sprint.
• La colaboración con el cliente por sobre la negociación contractual. El Dueño
del Producto es el punto principal de contacto entre el Equipo de Scrum y los
eventuales usuarios finales del producto, y con las partes de la organización que
necesitan el producto. El Dueño del Producto es un miembro del equipo que trabaja
colaborativamente con el equipo para determinar lo que necesita hacerse. En esta
colaboración, el Dueño del Producto selecciona las siguientes cosas más valiosas a
realizar, y se asegura que el producto sea lo más valioso posible hasta ese punto en
el tiempo. Esto es crítico. El Dueño del Producto necesita construir una colaboración
rica con sus equipos.

9
• Adaptarse al cambio por sobre seguir un plan. Todo lo relativo a Scrum está
diseñado para asegurarse que todos tengan la información que necesitan para tomar
buenas decisiones sobre el proyecto. El avance del proyecto se representa por un
incremento del producto real y funcionando. El backlog de las cosas a realizar está
disponible para que todos lo vean. El avance, tanto del sprint como del proyecto en
su totalidad, está visible de forma clara. Los problemas y los riesgos se discuten
abiertamente y se los trata de forma inmediata. Esto es crítico. Scrum funciona bien
en aquellos equipos que abiertamente "inspeccionan" lo que ocurre y “adaptan" sus
acciones a la realidad. Y funciona mal para los equipos que no logran esto.
VALORES DE SCRUM:
Todo el trabajo que se realiza en Scrum necesita una base firme de valores que sirvan
como fundación para los procesos y principios del equipo. Usando el trabajo en equipo y
la mejora continua, Scrum crea estos valores y los utiliza. Los valores son Foco, Coraje,
Transparencia, Compromiso y Respeto.
• Foco. Como nos enfocamos en solo unas pocas cosas a la vez, trabajamos bien juntos
y producimos un trabajo excelente. Entregamos elementos valiosos antes.
• Coraje. Como no estamos solos, nos sentimos apoyados y tenemos más recursos a
nuestra disposición. Esto nos brinda coraje para superar grandes desafíos.
• Transparencia. Mientras trabajamos juntos, nos contamos cómo nos está yendo, y
qué cosas se nos interponen en el camino. Aprendemos que es bueno expresar las
preocupaciones, para que puedan resolverse.
• Compromiso. Como tenemos control sobre nuestro propio destino, nos
comprometemos más a tener éxito.
• Respeto. Mientras trabajamos juntos, compartimos éxitos y fracasos, nos respetamos
mutuamente, y nos ayudamos a ser merecedores del respeto.
Si una organización deja que Scrum haga su trabajo, va a descubrir los beneficios de
Scrum y comenzará a comprender por qué estos valores son necesarios y usados por
Scrum.
EL MARCO DE TRABAJO DE SCRUM:
Scrum es un marco de trabajo para construir productos. Scrum comienza cuando algún
interesado necesita un producto.
Scrum es un proceso de equipo. El Equipo de Scrum incluye 3 roles: El Dueño del
Producto, el ScrumMaster, y los miembros del Equipo de Desarrollo. El Dueño del

10
Producto tiene la responsabilidad de decidir qué trabajo necesita hacerse. El ScrumMaster

actúa como un líder servicial, ayudando al equipo y a la organización a usar lo mejor
posible a Scrum. El Equipo de Desarrollo construye el producto incrementalmente, en
una serie de periodos de tiempo pequeños llamados Sprints. Un Sprint es un periodo de
tiempo de duración fija, de 1 a 4 semanas, con preferencia por los intervalos más cortos.
En cada Sprint, el Equipo construye y entrega un Incremento del Producto. Cada
incremento es un subconjunto del producto, reconocible y visualmente mejorado, que
cumple con el criterio de aceptación y está construido con un nivel de calidad llamada
Definición de Terminado.
Scrum incluye 3 artefactos esenciales: el Backlog del Producto, el Backlog del Sprint, y
el Incremento del Producto. El Backlog del Producto es una lista ordenada de ideas para
el producto, ordenada según cómo se espera sean construidas. El Backlog del Sprint es
un plan detallado para el desarrollo del próximo Sprint. El Incremento del Producto es el
resultado requerido de cada Sprint. Es una versión integrada del producto, mantenida con
una calidad lo suficientemente alta como para ponerse en producción si el Dueño del
Producto lo deseara. Además de estos artefactos, Scrum quiere transparencia dentro del
equipo y con los interesados. Por lo tanto, el Equipo de Scrum genera muestras visibles
de su planificación y progreso.
Scrum incluye 5 Actividades o Reuniones: la Definición del Backlog del Producto, la
Planificación del Sprint, el Scrum Diario, la Demo del Sprint, y la Retrospectiva.
A continuación, describiremos los roles, artefactos y actividades.
ROLES DE SCRUM:
Rol: Dueño del Producto:
El Dueño del Producto es un único individuo responsable por lograr el mayor valor
posible del producto para una fecha deseada. Esto lo logra gestionando el flujo del trabajo
del equipo, seleccionando y refinando los elementos del Backlog del Producto. El Dueño
del Producto mantiene el Backlog del Producto y se asegura que todos conozcan lo que
está ahí y las prioridades. El Dueño del Producto puede recibir ayuda de otras personas,
pero debe ser una sola persona.
Obviamente que el Dueño del Producto no es el único responsable de todo. El equipo
completo de Scrum es responsable por ser lo más productivo posible, por mejorar sus
prácticas, por realizar las preguntas adecuadas, por ayudar el Dueño del Producto, etc. El
Equipo de Desarrollo es responsable en determinar cuánto trabajo van a tomar para un
Sprint, y en producir un Incremento del Producto usable en cada Sprint.

11
Igualmente, el Dueño del Producto, es Scrum, se encuentra en una posición única. El

Dueño del Producto es quien suele estar más cerca del "costado de negocio" del proyecto.
El Dueño del Producto generalmente es quien fue encargado por la organización para
"entregar el producto", y usualmente es quien debe satisfacer lo mejor posible a las
necesidades de todos los interesados. El Dueño del Producto logra esto gestionando el
Backlog del Producto, y asegurándose que este backlog, y el progreso, sean visibles.
El Dueño del Producto, como elige en qué va a trabajar el Equipo de Desarrollo a
continuación, es quien toma las decisiones de alcance vs. fechas para lograr el mejor
producto posible.
Rol: Miembro del Equipo de Desarrollo:
El Equipo de Desarrollo está compuesto de profesionales que realizan el trabajo de
entregar Incrementos del Producto. Se auto-organizan para lograr este trabajo. Se espera
que los miembros del Equipo de Desarrollo estén disponibles durante todo el proyecto a
tiempo completo.
Scrum requiere que el Equipo de Desarrollo sea multi-disciplinario para que, entre ellos,
posean todas las habilidades necesarias para realizar la entrega incremental del producto.
Los miembros del Equipo de Desarrollo son responsables en auto-organizarse para lograr
el objetivo del Sprint, y producir un nuevo Incremento del Producto de acuerdo a la
Planificación del Sprint.
El Dueño del Producto realiza una lista ordenada de lo que necesita hacerse. Los
miembros del Equipo de Desarrollo estiman cuánto podrán completar en un Sprint, y
luego deciden cómo van a lograrlo.
Rol: ScrumMaster:
El ScrumMaster es un "líder servicial", que ayuda al resto del Equipo de Scrum a seguir
el proceso. El ScrumMaster necesita tener una buena comprensión del marco de Scrum,
y debe tener la habilidad de entrenar a otras personas en los detalles de Scrum.
El ScrumMaster trabaja junto al Dueño del Producto para ayudarlo a comprender cómo
crear y mantener el Backlog del Producto. Trabaja con el Equipo de Desarrollo para
encontrar e implementar prácticas técnicas que le permitan terminar las cosas al final de
cada Sprint. Trabaja con todo el Equipo de Scrum para evolucionar la Definición de
Terminado.
Otra responsabilidad del ScrumMaster es verificar que se vayan eliminando los
impedimentos del equipo. Estos impedimentos pueden ser externos al equipo, como la

12
falta de apoyo de otro equipo, o internos, como ser que el Dueño del Producto no sepa
cómo preparar adecuadamente un Backlog de Producto.
El ScrumMaster fomenta la auto-gestión. Los problemas deben ser resueltos por el equipo
en la medida de lo posible.
El ScrumMaster actúa como un coach del Equipo de Scrum, ayudándolo a ejecutar el
proceso de Scrum. Los ayuda a trabajar juntos y a aprender el marco de Scrum, y los
protege de distracciones internas y externas. Puede facilitar reuniones, y ayuda a mantener
el rumbo del Equipo de Scrum, a que sea productivo y adquiera habilidades.
El ScrumMaster es responsable por garantizar que se comprenda y aplique correctamente
Scrum, dentro del equipo y fuera del mismo. Ayuda a que las personas fuera del equipo
comprendan el proceso, y entiendan qué interacciones con el equipo serán útiles y cuáles
no. El ScrumMaster ayuda a que todos puedan mejorar, haciendo que el Equipo de Scrum
sea más productivo y valioso.
ARTEFACTO DE SCRUM:
Backlog del Producto:
El Backlog del producto es un artefacto esencial en Scrum. El Backlog del Producto es
una lista ordenada de ideas para el producto, en el orden que esperamos deban terminarse.
Es un lugar único en donde fluyen todos los requerimientos. Esto significa que todo el
trabajo que hace el Equipo de Desarrollo proviene del Backlog del Producto. Cada idea,
cada característica, cada mejora, cada bug, cada requerimiento de documentación - todo
el trabajo que sea hace - está derivado de algún elemento del Backlog del Producto. Cada
elemento del Backlog del Producto incluye una descripción y una estimación.
El Backlog del Producto puede empezar como una lista grande o corta. Puede ser poco o
muy detallado. Usualmente comienza siendo poco detallado y corto, y se va volviendo
más grande y concreto con el tiempo. Los elementos del Backlog del Producto elegidos
para la implementación pronto serán "refinados": clarificados, mejor definidos, separados
en partes más pequeñas, todo esto como parte de las actividades del Refinamiento del
Backlog del Producto.
El Dueño del Producto es el responsable por mantener el Backlog del Producto, aunque
el Dueño del Producto puede (y debería) buscar ayuda para crearlo y mantenerlo
actualizado. Los elementos del Backlog del Producto pueden originarse del Dueño del
Producto, de los miembros del equipo, o de otros interesados.

13
ACTIVIDADES DEL SCRUM:

Refinamiento del Backlog del Producto:
Como los elementos del Backlog del Producto suelen ser grandes y generales, y como las
ideas van y vienen y las prioridades cambian, el Refinamiento del Backlog del Producto
es una actividad que ocurre durante todo el proyecto de Scrum. Esta actividad incluye
(pero no está limitada a):
mantener ordenado el Backlog del Producto eliminar ideas que ya no son importantes
agregar o promover elementos que surgen o se vuelven importantes dividir elementos en
elementos más pequeños unir elementos en elementos más grandes estimar elementos
Un beneficio clave de la actividad de Refinamiento del Backlog del Producto es
prepararse para los próximos Sprint. Para lograr esto, la actividad de refinamiento le
brinda especial atención a preparar los elementos que están próximos a implementarse.
Hay varias cosas a considerar, incluyendo:
Cada elemento que entra en un Sprint debería representar un incremento en el "valor de
negocio".
El Equipo de Desarrollo necesita poder construir cada elemento en un único Sprint.
Todos necesitan tener en claro lo que se quiere.
Dependiendo en la naturaleza del producto, se podrían necesitar otras habilidades. En
cualquier caso, el Refinamiento del Backlog del Producto es una actividad para todos los
miembros del equipo, y no sólo para el Dueño del Producto.
Planificación del Sprint:
Cada Sprint comienza con una reunión acotada en tiempo llamada Planificación del
Sprint. En esta reunión el Equipo de Scrum colabora para seleccionar y comprender el
trabajo a realizar en el Sprint que comienza.
El equipo completo está presente en la reunión de Planificación del Sprint. Se trabaja con
el Backlog del Producto ordenado. El Dueño del Producto y los Miembros del Equipo de
Desarrollo discuten cada elemento y llegan a un entendimiento sobre qué se necesita para
completar cada elemento, de manera de ser consistentes con la Definición de Terminado.
Todas las reuniones de Scrum son acotadas en tiempo. La duración recomendada para la
reunión de Planificación del Sprint es de menos de 2 horas por cada semana que dure el
Sprint. Como esta reunión está acotada en tiempo, el éxito de la reunión de Planificación
del Sprint depende en gran medida de la calidad del Backlog del Producto. Es por esto
que resulta muy importante la actividad de Refinamiento del Backlog del Producto.
En Scrum, la reunión de Planificación del Sprint tiene 2 partes:

14
✓ Determinar qué trabajo se completará en el Sprint.

✓ Determinar cómo se realizará este trabajo.
¿qué trabajo se realizará?
En la primera parte de la reunión, el Dueño del Producto le presenta al Equipo de
Desarrollo los elementos ordenados del Backlog del Producto. Para decidir cuántos
elementos se realizarán, el Equipo de Desarrollo considera el estado actual del Incremento
del Producto, el rendimiento anterior del equipo, la capacidad actual del equipo, y el
Backlog de Producto ordenado. El Equipo de Desarrollo es el único que decide cuánto
trabajo tomarán. Ni el Dueño del Producto ni ninguna otra agencia pueden empujarle más
trabajo al Equipo de Desarrollo.
A menudo, pero no siempre, el Sprint tiene un objetivo, que se llama Objetivo del Sprint.
Esta es una práctica recomendable que ayuda a enfocarse en la esencia de lo que necesita
hacerse, y quita foco de los detalles que pueden no ser tan importantes.
¿cómo se realizará el trabajo?
En la segunda parte de la reunión, el Equipo de Desarrollo colabora para decidir cómo
producir el próximo Incremento del Producto de acuerdo con la Definición de Terminado
actual. Realizan el diseño y la planificación suficientes para estar seguros de poder
terminar el trabajo durante el Sprint. El trabajo a realizar durante los primeros días se
divide en unidades más pequeñas de 1 día o menos. El trabajo a realizar más trade puede
dejarse en unidades más grandes para separar después.
Así como el Dueño del Producto es responsable por decidir qué se va a hacer, el Equipo
de Desarrollo es el responsable en determinar cómo realizar el trabajo.
El Dueño del Producto puede permanecer durante esta parte de la reunión, para responder
preguntas y dudas. En cualquier caso, siempre necesita estar disponible para el Equipo de
Desarrollo.
Resultado de la Planificación del Sprint:
La Planificación del Sprint concluye cuando el Equipo de Scrum llega a comprender la
cantidad y complejidad de lo que se logrará durante el Sprint, y lo que espera poder
terminar (dentro de algún margen racional de circunstancias). El Equipo de Desarrollo
estima la cantidad de trabajo que podrá completar y se compromete a completarlo.
Para resumir, durante la reunión de Planificación del Sprint, el Equipo de Desarrollo:
considera y discute los elementos del Backlog del Producto con el Dueño del Producto
se asegura de comprender los elementos del Backlog del Producto
selecciona una cantidad de elementos que estiman poder terminar,

15
y crean un plan lo suficientemente detallado para asegurarse que puedan completar estos
elementos.
La lista resultante de estos elementos a realizar es el "Backlog del Sprint".
Artefacto: Backlog del Sprint:
El Backlog del Sprint es la lista de los elementos del Backlog del Producto, elegidos para
ser desarrollador en el Sprint actual, junto con el plan del equipo para lograr el trabajo.
Refleja la estimación del equipo del trabajo que puede completarse.
Con el Backlog del Sprint determinado, el Sprint comienza, y el Equipo de Desarrollo
crea el nuevo Incremento del Producto definido por el Backlog del Sprint.
Desarrollo:
Durante el Sprint, el Equipo de Desarrollo se auto-gestiona para producir un Incremento
del Producto de acuerdo al Backlog del Sprint, el cual fue determinado durante la
Planificación del Sprint. La auto-gestión significa que el equipo es responsable de
producir el Incremento del Producto conforme a los estándares de la organización,
conforme a la Definición de Terminado, y que el Equipo de Desarrollo determina cómo
lograr esto.
Artefacto: Incremento del Producto:
El artefacto más importante de Scrum es el Incremento del Producto. Cada Sprint produce
un Incremento del Producto. El Incremento del Producto debe tener la suficiente calidad
para ser entregado a los usuarios finales. El Incremento del Producto tiene que cumplir
con la Definición de Terminado del Equipo de Scrum, y cada componente debe ser
aceptado por el Dueño del Producto.
Indicadores adicionales visibles de avance:
Scrum requiere que transparencia dentro y fuera del equipo. Aunque el Incremento del
Producto es la forma más importante de crear transparencia, el Equipo de Scrum creará
cualquier otro artefacto que necesita para asegurarse que se comprenda el estado del
proyecto. Los gráficos de burndown y los tableros de tareas son artefactos adicionales
muy comunes.
Acuerdo: Definición de Terminado:
Cuando se entrega el Incremento del Producto, necesita estar "terminado" según lo
acordado que signifique "terminado". Esta definición es diferente para cada Equipo de
Scrum, y a medida que madura el equipo, la Definición de Terminado se expandirá para
ser más precisa.

16
La Definición de Terminado siempre debe incluir la noción de que el Incremento del

Producto tiene la calidad necesaria para que sea productivo: el Dueño del Producto
debería poder elegirlo para liberarlo inmediatamente. El Incremento del Producto incluye
la funcionalidad de todos los Incrementos del Producto anteriores, y está completamente
testeado de manera que todos los elementos del Backlog del Producto continúan
funcionando juntos.
Actividad: Scrum Diario:
El Equipo de Desarrollo es auto-gestionado. El Equipo de Desarrollo utiliza la reunión de
Scrum Diario para asegurarse que están en el camino indicado para lograr el Objetivo del
Sprint. La reunión ocurre a la misma hora y en el mismo lugar, todos los días. Cada
miembro del Equipo de Desarrollo responde 3 preguntas:
¿Qué logré desde nuestro último Scrum Diario?
¿Qué espero lograr entre hoy y el próximo Scrum Diario?
¿Qué está impidiendo mi avance?
Pueden ocurrir algunas preguntas breves para clarificar, pero no hay discusiones de
ningún tema durante el Scrum Diario. Sin embargo, muchos equipos se juntan justo
después del Scrum Diario para trabajar en cualquier tema que hubiera surgido.
El Scrum Diario no es un reporte para la gerencia, ni para el Dueño del Producto, ni para
el ScrumMaster. Es una reunión de comunicación dentro del Equipo de Desarrollo, para
asegurar que están todos sincronizados. Sólo los miembros del Equipo de Scrum,
incluyendo el ScrumMaster y el Dueño del Producto, pueden hablar durante esta reunión.
Otras partes interesadas pueden asistir a escuchar. Basados en lo que salga durante la
reunión, el Equipo de Desarrollo reorganiza el trabajo que necesita completarse para
alcanzar el Objetivo del Sprint.
El Scrum Diario es clave para Scrum, lleva a la transparencia, genera confianza, y brinda
mejor rendimiento. Logra que los problemas se descubran rápido, y promueve la auto-
gestión del equipo y la confianza. Todas las reuniones de Scrum están acotadas en tiempo.
La duración recomendada para el Scrum Diario es de no más de 15 minutos.
Actividad: Demo del Sprint:
Al final del Sprint, el Equipo de Scrum y los interesados revisan lo producido en el Sprint.
Todas las reuniones de Scrum son acotadas en tiempo. La duración recomendada para la
Demo Sprint es de 1 hora por semana de duración del Sprint.
El punto central de la discusión es el Incremento de Producto terminado durante el Sprint.
Dado que los interesados son aquellos que están "involucrados" en los resultados,

17
generalmente resulta útil que participen de esta reunión. Es una reunión informal, para
compartir en dónde estamos y colaborar sobre cómo podemos avanzar. Todos pueden
participar de la Demo del Sprint. Naturalmente, el Dueño del Producto es quien toma la
decisión final sobre el futuro, y actualiza el Backlog del Producto de manera apropiada.
Los equipos encuentran su propia manera de hacer una Demo del Sprint. Es común hacer
una demostración del Incremento del Producto. El grupo a menudo discute lo que
observaron durante el Sprint, y las ideas del producto que aparecen. Discuten el Backlog
del Producto y hablan sobre las fechas posibles para terminar, y lo que puede hacerse
sobre esas fechas.
La Demo del Sprint les brinda a todos los presentes una forma de conocer el Incremento
del Producto vigente. También, es común actualizar el Backlog del Producto como parte
de la Demo del Sprint.
Actividad: Retrospectiva del Sprint:
Al final de cada Sprint, el Equipo de Scrum se junta para la Retrospectiva. El propósito
es revisar cómo fueron las cosas con respecto al proceso, a las relaciones entre las
personas, y a las herramientas. El equipo identifica lo que salió bien y lo que no salió tan
bien, e identifica mejoras posibles. Arman un plan para mejorar las cosas en el futuro.
Todas las reuniones de Scrum están acotadas en tiempo. La duración recomendada para
la Retrospectiva del Sprint es de 1 hora por semana de duración del Sprint.
El Equipo de Scrum mejora su propio proceso, siempre dentro del marco de trabajo de
Scrum.
Y volver a repetir
El ciclo de Scrum se repite a partir de aquí, cada Sprint.
Para resumir, los miembros del Equipo de Scrum (el Dueño del Producto, el Equipo de
Desarrollo, y el ScrumMaster) colaboran para crear una serie de Incrementos del
Producto, durante intervalos cortos de duración fija, llamados Sprints. Cada incremento
cumple con el criterio de aceptación del Dueño del Producto y con la Definición de
Terminado compartida por el equipo. Trabajan a partir de un Backlog del Producto. En
cada Sprint, comienzan con la Planificación del Sprint para generar el Backlog del Sprint,
un plan para el Sprint. Se auto-gestionan para realizar el Desarrollo, usando la reunión de
Scrum Diario para producir el mejor Incremento de Producto posible. Realizan un
Refinamiento del Backlog del Producto para prepararse para la próxima reunión de
Planificación del Sprint. Terminan el Sprint con una Demo del Sprint y con una
Retrospectiva, revisando el producto y sus procesos.

18
9 SUMMARY:
Scrum is a process in which a set of good practices are applied on a regular basis to work
collaboratively, as a team, and obtain the best possible result of a project. These practices
support each other and their selection is based on a study of how highly productive teams
work.
In Scrum, partial and regular deliveries of the final product are made, prioritized by the
benefit they bring to the recipient of the project. Therefore, Scrum is especially suitable
for projects in complex environments, where you need to get results soon, where
requirements are changing or poorly defined, where innovation, competitiveness,
flexibility and productivity are fundamental.
Scrum is also used to solve situations in which the customer is not delivering what he
needs, when the deliveries are too long, the costs soar or the quality is not acceptable,
when the ability to react to the competition is needed, when the moral of equipment is
low and rotation is high, when it is necessary to identify and solve inefficiencies
systematically or when you want to work using a process specialized in product
development.
Scrum is the best known and most widely used Agile framework for software
development.
BEGINNING:
Values of the Agile Manifesto:
Scrum is the best known Agile framework. It is the source of many of the values and
principles behind the Agile Manifesto, which forms a common scope for all of these
approaches. You can read the Agile Manifesto for more information.
The values of the Agile Manifesto apply directly to Scrum:
• Individuals and their interactions over processes and tools: Scrum, like these Agile
frameworks and methods, is based on trust in teams, individuals in teams, and the way in
which they interact. The teams discover what has to be done, how to do it, and they do it.
The teams identify what things stand in their way, and assume the responsibility of
solving all the difficulties that are within their reach. Teams work with other parts of the
organization to resolve issues that are beyond their control. This is critical. If they try to
apply Scrum, but they take away the focus on the responsibility of the team it will
generally generate problems.
• Software that works by exhaustive documentation. Scrum requires that the main
result of each Sprint be the finished increment of the product. Obviously there will be

19
tasks of analysis, design, testing, and all this will be documented. But what guides the
success of the project is the software that works. This is critical. The Scrum teams have
to produce an increase of the product in each Sprint.
• Collaboration with the client over contractual negotiation. The Product Owner is the
main point of contact between the Scrum Team and the eventual final users of the product,
and with the parts of the organization that need the product. The Product Owner is a
member of the team who works collaboratively with the team to determine what needs to
be done. In this collaboration, the Product Owner selects the following most valuable
things to be done, and ensures that the product is as valuable as possible up to that point
in time. This is critical. The Product Owner needs to build a rich collaboration with their
teams.
• Adapt to change by following a plan. Everything related to Scrum is designed to
ensure that everyone has the information they need to make good decisions about the
project. The progress of the project is represented by an increase of the real product and
functioning. The backlog of things to do is available for everyone to see. The progress,
both of the sprint and of the project as a whole, is clearly visible. Problems and risks are
discussed openly and dealt with immediately. This is critical. Scrum works well on teams
that openly "inspect" what happens and "adapt" their actions to reality, and it works badly
for teams that do not achieve this.
SCRUM VALUES:
All the work that is done in Scrum needs a firm base of values that serve as a foundation
for the processes and principles of the team. Using teamwork and continuous
improvement, Scrum creates these values and uses them. The values are Focus, Courage,
Transparency, Commitment and Respect.
• Focus: Because we focus on just a few things at once, we work well together and
produce excellent work. We deliver valuable items before.
• Courage: As we are not alone, we feel supported and have more resources at our
disposal. This gives us the courage to overcome great challenges.
• Transparency: As we work together, we tell each other how we are doing, and what
things stand in our way. We learn that it is good to express concerns, so that they can be
resolved.
• Commitment: As we have control over our own destiny, we commit ourselves more to
succeed.

20
•Respect. While we work together, we share successes and failures, we respect each other,
and we help each other to be worthy of respect.
If an organization lets Scrum do its work, it will discover the benefits of Scrum and begin
to understand why these values are necessary and used by Scrum.
THE SCRUM WORK FRAMEWORK:
Scrum is a framework to build products. Scrum begins when someone interested needs a
product.
Scrum is a team process. The Scrum Team includes 3 roles: The Product Owner, the
ScrumMaster, and members of the Development Team. The Product Owner has the
responsibility to decide what work needs to be done. The ScrumMaster acts as a helpful
leader, helping the team and the organization to use Scrum as best as possible. The
Development Team builds the product incrementally, in a series of small time periods
called Sprints. A Sprint is a period of time of fixed duration, from 1 to 4 weeks, with
preference for the shorter intervals. In each Sprint, the Team builds and delivers a Product
Increase. Each increment is a recognizable and visually enhanced subset of the product
that meets the acceptance criteria and is built with a quality level called Definition of
Completion.
Scrum includes 3 essential artifacts: the Product Backlog, the Sprint Backlog, and the
Product Increase. The Product Backlog is an ordered list of ideas for the product, ordered
according to how it is expected to be constructed. The Sprint Backlog is a detailed plan
for the development of the next Sprint. The Product Increase is the required result of each
Sprint. It is an integrated version of the product, maintained with a quality high enough
to be put into production if the Product Owner wishes it. In addition to these artifacts,
Scrum wants transparency within the team and with stakeholders. Therefore, the Scrum
Team generates visible samples of its planning and progress.
Scrum includes 5 Activities or Meetings: the Definition of the Product Backlog, the Sprint
Planning, the Daily Scrum, the Sprint Demo, and the Retrospective.
Next, we will describe the roles, artifacts and activities.
ROLES DE SCRUM:
Role: Product Owner:
The Product Owner is a single individual responsible for achieving the highest possible
product value for a desired date. This is achieved by managing the work flow of the team,
selecting and refining the elements of the Product Backlog. The Product Owner maintains

21
the Product Backlog and ensures that everyone knows what is there and the priorities.
The Product Owner can receive help from other people, but it must be one person.
Obviously, the Product Owner is not solely responsible for everything. The entire Scrum
team is responsible for being as productive as possible, for improving their practices, for
asking the right questions, for helping the Product Owner, etc. The Development Team
is responsible for determining how much work they will take for a Sprint, and for
producing a Usable Product Increase in each Sprint.
Likewise, the Owner of the Product, is Scrum, is in a unique position. The Product Owner
is the one who is usually closest to the "business side" of the project. The Product Owner
is usually the one who was commissioned by the organization to "deliver the product",
and usually is the one who must satisfy the needs of all interested parties as best as
possible. The Product Owner achieves this by managing the Product Backlog, and making
sure that this backlog, and the progress, are visible.
The Product Owner, as he chooses what the Development Team will be working on next,
is the one who makes the decisions of scope vs. dates to achieve the best possible product.
Role: Member of the Development Team:
The Development Team is composed of professionals who perform the work of delivering
Product Increases. They self-organize to achieve this work. The members of the
Development Team are expected to be available throughout the project on a full-time
basis.
Scrum requires that the Development Team be multi-disciplinary so that, among them,
they possess all the necessary skills to perform the incremental delivery of the product.
The members of the Development Team are responsible for self-organizing to achieve
the Sprint goal, and produce a new Product Increase according to the Sprint Planning.
The Product Owner makes an ordered list of what needs to be done. The members of the
Development Team estimate how much they can complete in a Sprint, and then decide
how they will achieve it.
Role: ScrumMaster:
The ScrumMaster is a "helpful leader" that helps the rest of the Scrum Team follow the
process. The ScrumMaster needs to have a good understanding of the Scrum framework,
and must have the ability to train other people in the Scrum details.
The ScrumMaster works together with the Product Owner to help you understand how to
create and maintain the Product Backlog. Work with the Development Team to find and

22
implement technical practices that allow you to finish things at the end of each Sprint.
Work with the entire Scrum Team to evolve the Definition of Completion.
Another responsibility of the ScrumMaster is to verify that the impediments of the
equipment are eliminated. These impediments may be external to the team, such as the
lack of support from another team, or internal, such as the fact that the Product Owner
does not know how to properly prepare a Product Backlog.
ScrumMaster encourages self-management. The problems should be solved by the team
as much as possible.
The ScrumMaster acts as a coach of the Scrum Team, helping him to execute the Scrum
process. It helps them work together and learn the Scrum framework, and protects them
from internal and external distractions. It can facilitate meetings, and help to maintain the
course of the Scrum Team, to be productive and acquire skills.
The ScrumMaster is responsible for ensuring that Scrum is understood and applied
correctly, within the team and outside of it. It helps people outside the team to understand
the process, and understand what interactions with the team will be useful and what will
not. The ScrumMaster helps everyone to improve, making the Scrum Team more
productive and valuable.
SCRUM ARTIFACT:
Product Backlog:
The product backlog is an essential artifact in Scrum. The Product Backlog is an ordered
list of ideas for the product, in the order that we expect it to end. It is a unique place where
all the requirements flow. This means that all the work done by the Development Team
comes from the Product Backlog. Each idea, each characteristic, each improvement, each
bug, each documentation requirement - all the work that is done - is derived from some
element of the Product Backlog. Each item in the Product Backlog includes a description
and an estimate.
The Product Backlog can start as a large or short list. It can be little or very detailed. It
usually starts out being sketchy and short, and it gets bigger and more concrete over time.
The elements of the Product Backlog chosen for implementation will soon be "refined":
clarified, better defined, separated into smaller parts, all this as part of the Product
Backlog Refinement activities.
The Product Owner is responsible for maintaining the Product Backlog, although the
Product Owner can (and should) seek help to create and keep it updated. The elements of

23
the Product Backlog may originate from the Product Owner, team members, or other
interested parties.
SCRUM ACTIVITIES:
Refinement of the Product Backlog:
As the elements of the Product Backlog are usually large and general, and as ideas come
and go and priorities change, Refining the Product Backlog is an activity that occurs
throughout the entire Scrum project. This activity includes (but is not limited to):
keep the Product Backlog tidy to eliminate ideas that are no longer important to add or
promote elements that arise or become important to divide elements into smaller elements
to unite elements into larger elements to estimate elements
A key benefit of the Product Backlog Refinement activity is preparing for the next Sprint.
To achieve this, the refining activity gives special attention to preparing the elements that
are about to be implemented. There are several things to consider, including:
Each item that enters a Sprint should represent an increase in "business value".
The Development Team needs to be able to build each element in a single Sprint.
Everyone needs to be clear about what they want.
Depending on the nature of the product, other skills may be needed. In any case, the
Refining of the Backlog of the Product is an activity for all team members, and not only
for the Product Owner.
Sprint planning:
Each Sprint begins with a time-limited meeting called Sprint Planning. In this meeting
the Scrum Team collaborates to select and understand the work to be done in the Sprint
that begins.
The entire team is present at the Sprint Planning meeting. We work with the Backlog of
the ordered Product. The Product Owner and the Development Team Members discuss
each element and come to an understanding of what is needed to complete each element,
so as to be consistent with the Definition of Completion. All Scrum meetings are limited
in time. The recommended duration for the Sprint Planning meeting is less than 2 hours
for each week of the Sprint. As this meeting is limited in time, the success of the Sprint
Planning meeting depends to a large extent on the quality of the Product Backlog. This is
why the Refining Activity of the Product Backlog is very important.
In Scrum, the Sprint Planning meeting has 2 parts:
✓ Determine what work will be completed in the Sprint.
✓ Determine how this work will be done.

24
What work will be done?

In the first part of the meeting, the Product Owner presents to the Development Team the
ordered elements of the Product Backlog. To decide how many elements will be made,
the Development Team considers the current status of the Product Increment, the previous
performance of the equipment, the current capacity of the equipment, and the ordered
Product Backlog. The Development Team is the only one that decides how much work
they will take. Neither the Product Owner nor any other agency can push more work to
the Development Team.
Often, but not always, the Sprint has a goal, which is called the Sprint Goal. This is a
recommended practice that helps focus on the essence of what needs to be done, and
removes focus from the details that may not be as important.
How will the work be done?
In the second part of the meeting, the Development Team collaborates to decide how to
produce the next Product Increase according to the current Definition of Completion.
They make enough design and planning to be sure they can finish the job during the
Sprint. The work to be done during the first days is divided into smaller units of 1 day or
less. The work to be done more trade can be left in larger units to separate later.
Just as the Product Owner is responsible for deciding what to do, the Development Team
is responsible for determining how to perform the work.
The Product Owner can remain during this part of the meeting, to answer questions and
doubts. In any case, you always need to be available for the Development Team.
Result of the Sprint Planning:
Sprint Planning concludes when the Scrum Team comes to understand the amount and
complexity of what will be achieved during the Sprint, and what it expects to be able to
finish (within some rational range of circumstances). The Development Team estimates
the amount of work you can complete and commits to completing it.
To summarize, during the Sprint Planning meeting, the Development Team:
considers and discusses the elements of the Product Backlog with the Product Owner
makes sure you understand the elements of the Product Backlog
select a number of items that you think you can finish,
and create a detailed enough plan to make sure they can complete these elements.
The resulting list of these elements to perform is the "Sprint Backlog".
Artifact: Sprint Backlog:

25
The Sprint Backlog is the list of items in the Product Backlog, chosen to be a developer
in the current Sprint, along with the team's plan to get the job done. Reflects the estimate
of the work team that can be completed.
With the Sprint Backlog determined, the Sprint begins, and the Development Team
creates the new Product Increment defined by the Sprint Backlog.
Developing:
During the Sprint, the Development Team self-manages to produce a Product Increase
according to the Sprint Backlog, which was determined during the Sprint Planning. Self-
management means that the team is responsible for producing the Product Increase in
accordance with the organization's standards, in accordance with the Definition of
Completion, and that the Development Team determines how to achieve this.
Artifact: Product Increase:
The most important artifact of Scrum is the Product Increase. Each Sprint produces a
Product Increase. The Product Increase must have sufficient quality to be delivered to the
end users. The Product Increase must comply with the Finishing Definition of the Scrum
Team, and each component must be accepted by the Product Owner.
Additional visible indicators of progress:
Scrum requires transparency inside and outside the team. Although the Product Increase
is the most important way to create transparency, the Scrum Team will create any other
artifact you need to make sure that the status of the project is understood. Burndown
graphics and task boards are very common additional artifacts.
Agreement: Definition of Completed:
When the Product Increment is delivered, it needs to be "finished" as agreed to mean
"finished". This definition is different for each Scrum Team, and as the team matures, the
Definition of Completion will expand to be more precise.
The Definition of Completed should always include the notion that the Product Increase
has the necessary quality to be productive: the Product Owner should be able to choose it
to release it immediately. The Product Increment includes the functionality of all the
previous Product Increments, and is fully tested so that all the elements of the Product
Backlog continue to work together.
Activity: Daily Scrum:
The Development Team is self-managed. The Development Team uses the Daily Scrum
meeting to make sure they are on track to achieve the Sprint Goal. The meeting happens

26
at the same time and in the same place, every day. Each member of the Development
Team answers 3 questions:
What did I achieve since our last Daily Scrum?
What do I hope to achieve between today and the next Daily Scrum?
What is preventing my progress?
There may be some brief questions to clarify, but there are no discussions of any topic
during the Daily Scrum. However, many teams come together just after the Daily Scrum
to work on any issue that may have arisen.
The Daily Scrum is not a report for management, neither for the Product Owner, nor for
the ScrumMaster. It is a communication meeting within the Development Team, to ensure
that they are all synchronized. Only members of the Scrum Team, including the
ScrumMaster and the Product Owner, can speak during this meeting. Other interested
parties can attend to listen. Based on what comes out during the meeting, the
Development Team reorganizes the work that needs to be completed to achieve the Sprint
Objective.
The Daily Scrum is key to Scrum, leads to transparency, builds confidence, and provides
better performance. It makes problems to be discovered quickly, and promotes self-
management of the team and confidence. All Scrum meetings are limited in time. The
recommended duration for the Daily Scrum is no more than 15 minutes.
Activity: Sprint Demo:
At the end of the Sprint, the Scrum Team and stakeholders review what has been produced
in the Sprint. All Scrum meetings are limited in time. The recommended duration for the
Sprint Demo is 1 hour per week of the Sprint.
The focus of the discussion is the Product Increase completed during the Sprint. Since the
stakeholders are those who are "involved" in the results, it is usually helpful to participate
in this meeting. It is an informal meeting, to share where we are and collaborate on how
we can move forward. Everyone can participate in the Sprint Demo. Naturally, the
Product Owner is the one who makes the final decision about the future, and updates the
Product Backlog appropriately.
Teams find their own way to make a Sprint Demo. It is common to demonstrate the
Product Increase. The group often discusses what they observed during the Sprint, and
the product ideas that appear. They discuss the Product Backlog and talk about the
possible dates to finish, and what can be done about those dates.

27
The Sprint Demo gives everyone present a way to know the current Product Increase.
Also, it is common to update the Product Backlog as part of the Sprint Demo.
Activity: Sprint Retrospective:
At the end of each Sprint, the Scrum Team meets for the Retrospective. The purpose is to
review how things went with respect to the process, the relationships between people, and
the tools. The team identifies what went well and what did not go so well, and identifies
possible improvements. They put together a plan to improve things in the future. All
Scrum meetings are limited in time. The recommended duration for the Sprint
Retrospective is 1 hour per week of the Sprint.
The Scrum Team improves its own process, always within the framework of Scrum's
work.
And repeat again
The Scrum cycle is repeated from here, each Sprint.
To summarize, members of the Scrum Team (the Product Owner, the Development Team,
and the ScrumMaster) collaborate to create a series of Product Increments, during short
intervals of fixed duration, called Sprints. Each increment meets the acceptance criteria
of the Product Owner and the Definition of Completion shared by the team. They work
from a Product Backlog. In each Sprint, start with the Sprint Planning to generate the
Sprint Backlog, a plan for the Sprint. They self-manage to carry out the Development,
using the daily Scrum meeting to produce the best possible Product Increase. Perform a
Refinement of the Product Backlog to prepare for the next Sprint Planning meeting. They
finish the Sprint with a Sprint Demo and with a Retrospective, reviewing the product and
its processes.
10 CONCLUSIONES:
✓ Scrum es un método para trabajar en equipo a partir de iteraciones o Sprints. Así
pues, Scrum es una metodología ágil, por lo que su objetivo será controlar y planificar
proyectos con un gran volumen de cambios de última hora, en donde la incertidumbre
sea elevada.
✓ Se suele planificar por semanas. Al final de cada Sprint o iteración, se va revisando
el trabajo validado de la anterior semana. En función de esto, se priorizan y planifican
las actividades en las que invertiremos nuestros recursos en el siguiente Sprint.
✓ La metodología Scrum se centra en ajustar sus resultados y responder a las exigencias
reales y exactas del cliente. De ahí, que se vaya revisando cada entregable, ya que los

28
requerimientos van variando a corto plazo. El tiempo mínimo para un Sprint es de

una semana y el máximo es de cuatro semanas.
✓ Entre las principales características de la metodología Scrum, desataca que es un
desarrollo incremental en lugar de la clásica planificación del desarrollo completo de
un producto o servicio. Sus equipos de trabajo se caracterizan por ser auto-
organizados. Y se centra en el producto final, en la calidad del mismo.
✓ Además, en la metodología Scrum se solapan diferentes fases de desarrollo, en lugar
de llevar a cabo una planificación secuencial o de cascada.
✓ La principal desventaja de Scrum es que las reuniones y la asignación de tareas deben
estar controladas por un líder que conozca y comparta este sistema de trabajo. Scrum
es sin lugar a dudas la metodología de desarrollo ágil más sencillo de comprender y
de implantar en las empresas, ya que tiene los suficientes puntos en común con las
metodologías de desarrollo tradicionales para superar la resistencia de la cultura
empresarial, pero a la vez es lo bastante flexible como para resultar efectiva.
11 RECOMENDACIONES:
✓ Scrum por sus características no es válido para cualquier proyecto ni para cualquier
persona o equipo de personas. Es más, Scrum según muchos especialistas de esta
metodología, es óptima para equipos de trabajo de hasta 8 personas, aunque hay
empresas que han utilizado Scrum con éxito con equipos más grandes.
✓ Se puede decir 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%. Es más, no hay metodología
mejor que otra ni válida al 100% para todas las personas y empresas.
✓ Scrum es una metodología más de las muchas que hay.
✓ Scrum no es ni la mejor metodología ni la única, pero 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.
✓ Por un lado, Scrum evita la burocracia y la generación documental. No es que con
Scrum no se deba o no se pueda documentar, si no que con Scrum no se exige
documentar nada para iniciar un proyecto, algo que en otras metodologías es
impensable.
✓ 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 para que el cliente

29
vaya viendo los avances y se quede satisfecho con lo que se está haciendo y cómo se
está haciendo.
✓ La idea de la metodología ágil es fundamentalmente que adopte los cambios, que se
pueda reconducir el proyecto en un momento dado, y que afecte lo menos posible a
los costes, los tiempos y al equipo de trabajo.
12 APRECIACION DEL EQUIPO:

✓ A medida que Scrum ha ido ganando terreno en el campo empresarial, hemos podido
conocer con mayor detalle las características de esta metodología, que en la
actualidad es una de las más implementadas por compañías de todo tipo.
✓ Nos ha quedado claro, su enfoque basado en la división del trabajo en las llamadas
iteraciones o etapas, de las cuales se obtienen resultados parciales hasta el momento
de la entrega definitiva o el demo final.
✓ Además, la interacción permanente que se presenta no sólo entre el Scrum Máster
(jefe o líder de proyecto) y el Scrum Team (equipo de trabajo), sino también entre
éstos y el Product Owner (destinatario o cliente).

30
13 GLOSARIO DE TÉRMINOS:
▪ Product Owner: El Product Owner es un rol muy importante en los proyectos ágiles:
Representa la voz del cliente. Se asegura de que el equipo conozca la perspectiva del
negocio. Gestiona las historias de usuario, las prioriza, y las mantiene en el product
backlog.
▪ Product backlog: El product backlog es la lista de tareas pendientes que se genera en
un proyecto, y que es priorizada por el Product Owner para que el equipo tenga un
orden con el que trabajar.
▪ Scrum: Scrum es un método ágil usado en proyectos de generación de software, en el
que se trabaja por ciclos para entregar valor al usuario final.
▪ Scrum Master: El Scrum Master (SM) o facilitador de proyectos, es la figura que lidera
los equipos en la gestión ágil de proyectos.
▪ Sprint: Iteración con la que se trabaja cuando usamos como herramienta de trabajo el
método Scrum.
▪ Stakeholder: Stakeholder es una palabra del inglés que, en el ámbito empresarial,
significa ‘interesado’ o ‘parte interesada’. Se refiere a todas aquellas personas u
organizaciones afectadas por las actividades y las decisiones de una empresa.
▪ Agile Coach: Un agile coach es una persona que ayuda a implantar procesos ágiles en
equipos poco maduros. Alguien que conoce en profundidad estos métodos y tiene
mucha experiencia en su implantación en el mundo empresarial.
▪ Cycle-Time: En agilidad, el Cycle-Time es una métrica que nos indica el tiempo que
ha estado una tarea desde que el equipo de desarrollo empezó a trabajar en ella hasta
que se dió por finalizada estando en producción.

31
14 LINKOGRAFIA:
✓ http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:sg07.p02.scrum.pdf
✓ https://www.sinnaps.com/blog-gestion-proyectos/metodologia-scrum
✓ https://dosideas.com/noticias/metodologias/981-scrum-en-1-sola-pagina
✓ https://www.wearemarketing.com/es/blog/metodologia-scrum-que-es-y-como-
funciona.html
✓ https://www.obs-edu.com/int/blog-project-management/scrum/scrum-resumen-
de-sus-reglas-basicas-de-ejecucion
✓ https://proyectosagiles.org/requisitos-de-scrum/

32

SCRUM

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SCRUM

Caricato da

Copyright:

Formati disponibili

ESCUELA PROFESIONAL DE

CURSO : Gestión de Sistemas Informáticos.

DOCENTE : Ing. PORRO CHULLI , Marco Aurelio.

Bagua Grande, abril del 2019.

12 Apreciacion del equipo: ........................................................................................................................ 30

13 Glosario de términos: ............................................................................................................................ 31

Ingeniería de Sistemas y Telemática. i

Ingeniería de Sistemas y Telemática.

❖ Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos,

Ingeniería de Sistemas y Telemática.

▪ Cumplimento de Expectativas: El cliente establece sus expectativas indicando el

Ingeniería de Sistemas y Telemática.

▪ Maximiza el Retorno de la Inversión (ROI): Producción de software únicamente

A. Planteamiento: Un proyecto gestionado ajo el modelo SCRUM parte de los

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

habilidades transversales necesarias para realizar el trabajo (análisis, diseño,

Es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Scrum es el marco de trabajo Ágil más conocido y difundido para el desarrollo de

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Producto tiene la responsabilidad de decidir qué trabajo necesita hacerse. El ScrumMaster

Ingeniería de Sistemas y Telemática.

Igualmente, el Dueño del Producto, es Scrum, se encuentra en una posición única. El

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

ACTIVIDADES DEL SCRUM:

Ingeniería de Sistemas y Telemática.

✓ Determinar qué trabajo se completará en el Sprint.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

La Definición de Terminado siempre debe incluir la noción de que el Incremento del

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

What work will be done?

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

requerimientos van variando a corto plazo. El tiempo mínimo para un Sprint es de

Ingeniería de Sistemas y Telemática.

12 APRECIACION DEL EQUIPO:

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Ingeniería de Sistemas y Telemática.

Potrebbero piacerti anche