S C RUM EN LA GERENCIA DE

P ROYECTOS

Un análisis de Scrum con base en los grupos de procesos y las áreas de conoci-
miento de la guía del PMBOK.

Enrique Arango Lyons

Universidad EAFIT
Octubre, 2012
 S C RUM EN LA GERENCIA DE
P ROYECTOS
Un análisis de Scrum con base en los grupos de procesos y las áreas de conoci-
miento de la guía del PMBOK.

Enrique Arango Lyons

Universidad EAFIT
Octubre, 2012

Introducción
En los últimos años, las llamadas Metodologías Ágiles han tomado un importante rol en el desar-
rollo de proyectos de cualquier tipo, especialmente los relacionados con software. Estas me-
todologías proponen métodos de llevar a cabo proyectos de manera rápida y eficaz, basándose
en desarrollos iterativos e incrementales, donde los requerimientos y soluciones evolucionan a
través de la colaboración en equipos multifuncionales y autoorganizables. Esto se evidencia en
el llamado Manifiesto Ágil (Beck et al., 2001), donde se especifica la preferencia de:

“Inidividuos e interacciones sobre procesos y herramientas;

Software funcionando sobre documentación extensiva;
Colaboración con el cliente sobre negociación contractual;
Respuesta ante el cambio sobre seguir un plan”

En este contexto surge la metodología Scrum. Scrum propone un “marco estructurado para
apoyar el desarrollo complejo de productos” (Schwaber & Sutherland, 2011) mediante la defini-
ción de roles, eventos, artefactos y reglas. Esta metodología, como muchas de las metodologías
ágiles, se desvía del modelo rígido clásico de manejo de proyectos, en favor de un enfoque
mucho más flexible e informal. Por esta razón, se puede tener la impresión de que Scrum no
presenta las características tradicionales de la gestión de proyectos, como las definidas en el
Project Management Body of Knowledge (PMBOK), sino que pertenece a una categoría total-
mente distinta. El presente informe busca entonces relacionar los conceptos que definen la me-
todología Scrum a la luz de los conceptos del PMBOK, específicamente los grupos de procesos
y las áreas de conocimiento, para esclarecer el lugar que toma Scrum en el área de la gerencia
de proyectos.

Scrum en la Gerencia de Proyectos#

1
Objetivos
Los objetivos de este informe de análisis se presentan a continuación:

• Relacionar los conceptos y características de la metodología Scrum con aquellos del

PMBOK respecto a los grupos de procesos y a las áreas de conocimiento de la gerencia de
proyectos.

• Evidenciar el lugar que ocupa la metodología Scrum dentro del área de la gerencia de
proyectos.

• Proveer una perspectiva de la metodología Scrum que permita asimilar y comprender su

utilización y efectividad como herramienta de la gerencia de proyectos.

Grupos de procesos de la gerencia de proyectos

La guía del PMBOK establece 5 grupos básicos de procesos que caracterizan a todos los
proyectos. En Scrum, estos grupos de procesos no se presentan una vez durante el ciclo de vida
del proyecto sino que, debido a la naturaleza de la metodología, se evidencian continuamente y
de manera iterativa. Esto quiere decir que los grupos de procesos se definen y ejecutan por cada
iteración.

A continuación se detalla cómo se relacionan estos procesos en una metodología Scrum:

INICIACIÓN
El objetivo de este grupo de procesos es definir y autorizar lo que se va a hacer en el proyecto.
En Scrum esto es definido en primer lugar mediante el artefacto Product Backlog determinado
por el Product Owner, quien representa la voz del cliente; este es un documento que describe las
funcionalidades y características que desea el cliente para el producto. Este documento es pos-
teriormente discutido y analizado durante el Sprint Planning Meeting que se realiza al comienzo
de cada Sprint o iteración. Los objetivos de esta reunión son definir qué se va a hacer durante
el próximo Sprint y cómo se piensa realizar; la primera parte, el “qué”, entra en este grupo de
procesos, ya que es aquí donde se definen los objetivos para la iteración.

El grupo de procesos de iniciación en Scrum se puede evidenciar entonces en la primera parte

del Sprint Planning Meeting tomando como insumo el Product Backlog para generar los ob-
jetivos del Sprint. El resultado de estos procesos es el Sprint Goal.

ENTRADAS
• Product Backlog.

Scrum en la Gerencia de Proyectos#

2
 HERRAMIENTAS
• Sprint Planning Meeting.

SALIDAS
• Sprint Goal.

PLANIFICACIÓN
Aquí se debe planificar el curso de acción requerido para llevar a cabo los objetivos de un
proyecto o, en este caso, de una iteración. En este grupo entra entonces la segunda parte del
Sprint Planning Meeting en la que se especifica cómo se van a realizar los objetivos definidos.
Como resultado de este proceso se genera el Sprint Backlog, documento en el que se especifican
las actividades necesarias para desarrollar los ítems del Product Backlog autorizados para su
ejecución durante el Sprint.

ENTRADAS
• Product Backlog.

• Sprint Goal.

HERRAMIENTAS
• Sprint Planning Meeting.

SALIDAS
• Sprint Backlog.

EJECUCIÓN
Este grupo de procesos es el encargado de llevar a cabo las actividades planificadas anterior-
mente con el fin de lograr los objetivos definidos; asimismo, implica la coordinación de perso-
nas y recursos. En Scrum, esto es desarrollado a través del Sprint. El Sprint es un periodo corto,
preferiblemente no mayor a un mes, en el que se ejecutan las actividades necesarias para cum-
plir los objetivos definidos. Estas actividades son las definidas en el Sprint Backlog.

Scrum define una tarea con el mismo nombre, el Daily Scrum, que consiste en reuniones diarias
de 15 minutos entre los integrantes del equipo de trabajo para estar al tanto de las actividades y
obstáculos que se tengan en el desarrollo. Esta actividad es una de las más importantes de la
metodología, ya que permite lograr transparencia y coordinación en la ejecución así como lle-
var un seguimiento directo del desarrollo.

La metodología determina igualmente que sus equipos deben ser autoogranizables; esto quiere
decir que los mismos miembros del equipo de trabajo deben planificar y coordinar la ejecución

Scrum en la Gerencia de Proyectos#

3
de sus propias actividades. Un método común que utilizan los equipos de Scrum para coordi-
narse adecuadamente consiste en la utilización de pequeñas notas adhesivas con actividades
que se clasifican de acuerdo a su estado, sea pendiente, en ejecución o terminado; estas notas
permiten conocer de forma práctica las actividades que está realizando cada miembro del
equipo.

Al finalizar la iteración, se debe mostrar un producto completamente funcional de acuerdo a las

actividades definidas para el Sprint.

ENTRADAS
• Sprint Backlog.

HERRAMIENTAS
• Daily Scrum.

• Equipo autoorganizable.

SALIDAS
• Producto funcional.

SEGUIMIENTO Y CONTROL
Para asegurar el cumplimiento de los objetivos de un proyecto, se deben realizar procesos de
seguimiento, control y medición que permitan conocer el avance y las acciones correctivas ne-
cesarias. Para hacer este seguimiento, Scrum propone la utilización de herramientas como el
Burndown Chart, en el cual se muestra gráficamente las horas restantes para completar los ob-
jetivos del Sprint; esto permite hacer previsiones y tomar acciones en caso de que haya retra-
sos. Igualmente, el Daily Scrum permite hacer seguimiento al trabajo que realiza cada uno de
los miembros del equipo, de tal manera que haya un conocimiento transparente de las activida-
dades que se estén realizando.

En este grupo surge también un rol fundamental para la metodología Scrum, el Scrum Master.
Aunque este rol se encuentra presente durante todo el ciclo de vida del Scrum, aquí toma una
importancia especial. Esta persona es la encargada de asegurarse de que el equipo de trabajo no
presente problemas y pueda alcanzar efectivamente los objetivos definidos; igualmente, se en-
carga de las comunicaciones con los interesados y de planear las reuniones necesarias.

ENTRADAS
• Progreso del desarrollo.

Scrum en la Gerencia de Proyectos#

4
 HERRAMIENTAS
• Daily Scrum.

• Burndown Chart.

SALIDAS
• Acciones correctivas.

CIERRE
Aquí se debe presentar el resultado de la iteración para su aceptación. Con este fin, Scrum de-
fine dos actividades importantes al cierre de cada Sprint. La primera es el Sprint Review, en el
cual se reúnen tanto el equipo de desarrollo como los interesados del proyecto para hacer una
revisión y validación del producto entregado. En caso de requerirse otra iteración, se analiza y
se hacen los ajustes necesarios al Product Backlog para su utilización en el próximo Sprint
Planning Meeting. De lo contrario, se hace la entrega final del resultado del proyecto.

La segunda actividad es el Sprint Retrospective, que permite hacer una evaluación del Sprint por
parte del equipo de trabajo, de tal manera que se lleven a cabo acciones correctivas en la
próxima iteración.

ENTRADAS
• Producto funcional.

HERRAMIENTAS
• Sprint Review.

• Sprint Retrospective.

SALIDAS
• Product Backlog actualizado.

• Acciones correctivas.

• Entrega del proyecto.

Áreas de conocimiento de la gerencia de proyectos

La guía del PMBOK establece también 9 áreas de conocimiento comunes en la gestión de
proyectos. Debido al enfoque flexible y práctico de Scrum, sus actividades pueden ser transver-
sales a múltiples áreas de conocimiento y no se realizan muchas formalidades ni procesos
documentales; las interacciones son directas entre los involucrados.

Scrum en la Gerencia de Proyectos#

5
A continuación se evidencia la aplicación de estas áreas de conocimiento en una metodología
Scrum:

GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO

Para integrar las distintas actividades de Scrum se definen principalmente espacios de comuni-
cación directa y la generación de artefactos. Estos artefactos son el resultado de eventos es-
pecíficos. Los principales artefactos son el Product Backlog y el Sprint Backlog que contienen
la información más relevante para el desarrollo del proyecto. Asimismo, las interacciones direc-
tas entre los involucrados permiten identificar, definir y coordinar las actividades necesarias
para cumplir los objetivos del proyecto.

GESTIÓN DEL ALCANCE DEL PROYECTO

Por su naturaleza de metodología ágil, Scrum propone un enfoque en el que el alcance es inci-
erto y se actualiza a medida que avanza el proyecto y se tiene más información de lo que desea
el cliente.

Scrum se basa en el Product Backlog para definir el alcance preliminar de un proyecto, y luego
el Sprint Backlog para determinar el alcance de una iteración. Para garantizar el cumplimiento
del alcance, Scrum propone Sprints de duración muy corta y exige que su objetivo y sus ac-
tividades no sean modificadas durante la ejecución del mismo. Esto permite que efectivamente
se completen las actividades definidas en el alcance y no se realicen tareas innecesarias.

El alcance es analizado al final de cada Sprint conforme se observe el progreso y el resultado

final de la iteración mediante el Sprint Review. Esto hace que la gestión del alcance se realice de
manera iterativa e incremental.

GESTIÓN DEL TIEMPO DEL PROYECTO

Scrum es muy exigente en cuanto al manejo del tiempo y determina que las actividades deben
tener un tiempo definido y ser de corta duración. Por ejemplo, las reuniones no deben durar
más de 4 horas, los Daily Scrum son de máximo 15 minutos y los Sprint no deben durar más de
un mes. La idea de este enfoque es que no se pierda mucho tiempo en planeación y la ejecución
sea eficiente al cumplir con los tiempos del proyecto.

Para hacer estimaciones de tiempo, se utiliza el Sprint Backlog. En este documento se estima el
tiempo requerido para las actividades definidas, actividades que deben estar bien desglosadas
de tal manera que se logre una estimación correcta. Esto con el fin de que las actividades que se
definan para un Sprint sean suficientes y se puedan terminar en la duración del mismo.

Para hacer seguimiento al tiempo durante el Sprint, se utiliza el Burndown Chart. Este permite
observar el tiempo restante en las actividades con el fin de estimar qué tan cerca o qué tan lejos
se está de cumplir los objetivos del Sprint en el tiempo determinado.

Scrum en la Gerencia de Proyectos#

6
GESTIÓN DE LOS COSTOS DEL PROYECTO
No hay definido un esquema específico para el manejo de los costos en Scrum, aunque gracias
al manejo disciplinado de las actividades, el tiempo y el alcance, entre otros elementos, es posi-
ble definir y hacer un adecuado seguimiento a los costos incurridos en el proyecto.

GESTIÓN DE LA CALIDAD DEL PROYECTO

Muchas de las actividades definidas en Scrum apuntan a lograr una alta calidad en el proyecto.
Calidad definida como el cumplimiento a cabalidad de los requisitos del cliente. Es por esto
que se prefieren interacciones directas con el cliente y retroalimentaciones rápidas, de tal
manera que se cumpla efectivamente con lo que el cliente desea. Además, al concentrarse en
iteraciones cortas con actividades bien definidas, el equipo puede enfocarse en realizarlas de la
mejor manera posible; igualmente los actividades de retroalimentación interna, como el Daily
Scrum y el Sprint Retrospective, permiten que se aplique un mejoramiento continuo al proceso
de desarrollo.

GESTIÓN DE LOS RECURSOS HUMANOS DEL PROYECTO

Scrum define de una manera simple y clara los roles de un proyecto. Estos roles son, como ya se
han mencionado: Product Owner, Scrum Master, equipo de desarrollo e interesados o Stake-
holders. Cada uno de estos roles tiene unas responsabilidades bien definidas. El equipo de tra-
bajo presenta, además, una característica interesante, y es la eliminación de jerarquías o roles
especializados al interior; Scrum prefiere tratar a todos los miembros del equipo por igual y de-
nominarlos a todos “desarrolladores” independiente de su función. Con esto se logra un trato
equitativo y la asimiliación de una responsabilidad conjunta: la obligación de responder ante el
proyecto pertenece al equipo de trabajo en su totalidad y no a miembros individuales.

GESTIÓN DE LAS COMUNICACIONES DEL PROYECTO

Como se ha mencionado anteriormente, el enfoque predilecto de Scrum es la interacción di-
recta. Por esto, se definen varios espacios de comunicación entre los involucrados del proyecto.
El Scrum Master es el encargado de planear las reuniones con los interesados; estas reuniones
son principalmente el Sprint Planning Meeting y el Sprint Review. Asimismo durante el Sprint,
el Scrum Master toma un rol importante en el manejo de las comunicaciones, ya que es el en-
cargado de que no se presenten interferencias externas en el equipo de trabajo; él es el encar-
gado de comunicarse directamente con el Product Owner y determinar qué información debe
llegar al equipo de trabajo. Esto permite que el equipo no se desenfoque del objetivo del Sprint
y logre completarlo a tiempo. Igualmente, la comunicación interna en el equipo es muy impor-
tante, razón por la que se realizan los Daily Scrum y el Sprint Retrospective.

Scrum en la Gerencia de Proyectos#

7
GESTIÓN DE LOS RIESGOS DEL PROYECTO
Scrum no define planes para manejo de riesgos, sino que prefiere tomar un enfoque más
empírico: se le da más valor a ocurrencias reales que a suposiciones. Los ciclos de ejecución
corta y retroalimentación rápida son entonces los encargados de reducir los riesgos del desar-
rollo. En periodos de desarrollo largos es muy probable que los requerimientos cambien y que
la complejidad y los riesgos aumenten. Con un enfoque ágil, y gracias a la interacción constante
entre las personas involucradas, se logra la capacidad de responder rápidamente ante eventos
infortunados o inesperados, ajustando y adaptando el desarrollo conforme avanza el proyecto.
La flexibilidad es la clave aquí en el manejo de riesgos.

GESTIÓN DE LAS ADQUISICIONES DEL PROYECTO

Scrum no define un esquema específico para las adquisiciones, aunque tampoco determina re-
stricciones al respecto.

Conclusión
Se realizó un análisis de Scrum a la luz de los conceptos definidos en el PMBOK con respecto a
la gerencia de proyectos. Como resultado de esto, se pudo observar la relación que mantiene
Scrum con esta área, aunque de una manera más flexible e informal, donde se valoran más las
interacciones directas, los ciclos cortos y la retroalimentación rápida. Se logró relacionar tam-
bién las actividades que propone Scrum con los grupos de procesos de la gerencia de proyectos
y los beneficios que trae su aplicación en cada una de las áreas del conocimiento.

Bibliografía
• S c h w a b e r, K . & S u t h e r l a n d J. ( 2 0 1 1 ) . “ T h e S c r u m Gu i d e ” . To m a d o d e :
http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf

• Beck, K.; Beedle, M.; van Bennekum, A.; Cockburn, A.; Cunningham, W.; Fowler, M.; Gren-
ning, J.; Highsmith, J.; Hunt, A.; Jeffries, R.; Kern, J.; Marick, B.; Martin, R.; Mellor, S.;
Schwaber, K.; Sutherland, J. & Thomas, D. (2001). “Manifesto for Agile Software Develop-
ment”. Tomado de: http://agilemanifesto.org/

• Project Management Institute. (2008). “Guía de los Fundamentos para la Gestión de Proyec-
tos” (4ta ed.).

• Project Management Body of Knowledge. (2012). En Wikipedia, La enciclopedia libre. Tomado

de: http://es.wikipedia.org/wiki/Project_Management_Body_of_Knowledge

Scrum en la Gerencia de Proyectos#

8