Metodologia scrum:

La metodología Scrum es tendencia en la gestión de proyectos. Si trabajas en un sector en el que el

nivel de incertidumbre es alto y tu trabajo ágil, quizás tengas que aplicar Scrum para gestionar tus
proyectos.
El sector del desarrollo de software es el principal representante de este tipo de metodología ágil. Se
trata de planificar tus proyectos en pequeños bloques o Sprints, e ir revisando y mejorando el anterior.
Y es el propio término Scrum proviene del mundo del rugby. Te lo contamos a continuación.
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 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.
El término Scrum (traducido del inglés como melé) fue acuñado y definido por Ikujiro Nonaka e
Hirotaka Takeuchi en los años 80, cuando las principales empresa de desarrollo tecnológica
empezaban a dominar el mercado y a definir conductas de trabajo. Ambos publicaron en 1986 en la
Harvard Business Review este artículo “El nuevo nuevo juego para el desarrollo de productos”. Así
abrieron una caja que durante los próximos años ha evolucionado y se ha extendido por muchos
sectores, no sólo el tecnológico.
El avance de las formaciones de las melés en partidos de rugby, inspiró a Nonaka y Takeuchi para
bautizar una nueva forma de trabajar que ya venía dándose en muchas empresas tecnológicas como
Honda, Canon y Fuji-Xerox.
Nonaka y Takeuchi explican cómo esta metodología ágil se compara con la formación de melé del
rugby de la siguiente forma: «El enfoque de las ‘carrera de relevos’ para el desarrollo de productos
entra en conflicto con el objetivo de obtener la máxima velocidad y flexibilidad. En su lugar un
enfoque como el rugby – donde el equipo intenta avanzar como equipo, enviando el balón hacia atrás
y luego avanzar – sirve mejor a los desarrollos competitivos que se ven hoy en día». Por eso Scrum y
equipo auto organizado van siempre de la mano.
Así pues, los proyectos que utilizan una metodología de desarrollo ágil pueden aplicar Scrum. En ellos,
los requisitos varían a muy corto plazo, necesitan una gestión muy flexible, orientada a objetivos y
resultados concretos. Y la metodología Scrum es perfecta.
El desarrollo del software fue el primero en aplicar la metodología Scrum. Anteriormente, este sector
utilizaba para planificar y gestionar sus proyectos con métodos en cascada o secuencial. En ellas se
planifican varias fases con unos plazos establecidos y se van ejecutando.
Sin embargo, en 1993, Jeff Sutherland y su equipo en Easel Corporation adaptaron la metodología
Srcum al desarrollo del software. Publicando así el Software Development Process. El método Scrum
estaba ahora orientado a objetos, a un control de procesos empírico, desarrollo iterativo e incremental, a
una mejora continua de la productividad, así como al desarrollo de sistemas complejos y ágiles.
En la actualidad, Scrum es utilizado para el desarrollo de muchos tipos de productos, con el objetivo de
organizar flujos de trabajo optimizados y flexibles. Una virtud de aplicaciones que integran esta idea
para gestionar proyectos, como Sinnaps.

En la actualidad, los proyectos se desarrollan en contextos muy versátiles. Son más complejos que
antes, frente a unas exigencias del cliente y del mercado mucho más variables, y con una incertidumbre
elevada. Por eso, la aplicación del método Scrum se ha extendido como la pólvora en numerosos
sectores, fuera del mundo del desarrollo de software.

Fases de la metodología Scrum

El desarrollo de producto tiene un ciclo de vida en la metodología Scrum. Estas son fases en las que
se divide un proceso Scrum:
• ¿Qué y quién? El producto que queremos conseguir una vez terminemos el Sprint, y los roles de
equipo con sus tareas asignadas.
• ¿Dónde y cuándo? El plazo y el contenido del Sprint.
• ¿Por qué y cómo? Las distintas herramientas para aplicar esta metodología ágil.

Cada Sprint puede tener una serie de eventos o etapas. Los más comunes son:
1. Reunión para la planificación del Sprint. En ella, se divide el tiempo de duración del Sprint, así
como el objetivo y entregable del mismo. Además, el equipo de desarrollo deberá saber cómo
realizarlo. Muy parecido a lo que llamamos reunión de Kick off y que puedes descubrir en este
curso gratis y online de gestión de proyectos.
2. Scrum diario. Se basa en poner en común y sincronizar actividades para elaborar el plan del día.
 3. Trabajo de desarrollo durante el Sprint. Nos aseguramos que los objetivos se están cumpliendo,
que no se producen cambios que alteran el objetivo del Sprint y se mantiene un feedback
constante con el cliente o dueño del proyecto.
4. Revisión del Sprint. Reunión con el cliente o dueño del proyecto, en la que se estudia y revisa el
Product Backlog del Sprint. Se definen los aspectos a cambiar, en caso necesario, de mayor
valor o probables para planificarlo en el siguiente Sprint.
5. Retrospectiva del proyecto. Oportunidad del equipo de desarrollo para mejorar su proceso de
trabajo y aplicar los cambios en los siguientes Sprints.
Roles de Scrum

La metodología Scrum tiene unos roles y responsabilidades principales, asignados a sus procesos de
desarrollo. Estos son:
• Project Owner. Se asegura de que el proyecto se esté desarrollando acorde con la estrategia del
negocio. Escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
• Master Scrum o Facilitador. Elimina los obstáculos que impiden que el equipo cumpla con su
objetivo.
• Development team Member. Los encargados de crear el producto para que pueda estar listo
con los requerimientos necesarios. Se recomienda que sea un equipo multidisciplinar, de no más
de 10 personas. Sin embargo, empresas como Google disponen de unos 15.000 desarrolladores
trabajando en una rama del código. Y con una metodología Scrum. La automatización en el
testeo explica sobre por qué este gran volumen en el equipo.

Ejemplos de uso

La metodología Scrum se puede aplicar a muchos sectores, sin embargo aún no se puede adaptar
adecuadamente a otros como los procesos de fabricación de productos o el mundo de la construcción
—a pesar de que éste último está sufriendo una transformación importante a través del BIM y sus
líneas bases. Puedes saber más sobre las metodologías a usar según tu tipo de proyecto en la primera
lección del curso online y gratis de gestión de proyectos.
Incluso, en los propios proyectos tecnológicos ha habido algún que otro fracaso. Precisamente, Jeff
Sutherland, cocreador de Scrum y Asesor Senior y Coach de OpenView, explica las razones del fracaso
de Healthcare y del éxito de Spotify en esta entrevista que resumimos aquí.
Causas de fracaso de Healthcare.gov, proyecto del gobierno norteamericano para mostrar
transparencia en los seguros sanitarios.
• No haber lanzado el proyecto fase a fase
• No testeo ni aprendizaje
 • Falta de liderazgo en un proyecto con más de 20 consultoras implicadas
• Falta de coordinación entre el Front-End y el Back-End
• El testeo final se produjo en un periodo demasiado corto

Causas del éxito de Spotify.

• Contrato externo de un especialista en metodologías ágiles. Gran importancia al rol del Scrum
Master.
• Fundamental el trabajo del Product Owner, para saber entender las necesidades reales del
cliente y trasladarlas a tiempo al equipo.
• Buena coordinación central de la compañía.
• Rápidos, baratos y mejores frente a sus competidores Google y Apple.
• Los pequeños equipos Scrum son hábiles para implementar el software al final de cada sprint,
sin romper a otros equipos.
• Cada equipo tiene una parte del software exclusivo suyo. Entre todos forman tribus o Tribe,
añadiendo distintos Squad o escuadrones.
Aquí un ejemplo gráfico de cómo funciona Scrum en Spotify.

Qué es SCRUM
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.
Ver en detalle cuales son los beneficios de Scrum, sus fundamentos y sus requisitos.

El proceso
En Scrum un proyecto se ejecuta en ciclos temporales cortos y de duración
fija (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos
son de 3 y hasta 4 semanas, límite máximo de feedback de producto real y
reflexión). Cada iteración tiene que proporcionar un resultado completo, un
incremento de producto final que sea susceptible de ser entregado con el mínimo
esfuerzo al cliente cuando lo solicite.
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa
como plan del proyecto. En esta lista el cliente (Product Owner) prioriza los
objetivos balanceando el valor que le aportan respecto a su coste (que el
equipo estima considerando la Definición de Hecho) y quedan repartidos en
iteraciones y entregas.
Las actividades que se llevan a cabo en Scrum son las siguientes (los tiempos
indicados son para iteraciones de 2 semanas):
Planificación de la iteración
El primer día de la iteración se realiza la reunión de planificación de la iteración.
Tiene dos partes:
1. Selección de requisitos (2 horas). El cliente presenta al equipo la lista de
requisitos priorizada del producto o proyecto. El equipo pregunta al cliente
las dudas que surgen y selecciona los requisitos más prioritarios que prevé
que podrá completar en la iteración, de manera que puedan ser entregados
si el cliente lo solicita.
2. Planificación de la iteración (2 horas). El equipo elabora la lista de tareas de
la iteración necesarias para desarrollar los requisitos seleccionados. La
estimación de esfuerzo se hace de manera conjunta y los miembros del
equipo se autoasignan las tareas, se autoorganizan para trabajar incluso en
parejas (o grupos mayores) con el fin de compartir conocimiento (creando
 un equipo más resiliente) o para resolver juntos objetivos especialmente
complejos.

Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos), normalmente
delante de un tablero físico o pizarra (Scrum Taskboard). El equipo inspecciona el trabajo
que el resto está realizando (dependencias entre tareas, progreso hacia el
objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder
hacer las adaptaciones necesarias que permitan cumplir con la previsión de
objetivos a mostrar al final de la iteración. En la reunión cada miembro del equipo
responde a tres preguntas:
• ¿Qué he hecho desde la última reunión de sincronización para ayudar al
equipo a cumplir su objetivo?
• ¿Qué voy a hacer a partir de este momento para ayudar al equipo a cumplir
su objetivo?
• ¿Qué impedimentos tengo o voy a tener que nos impidan conseguir nuestro
objetivo?

Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda

mantener el foco para cumplir con sus objetivos.
• Elimina los obstáculos que el equipo no puede resolver por sí mismo.
• Protege al equipo de interrupciones externas que puedan afectar el objetivo
de la iteración o su productividad.

Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para
prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican los objetivos del
proyecto (10%-15% del tiempo de la iteración) con el objetivo de maximizar la utilidad de lo que
se desarrolla y el retorno de inversión.

Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene
dos partes:
1. Revisión (demostración) (1,5 horas). El equipo presenta al cliente los requisitos
completados en la iteración, en forma de incremento de producto preparado
para ser entregado con el mínimo esfuerzo. En función de los resultados
mostrados y de los cambios que haya habido en el contexto del proyecto, el
cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la
primera iteración, replanificando el proyecto.
 2. Retrospectiva (1,5 horas). El equipo analiza cómo ha sido su manera de
trabajar y cuáles son los problemas que podrían impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El
Facilitador se encargará de eliminar o escalar los obstáculos identificados
que estén más allá del ámbito de acción del equipo.
Ver en detalle las diferentes actividades, responsabilidades y herramientas en cómo funciona Scrum.

Compártelo:
• Object 1

• Object 2

• Object 3

• Object 4

• Correo electrónico
•

Object 5

Categorías
• calidad (6)
• como_empezar / transformación Agile (21)
• contratos_agiles (4)
• ejecución (2)
• ejemplos (11)
• entrevistas (4)
• escuela_secundaria (2)
• fundamentos (14)
• ingeniería (2)
• inspección_adaptación (6)
• métricas (5)
• personas / motivación / liderazgo (9)
• planificación_iteración (4)
• planificación_proyecto (13)
• recursos_externos (3)
 • simulaciones y juegos (2)
• Sin categoría (28)

Entradas recientes
• Master en Agile – MMA 2019
• Cómo desescalar una organización – Un caso real
• Refactorización organizativa Agile – Parte 2
• Refactorización organizativa Agile – Parte 1
• Auto-organización – Fundamentos y relación con la motivación intrínseca

Ver todos los artículos

Comentarios recientes
Xavier Albaladejo en Métricas de iteración (Scrum s…

Lisbeth Mavarez en Métricas de iteración (Scrum s…

Xavier Albaladejo en Videos cortos sobre planificac…

Juana M. Contreras C… en Videos cortos sobre planificac…

Xavier Albaladejo en El expendedor – Juego de…

Suscríbete al RSS
• Registrarse
• Acceder
• de las entradas
• de los comentarios
• WordPress.com

Colaboraciones
Metodología Scrum
¿Qué es?

Scrum es una metodología á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.

¿Cuándo se utiliza?

Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve
crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los
objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el
inicio de cada nueva iteración sin ningún problema.

Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma
parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus
capacidades.

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.
• 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.
Si desea conocer más acerca de Scrum, consulte aquí cómo es el proceso y roles que intervienen.
En este artículo, resumo Qué Es la Metodología Scrum. Aquí encontrarás todo lo que necesitas saber
sobre el método Scrum

¿QUÉ ES LA METODOLOGÍA SCRUM?

Muchos de mis lectores me preguntan continuamente “¿Qué es la Metodología Scrum?” Ahora traigo
un largo artículo describiendo todo el proceso. Este artículo está basado en la Guía Scrum.
Se define Scrum como una estructura en la que las personas pueden abordar complejos problemas
adaptativos, siendo a la vez productivas y creativas para entregar productos finales de gran valor.
Scrum también incorpora varios elementos, como que es ligero y fácil de entender. Eso sí, es difícil de
dominar.
Una Mirada más Profunda de la Metodología Scrum
Como ya se ha mencionado, Scrum es una estructura de procesos, y se lleva usando desde los inicios de
los años 90. Se usa Scrum para la dirección del desarrollo de productos complejos, y varios procesos y
técnicas garantizan que esto ocurre. Cuando pretendes mejorar tus prácticas de dirección y desarrollo,
Scrum puede ayudarte a aclarar la relativa eficacia de tu gestión de productos.
La estructura está compuesta de Equipos Scrum que llevan a cabo una serie de funciones, tienen
diferentes utensilios y eventos y siguen una serie de reglas. Cada parte de la estructura tiene un
propósito, que trabaja hacia el éxito de Scrum.
Este artículo explica todo lo que necesitas saber sobre Scrum, incluyendo las reglas y relaciones
implicadas. Además, hay diferentes discusiones sobre tácticas que revelan las diferentes maneras en las
que se puede trabajar con la Estructura Scrum.

Entendiendo Scrum: Teoría de Scrum

Para entender Scrum, es importante echar un vistazo a sus fundamentos básicos. Scrum se ha fundado
sobre una teoría empírica de control de procesos, que también se conoce como empirismo. Lo que
afirma esta teoría es que el conocimiento se basa en la toma de decisiones y en la experiencia de los
factores conocidos.
Por tanto, Scrum busca cómo optimizar la predictibilidad y controlar el riesgo utilizando un método
Iterativo e Incremental. Para que esto suceda, hay tres pilares que se deben implementar. Estos son la
Transparencia, la Inspección y la Adaptación.

Transparencia
Hay partes de este proceso que necesitan ser visibles para aquellos responsables de los resultados. Esto
requiere definiciones estándar de todos los aspectos para asegurarse de que hay un entendimiento
común de todas las observaciones. Considera estos ejemplos: –
• Todos los participantes en el proceso deben usar un lenguaje común
• Tanto aquellos que llevan a cabo el trabajo, como los que aceptan el resultado, deben tener una
definición estándar de “Finalizado”.

Inspección
Aquellos que usan Scrum necesitan inspeccionar periódicamente los instrumentos Scrum y el progreso
del Objetivo en el Sprint. Esto asegura que puedan detectar variaciones no deseadas a tiempo. Las
inspecciones deben llevarse a cabo de vez en cuando, de manera que no se interrumpa el trabajo en
progreso. Los inspectores cualificados se aseguran de que todas las inspecciones se hacen de manera
correcta y son beneficiosas.
Adaptación
Después de una inspección, puede revelarse que uno o más aspectos del proceso se ha desviado de los
límites aceptables. Esto significa que el producto final podría no ser aceptable y que es necesario hacer
algún ajuste en el proceso o el material que se está usando. Cuanto antes ocurra, mejor, de manera que
se eviten más desviaciones.

Equipo Scrum
Tres miembros componen el Equipo Scrum básico, y son el Product Owner, el Equipo de Desarrollo y
el Scrum Master. Se espera que estos equipos se auto-organicen y sean multifuncionales. Cuando se
auto-organizan, pueden elegir la mejor manera de finalizar el trabajo y no tener en cuenta la orientación
que puedan dar personas que no sean del equipo.
Como equipos multifuncionales, tienen todas las competencias para para realizar el trabajo, sin
depender de otras personas fuera del equipo. El objetivo del equipo es optimizar la flexibilidad, la
creatividad y la productividad.
Los Equipos Scrum entregan productos de manera iterativa e incremental, aprovechando el feedeback
que les llega. Las entregas incrementales de productos “Finalizados” asegura que siempre está
disponible una versión funcional del producto. Si quieres conseguir un equipo óptimo, echa un vistazo
a estos dos artículos: “Cómo Conseguir un Gran Equipo Ágil” y “Cómo Llevar a Cabo una Reunión
Inicial de Equipo”.

El Product Owner
Cuando se trata de maximizar el valor del producto y el trabajo del Equipo de Desarrollo, es el Product
Owner el responsable de ello. Esto varía según los Equipos Scrum y las personas del equipo. El
Product Owner tiene la responsabilidad de gestionar el Backlog del Producto. Esta gestión incluye:
• Expresar claramente los elementos del backlog de Producto
• Ordenar los elementos del Backlog de Producto para alcanzar las misiones y los objetivos
• Optimizar el valor del trabajo que realiza el Equipo de Desarrollo
• Asegurar que el Backlog de Producto es visible, transparente y claro.

Esto revela en qué debería trabajar el Equipo Scrum y asegura que el Equipo de Desarrollo comprende
perfectamente los elementos del Backlog de Producto al nivel requerido. Aunque el Product Owner
podría delegar este trabajo en el Equipo de Desarrollo, son responsables del resultado.
El Product Owner es una persona y no un comité. Si existe un comité en funcionamiento, pueden
presentar sus deseos en el backlog de Producto. Aquellos que quieran hacer cualquier ajuste, necesitan
consultar al Product Owner.
Para garantizar que el Product Owner tiene éxito, todas las personas de la organización deben respetar
sus decisiones, que son visibles en el contenido y orden del Backlog de Producto. No hay nadie capaz
de ordenar al Equipo de Desarrollo trabajar con requisitos distintos, y el Equipo de Desarrollo también
tiene sus acciones limitadas bajo las instrucciones de otra persona.

El Equipo de Desarrollo
Es un equipo formado por profesionales que trabajan para entregar un Incremento de producto
“Finalizado” que se pueda lanzar al final de cada Sprint. Solo los miembros de este equipo pueden
crear el Incremento.
La organización asegura que el Equipo de Desarrollo está empoderado para organizar y gestionar su
trabajo. La sinergia que ocurre, como resultado, optimizará la eficiencia y efectividad del Equipo de
Desarrollo. Estos equipos tienen las siguientes características:
• Se auto-organizan. No reciben instrucciones ni consejo de nadie sobre cómo convertir el
Backlog de Producto en Incrementos de funcionalidades potencialmente liberables.
• Son multifuncionales y tienen todas las habilidades necesarias para crear un Incremento de
producto.
• Scrum no otorga ningún título al Equipo de Desarrollo. Todo el mundo es desarrollador, sin
importar el trabajo que desempeñen. Esto se aplica sin excepciones.
• Dentro del Equipo de Desarrollo, el Scrum reconoce que no hay sub-equipos. Esto ocurre
incluso cuando hay muchos dominios que tienen que ser tratados, como el análisis de negocios
o el testeo. Esto se aplica sin excepciones.
• Cada miembro del Equipo de Desarrollo podría tener una habilidad o zona de confort especial,
pero si hablamos de responsabilidades, se considera al equipo como un todo.
El Equipo de Desarrollo se compone de muchas personas, siendo tres el número óptimo. Esto asegura
que se mantienen ágiles y son un lo suficientemente grandes para finalizar todo el trabajo que se debe
hacer en un Sprint.
Si el equipo tiene menos de tres miembros, la interacción puede verse reducida, lo que significa que se
tendrá menor productividad. Además, los Equipos de Desarrollo pequeños pueden ver restringidas sus
capacidades durante el Sprint, significando que podrían no ser capaces de entregar un Incremento
potencialmente liberable.
Los equipos grandes, como aquellos con más de nueve miembros, necesitan mucha más coordinación.
Acaban generando demasiada complejidad como para gestionar un proceso empírico. Al contar al
Equipo de Desarrollo, no se cuenta al Product Owner ni al Scrum Master a no ser que también estén
realizando el trabajo del Backlog del Sprint.

El Scrum Master
El Scrum Master tiene la responsabilidad de asegurar que se ha entendido y aprobado el método Scrum.
Trabajan con el Equipo Scrum, por lo que pueden adherirse a la teoría, prácticas y reglas de Scrum. El
Scrum Master es esencialmente el líder-ayudante del Equipo Scrum. Si te encuentras en la situación de
que eres el Scrum Master de dos equipos, echa un vistazo a: “Las Dos Preguntas más Importantes sobre
Liderar 2 Equipos como Scrum Master”.
El Scrum Master ayuda a las personas que no están en el Equipo Scrum a entender cuáles de sus
interacciones con el Equipo Scrum son útiles y cuáles no.

Entendiendo el Servicio del Scrum Master

Hay tres grupos de Servicio del Scrum Master, y estos incluyen:

El Servicio del Scrum Master para el Product Owner

Esto se hace de numerosas maneras, incluyendo:
• Encontrar técnicas para gestionar de manera efectiva el Backlog de Producto
• Ayudar al Equipo Scrum a entender la necesidad de tener elementos claros y concisos en el
backlog de Producto
• Comprensión del planteamiento de producto en un ambiente empírico
• Asegurar que el Product Owner conoce la mejor manera de organizar el backlog de Producto
para maximizar el valor
• Comprensión y práctica de la agilidad.
• Facilitar eventos de Scrum según se requiera

El Servicio del Scrum Master para el Equipo de Desarrollo

Aquí, el Scrum Master ayudará al Equipo de Desarrollo de las siguientes maneras:
• Actuar de coach en temas de auto-organización y multifuncionalidad
• Ayudar al Equipo de Desarrollo a crear productos de alto valor
• Eliminar los Impedimentos del progreso del Equipo de Desarrollo
• Facilitar eventos de Scrum según se requiera
• Actuar como coach en ambientes de organización donde el método Scrum no ha sido totalmente
adoptado o entendido

Servicio del Scrum Master para la Organización

Los Scrum Masters pueden ayudar a la organización de varias maneras, como:
• Liderar al equipo y actuar de coach en la adopción del método Scrum
• Planear la implementación de Scrum en la organización
• Ayudar a empleados y partes interesadas a entender el desarrollo de Scrum y el desarrollo
empírico de productos
• Causar cambios que lleven al incremento de la productividad del Equipo Scrum
• Trabajar con otros Scrum Masters para aumentar la efectividad de la implantación de Scrum en
la organización
Valores de Scrum
Hay muchos valores que el Equipo Scrum debe encarnar. Estos son el coraje, el compromiso, la
sinceridad, el respeto Estos valores son básicos para erigir los pilares del método Scrum y conseguir
confianza con todas las personas envueltas en él.
Los miembros del Equipo Scrum aprenden y exploran estos valores al trabajar en eventos y roles de
Scrum. Para que el método Scrum tenga éxito, es necesario que los miembros del equipo sean
competentes en estas cinco características.
Así lo hacen:
• Tienen el coraje para hacer lo que es correcto y abordar los problemas graves
• Se comprometen a alcanzar los objetivos del equipo
• Los inversores y el equipo acuerdan hablar abiertamente sobre el trabajo y las dificultades que
tiene el mismo
• Se respetan los unos a los otros y confían en que son independientes y capaces
• Se centran en el trabajo del Sprint y los objetivos del equipo

Eventos de Scrum: Inspección y Eventos de Adaptación

Son normalmente eventos programados que se usan en Scrum. Normalmente regulan y minimiza la
necesidad de llevar a cabo reuniones no planeadas. Todos estos eventos son de tiempo limitado, lo que
significa que tienen una duración máxima.
En el momento que un evento, como un Sprint, comienza, tiene una duración fija que no puede
cambiarse. Una vez que se cumple el objetivo del evento, todos los eventos restantes pueden
finalizarse. Esto asegura que se gasta el mínimo tiempo posible en el proceso.
Cada evento da la oportunidad de inspeccionar o adaptar algo y ha sido diseñado para permitir una
transparencia radical. Hay cuatro eventos formales programados en el método Scrum, que son: –
• Planificación del Sprint
• Scrum Diario
• Revisión del Sprint
• Retrospectiva del Sprint

Entendiendo el Sprint
El corazón del método Scrum es el Sprint. Se puede definir como un periodo de tiempo de un mes o
menos en el que se crea un producto liberable, utilizable y “Finalizado”. Normalmente tienen una
duración consistente durante un periodo de desarrollo. Los sprints deberían tener duraciones constantes
durante todo el desarrollo. Un nuevo Sprint comienza solo cuando el anterior ha finalizado.
Los Sprints contienen y consisten de la Planificación del Sprint, los Scrums Diarios, la Revisión del
Sprint, la Retrospectiva del Sprint y el Trabajo de Desarrollo.
Cuando el Sprint está en curso, no debería haber ninguna alteración que pudiera afectar al objetivo del
mismo, los objetivos cualitativos no descienden, y el enfoque podría ser aclarado y renegociado entre el
Product Owner y el Equipo de Desarrollo.
Es seguro considerar cada Sprint como un proyecto de un mes en el que se ha de conseguir algo. Por
esta razón, en el Sprint se define claramente qué se va a construir, diseñar, un plan para la producción,
el trabajo y el producto final. Si el Sprint durara más de un mes, la definición de lo que se va a crear
cambiaría, y el riesgo podría subir junto a la complejidad general. Los Sprints son importantes ya que
aseguran que el trabajo es predecible y puede ser inspeccionado y adaptado mientras se trabaja por el
objetivo del Sprint. Limitan el riesgo, particularmente si nos fijamos en el coste.
Es posible cancelar un Sprint antes de que finalice. Sin embargo, la única persona que puede hacer esto
es el Product Owner. La decisión puede estar influenciada por otros, incluyendo las partes interesadas,
el Equipo de Desarrollo o el Scrum Master. Una cancelación puede hacerse efectiva cuando el Objetivo
del Sprint se vuelve obsoleto.
La obsolescencia puede estar causada por el azar en la dirección, las condiciones del mercado o las
condiciones de la tecnología. Si el Sprint deja de tener sentido, debería ser cancelado. Sin embargo,
verás que raramente se cancela un Sprint, ya que tienen una duración bastante corta.
Hay una serie de pasos que hay que cumplir al cancelar un Sprint. Se revisan primero los elementos
completados y “Finalizados” del Backlog de Producto. Si algo del trabajo del Sprint puede liberarse,
será aceptado por el Product Owner. Esos elementos que son incompetentes en el backlog de Producto
se reestiman y devuelven al Backlog de Producto. Ya que este tipo de trabajo se puede depreciar
rápidamente, se debe revalorar frecuentemente.
Las cancelaciones desaniman, ya que consumen recursos. Esto se debe a que todas las personas
envueltas en el Sprint tienen que reagruparse y realizar otro proceso de planificación del Sprint, para
comenzar uno nuevo. Causan malestar en el equipo y se trata de evitarlas.

Planificación del Sprint

Cualquier trabajo que va a hacerse en el Sprint se planea en la Planificación del Sprint. La planificación
une al Equipo Scrum y se crea mediante un trabajo colaborativo. La planificación del Sprint tiene una
duración concreta de ocho horas como máximo para un Sprint de un mes; aquí puedes encontrar
sugerencias sobre cómo llevar a cabo una efectiva planificación del sprint.
Cuando el Sprint dura menos, también el evento tiene a ser más corto. Depende del Scrum Master
asegurar que el evento tiene lugar y que los asistentes entienden la razón del mismo. El Scrum Master
enseñará al equipo a man
En este artículo, resumo Qué Es la Metodología Scrum. Aquí encontrarás todo lo que necesitas saber
sobre el método Scrum
¿QUÉ ES LA METODOLOGÍA SCRUM?
Muchos de mis lectores me preguntan continuamente “¿Qué es la Metodología Scrum?” Ahora traigo
un largo artículo describiendo todo el proceso. Este artículo está basado en la Guía Scrum.
Se define Scrum como una estructura en la que las personas pueden abordar complejos problemas
adaptativos, siendo a la vez productivas y creativas para entregar productos finales de gran valor.
Scrum también incorpora varios elementos, como que es ligero y fácil de entender. Eso sí, es difícil de
dominar.

Una Mirada más Profunda de la Metodología Scrum

Como ya se ha mencionado, Scrum es una estructura de procesos, y se lleva usando desde los inicios de
los años 90. Se usa Scrum para la dirección del desarrollo de productos complejos, y varios procesos y
técnicas garantizan que esto ocurre. Cuando pretendes mejorar tus prácticas de dirección y desarrollo,
Scrum puede ayudarte a aclarar la relativa eficacia de tu gestión de productos.
La estructura está compuesta de Equipos Scrum que llevan a cabo una serie de funciones, tienen
diferentes utensilios y eventos y siguen una serie de reglas. Cada parte de la estructura tiene un
propósito, que trabaja hacia el éxito de Scrum.
Este artículo explica todo lo que necesitas saber sobre Scrum, incluyendo las reglas y relaciones
implicadas. Además, hay diferentes discusiones sobre tácticas que revelan las diferentes maneras en las
que se puede trabajar con la Estructura Scrum.

Entendiendo Scrum: Teoría de Scrum

Para entender Scrum, es importante echar un vistazo a sus fundamentos básicos. Scrum se ha fundado
sobre una teoría empírica de control de procesos, que también se conoce como empirismo. Lo que
afirma esta teoría es que el conocimiento se basa en la toma de decisiones y en la experiencia de los
factores conocidos.
Por tanto, Scrum busca cómo optimizar la predictibilidad y controlar el riesgo utilizando un método
Iterativo e Incremental. Para que esto suceda, hay tres pilares que se deben implementar. Estos son la
Transparencia, la Inspección y la Adaptación.

Transparencia
Hay partes de este proceso que necesitan ser visibles para aquellos responsables de los resultados. Esto
requiere definiciones estándar de todos los aspectos para asegurarse de que hay un entendimiento
común de todas las observaciones. Considera estos ejemplos: –
• Todos los participantes en el proceso deben usar un lenguaje común
• Tanto aquellos que llevan a cabo el trabajo, como los que aceptan el resultado, deben tener una
definición estándar de “Finalizado”.
Inspección
Aquellos que usan Scrum necesitan inspeccionar periódicamente los instrumentos Scrum y el progreso
del Objetivo en el Sprint. Esto asegura que puedan detectar variaciones no deseadas a tiempo. Las
inspecciones deben llevarse a cabo de vez en cuando, de manera que no se interrumpa el trabajo en
progreso. Los inspectores cualificados se aseguran de que todas las inspecciones se hacen de manera
correcta y son beneficiosas.

Adaptación
Después de una inspección, puede revelarse que uno o más aspectos del proceso se ha desviado de los
límites aceptables. Esto significa que el producto final podría no ser aceptable y que es necesario hacer
algún ajuste en el proceso o el material que se está usando. Cuanto antes ocurra, mejor, de manera que
se eviten más desviaciones.

Equipo Scrum
Tres miembros componen el Equipo Scrum básico, y son el Product Owner, el Equipo de Desarrollo y
el Scrum Master. Se espera que estos equipos se auto-organicen y sean multifuncionales. Cuando se
auto-organizan, pueden elegir la mejor manera de finalizar el trabajo y no tener en cuenta la orientación
que puedan dar personas que no sean del equipo.
Como equipos multifuncionales, tienen todas las competencias para para realizar el trabajo, sin
depender de otras personas fuera del equipo. El objetivo del equipo es optimizar la flexibilidad, la
creatividad y la productividad.
Los Equipos Scrum entregan productos de manera iterativa e incremental, aprovechando el feedeback
que les llega. Las entregas incrementales de productos “Finalizados” asegura que siempre está
disponible una versión funcional del producto. Si quieres conseguir un equipo óptimo, echa un vistazo
a estos dos artículos: “Cómo Conseguir un Gran Equipo Ágil” y “Cómo Llevar a Cabo una Reunión
Inicial de Equipo”.

El Product Owner
Cuando se trata de maximizar el valor del producto y el trabajo del Equipo de Desarrollo, es el Product
Owner el responsable de ello. Esto varía según los Equipos Scrum y las personas del equipo. El
Product Owner tiene la responsabilidad de gestionar el Backlog del Producto. Esta gestión incluye:
• Expresar claramente los elementos del backlog de Producto
• Ordenar los elementos del Backlog de Producto para alcanzar las misiones y los objetivos
• Optimizar el valor del trabajo que realiza el Equipo de Desarrollo
• Asegurar que el Backlog de Producto es visible, transparente y claro.
Esto revela en qué debería trabajar el Equipo Scrum y asegura que el Equipo de Desarrollo comprende
perfectamente los elementos del Backlog de Producto al nivel requerido. Aunque el Product Owner
podría delegar este trabajo en el Equipo de Desarrollo, son responsables del resultado.
El Product Owner es una persona y no un comité. Si existe un comité en funcionamiento, pueden
presentar sus deseos en el backlog de Producto. Aquellos que quieran hacer cualquier ajuste, necesitan
consultar al Product Owner.
Para garantizar que el Product Owner tiene éxito, todas las personas de la organización deben respetar
sus decisiones, que son visibles en el contenido y orden del Backlog de Producto. No hay nadie capaz
de ordenar al Equipo de Desarrollo trabajar con requisitos distintos, y el Equipo de Desarrollo también
tiene sus acciones limitadas bajo las instrucciones de otra persona.

El Equipo de Desarrollo
Es un equipo formado por profesionales que trabajan para entregar un Incremento de producto
“Finalizado” que se pueda lanzar al final de cada Sprint. Solo los miembros de este equipo pueden
crear el Incremento.
La organización asegura que el Equipo de Desarrollo está empoderado para organizar y gestionar su
trabajo. La sinergia que ocurre, como resultado, optimizará la eficiencia y efectividad del Equipo de
Desarrollo. Estos equipos tienen las siguientes características:
• Se auto-organizan. No reciben instrucciones ni consejo de nadie sobre cómo convertir el
Backlog de Producto en Incrementos de funcionalidades potencialmente liberables.
• Son multifuncionales y tienen todas las habilidades necesarias para crear un Incremento de
producto.
• Scrum no otorga ningún título al Equipo de Desarrollo. Todo el mundo es desarrollador, sin
importar el trabajo que desempeñen. Esto se aplica sin excepciones.
• Dentro del Equipo de Desarrollo, el Scrum reconoce que no hay sub-equipos. Esto ocurre
incluso cuando hay muchos dominios que tienen que ser tratados, como el análisis de negocios
o el testeo. Esto se aplica sin excepciones.
• Cada miembro del Equipo de Desarrollo podría tener una habilidad o zona de confort especial,
pero si hablamos de responsabilidades, se considera al equipo como un todo.
El Equipo de Desarrollo se compone de muchas personas, siendo tres el número óptimo. Esto asegura
que se mantienen ágiles y son un lo suficientemente grandes para finalizar todo el trabajo que se debe
hacer en un Sprint.
Si el equipo tiene menos de tres miembros, la interacción puede verse reducida, lo que significa que se
tendrá menor productividad. Además, los Equipos de Desarrollo pequeños pueden ver restringidas sus
capacidades durante el Sprint, significando que podrían no ser capaces de entregar un Incremento
potencialmente liberable.
Los equipos grandes, como aquellos con más de nueve miembros, necesitan mucha más coordinación.
Acaban generando demasiada complejidad como para gestionar un proceso empírico. Al contar al
Equipo de Desarrollo, no se cuenta al Product Owner ni al Scrum Master a no ser que también estén
realizando el trabajo del Backlog del Sprint.

El Scrum Master
El Scrum Master tiene la responsabilidad de asegurar que se ha entendido y aprobado el método Scrum.
Trabajan con el Equipo Scrum, por lo que pueden adherirse a la teoría, prácticas y reglas de Scrum. El
Scrum Master es esencialmente el líder-ayudante del Equipo Scrum. Si te encuentras en la situación de
que eres el Scrum Master de dos equipos, echa un vistazo a: “Las Dos Preguntas más Importantes sobre
Liderar 2 Equipos como Scrum Master”.
El Scrum Master ayuda a las personas que no están en el Equipo Scrum a entender cuáles de sus
interacciones con el Equipo Scrum son útiles y cuáles no.

Entendiendo el Servicio del Scrum Master

Hay tres grupos de Servicio del Scrum Master, y estos incluyen:

El Servicio del Scrum Master para el Product Owner

Esto se hace de numerosas maneras, incluyendo:
• Encontrar técnicas para gestionar de manera efectiva el Backlog de Producto
• Ayudar al Equipo Scrum a entender la necesidad de tener elementos claros y concisos en el
backlog de Producto
• Comprensión del planteamiento de producto en un ambiente empírico
• Asegurar que el Product Owner conoce la mejor manera de organizar el backlog de Producto
para maximizar el valor
• Comprensión y práctica de la agilidad.
• Facilitar eventos de Scrum según se requiera

El Servicio del Scrum Master para el Equipo de Desarrollo

Aquí, el Scrum Master ayudará al Equipo de Desarrollo de las siguientes maneras:
• Actuar de coach en temas de auto-organización y multifuncionalidad
• Ayudar al Equipo de Desarrollo a crear productos de alto valor
• Eliminar los Impedimentos del progreso del Equipo de Desarrollo
• Facilitar eventos de Scrum según se requiera
• Actuar como coach en ambientes de organización donde el método Scrum no ha sido totalmente
adoptado o entendido
Servicio del Scrum Master para la Organización
Los Scrum Masters pueden ayudar a la organización de varias maneras, como:
• Liderar al equipo y actuar de coach en la adopción del método Scrum
• Planear la implementación de Scrum en la organización
• Ayudar a empleados y partes interesadas a entender el desarrollo de Scrum y el desarrollo
empírico de productos
• Causar cambios que lleven al incremento de la productividad del Equipo Scrum
• Trabajar con otros Scrum Masters para aumentar la efectividad de la implantación de Scrum en
la organización

Valores de Scrum
Hay muchos valores que el Equipo Scrum debe encarnar. Estos son el coraje, el compromiso, la
sinceridad, el respeto Estos valores son básicos para erigir los pilares del método Scrum y conseguir
confianza con todas las personas envueltas en él.
Los miembros del Equipo Scrum aprenden y exploran estos valores al trabajar en eventos y roles de
Scrum. Para que el método Scrum tenga éxito, es necesario que los miembros del equipo sean
competentes en estas cinco características.
Así lo hacen:
• Tienen el coraje para hacer lo que es correcto y abordar los problemas graves
• Se comprometen a alcanzar los objetivos del equipo
• Los inversores y el equipo acuerdan hablar abiertamente sobre el trabajo y las dificultades que
tiene el mismo
• Se respetan los unos a los otros y confían en que son independientes y capaces
• Se centran en el trabajo del Sprint y los objetivos del equipo

Eventos de Scrum: Inspección y Eventos de Adaptación

Son normalmente eventos programados que se usan en Scrum. Normalmente regulan y minimiza la
necesidad de llevar a cabo reuniones no planeadas. Todos estos eventos son de tiempo limitado, lo que
significa que tienen una duración máxima.
En el momento que un evento, como un Sprint, comienza, tiene una duración fija que no puede
cambiarse. Una vez que se cumple el objetivo del evento, todos los eventos restantes pueden
finalizarse. Esto asegura que se gasta el mínimo tiempo posible en el proceso.
Cada evento da la oportunidad de inspeccionar o adaptar algo y ha sido diseñado para permitir una
transparencia radical. Hay cuatro eventos formales programados en el método Scrum, que son: –
• Planificación del Sprint
 • Scrum Diario
• Revisión del Sprint
• Retrospectiva del Sprint

Entendiendo el Sprint
El corazón del método Scrum es el Sprint. Se puede definir como un periodo de tiempo de un mes o
menos en el que se crea un producto liberable, utilizable y “Finalizado”. Normalmente tienen una
duración consistente durante un periodo de desarrollo. Los sprints deberían tener duraciones constantes
durante todo el desarrollo. Un nuevo Sprint comienza solo cuando el anterior ha finalizado.
Los Sprints contienen y consisten de la Planificación del Sprint, los Scrums Diarios, la Revisión del
Sprint, la Retrospectiva del Sprint y el Trabajo de Desarrollo.
Cuando el Sprint está en curso, no debería haber ninguna alteración que pudiera afectar al objetivo del
mismo, los objetivos cualitativos no descienden, y el enfoque podría ser aclarado y renegociado entre el
Product Owner y el Equipo de Desarrollo.
Es seguro considerar cada Sprint como un proyecto de un mes en el que se ha de conseguir algo. Por
esta razón, en el Sprint se define claramente qué se va a construir, diseñar, un plan para la producción,
el trabajo y el producto final. Si el Sprint durara más de un mes, la definición de lo que se va a crear
cambiaría, y el riesgo podría subir junto a la complejidad general. Los Sprints son importantes ya que
aseguran que el trabajo es predecible y puede ser inspeccionado y adaptado mientras se trabaja por el
objetivo del Sprint. Limitan el riesgo, particularmente si nos fijamos en el coste.
Es posible cancelar un Sprint antes de que finalice. Sin embargo, la única persona que puede hacer esto
es el Product Owner. La decisión puede estar influenciada por otros, incluyendo las partes interesadas,
el Equipo de Desarrollo o el Scrum Master. Una cancelación puede hacerse efectiva cuando el Objetivo
del Sprint se vuelve obsoleto.
La obsolescencia puede estar causada por el azar en la dirección, las condiciones del mercado o las
condiciones de la tecnología. Si el Sprint deja de tener sentido, debería ser cancelado. Sin embargo,
verás que raramente se cancela un Sprint, ya que tienen una duración bastante corta.
Hay una serie de pasos que hay que cumplir al cancelar un Sprint. Se revisan primero los elementos
completados y “Finalizados” del Backlog de Producto. Si algo del trabajo del Sprint puede liberarse,
será aceptado por el Product Owner. Esos elementos que son incompetentes en el backlog de Producto
se reestiman y devuelven al Backlog de Producto. Ya que este tipo de trabajo se puede depreciar
rápidamente, se debe revalorar frecuentemente.
Las cancelaciones desaniman, ya que consumen recursos. Esto se debe a que todas las personas
envueltas en el Sprint tienen que reagruparse y realizar otro proceso de planificación del Sprint, para
comenzar uno nuevo. Causan malestar en el equipo y se trata de evitarlas.
Planificación del Sprint
Cualquier trabajo que va a hacerse en el Sprint se planea en la Planificación del Sprint. La planificación
une al Equipo Scrum y se crea mediante un trabajo colaborativo. La planificación del Sprint tiene una
duración concreta de ocho horas como máximo para un Sprint de un mes; aquí puedes encontrar
sugerencias sobre cómo llevar a cabo una efectiva planificación del sprint.
Cuando el Sprint dura menos, también el evento tiene a ser más corto. Depende del Scrum Master
asegurar que el evento tiene lugar y que los asistentes entienden la razón del mismo. El Scrum Master
enseñará al equipo a mantenerse en la duración establecida.
En la Planificación se responden las preguntas sobre qué se puede liberar en el Incremento del siguiente
Sprint, y cómo se conseguirá realizar el trabajo que se va a liberar.

¿Qué se puede liberar en el siguiente Sprint?

Durante el periodo de Planificación del Sprint, el Equipo de Desarrollo trabajará en pronosticar la
funcionalidad que será desarrollada durante el Sprint. El Product Owner analizará el objetivo que se
busca en el Sprint. Más allá, los elementos del Backlog de Producto que ayudarán a conseguir dicho
objetivo. El Equipo Scrum al completo trabajará conjuntamente para comprender el trabajo del Sprint.
Esta reunión tiene unos aportes principales, que son el Backlog de Producto, el último Incremento de
producto, la capacidad esperada del Equipo de Desarrollo durante el Sprint y el rendimiento previo del
mismo. El Equipo de Desarrollo seleccionará cuántos elementos del Sprint provendrán del backlog de
Producto. Es el Equipo de Desarrollo quien proporcionará información sobre qué pueden conseguir,
basándose en las expectativas del Sprint.
Después del pronóstico de los elementos del Backlog de Producto, el Equipo de Desarrollo llevará a
cabo el Sprint, mientras que el Equipo Scrum podría establecer el Objetivo del Sprint. El Objetivo del
Sprint es el propósito que se alcanzará en el Sprint cuando el Backlog de Producto haya sido
implementado. Sirve como guía para el Equipo de Desarrollo sobre por qué se crea el Incremento.
Si te interesa este tema, hace un tiempo Chris escribió un artículo en el blog: “Cuatro Razones Por las
Que no se Llevan a Cabo las Historias de Usuario Ágiles”, échale un vistazo.

¿Cómo se logrará el trabajo?

Una vez que se ha establecido el Objetivo del Sprint y que los elementos de Backlog de Producto se
han seleccionado, entonces el Equipo de Desarrollo decidido cómo se construirá la funcionalidad para
conseguir un Incremento del producto “Finalizado” durante el Srpint. Los elementos del Backlog de
Producto elegidos para este Sprint, junto al plan para liberarlos, se conoce como Backlog del Sprint.
El Equipo de Desarrollo diseñará un sistema para convertir el Backlog de Producto en un Incremento
de producto funcional. La carga de trabajo puede variar según el esfuerzo necesario y el tamaño del
trabajo. Durante la Planificación del Sprint, el Equipo de Desarrollo pronosticará qué piensan que se
puede conseguir en el siguiente Sprint.
Al final de la reunión, el trabajo planeado para los primeros días del Sprint, que debe realizar el Equipo
de Desarrollo, se descompone en unidades diarias (o menos). La auto-organización tiene lugar a la hora
de realizar el trabajo del Backlog del Sprint, tanto durante la Planificación del Sprint como cuando sea
requerido en el Sprint.
El Product Owner tiene la tarea de ayudar a aclarar los elementos del Backlog de Producto elegidos e
intercambiarlos cuando sea necesario. Si el Equipo de Desarrollo decidiera que es mucho o poco
trabajo, entonces debería ser renegociado basándose en los elementos del Backlog de Producto.
Esto se hace junto al Product Owner. El Equipo de Desarrollo tiene también la libertad de invitar a
otros a asistir en beneficio del dominio o para dar consejos técnicos. Al final de la Planificación del
Sprint, el Equipo de Desarrollo debería tener la capacidad de explicar al Product Owner y al Scrum
Master cómo se realizará el trabajo trabajando como un equipo auto-organizado para alcanzar el
Objetivo del Sprint.

Objetivo del Sprint

Es un objetivo que se pone en el Sprint, que se consigue con facilidad una vez que se ha implementado
el Backlog de Producto. Actúa, de alguna manera, como una guía al Equipo de Desarrollo sobre la
razón por la que se crea el Incremento. El Objetivo del Sprint se establece en la reunión de
Planificación del Sprint.
Se asegura que el Equipo de Desarrollo tiene un nivel de flexibilidad, en relación a la funcionalidad
implementada en el Sprint. El Objetivo del Sprint se entrega a través de los Elementos del Backlog del
Producto y asegura que el Equipo de Desarrollo puede trabajar conjuntamente, en lugar de dividirse en
diferentes iniciativas.
El Equipo de Desarrollo trabaja con el Objetivo del Sprint siempre en la mente, y esto afecta su
funcionalidad y uso de la tecnología. Cuando haya un cambio en las expectativas, el Equipo de
Desarrollo y el Product Owner facilitarán la colaboración para negociar el enfoque que se da al
Backlog de Producto en el Sprint.

Scrum Diario
Cada día, el Equipo de Desarrollo deja 15 minutos para sincronizar sus actividades y desarrollar un
plan para las siguientes 24 horas. Esto se conoce como el Scrum Diario. Incluye una inspección del
trabajo que se ha hecho desde el anterior Scrum Diario y posteriormente se enfatiza sobre el trabajo que
ha de realizarse antes del siguiente.
Es esencial que la hora y el lugar del Scrum Diario sean siempre iguales, ya que esto evitará cualquier
complejidad. En la reunión, el Equipo de Desarrollo se centrará en:
• Qué se hizo el día anterior que ayudó a alcanzar el Objetivo del Sprint
• Qué se ha hecho hoy para ayudar a alcanzar el Objetivo del Sprint
• Qué impedimentos pueden poner trabas a la consecución del Objetivo del Sprint
 •

Esto significa que el Scrum Diario es como una manera de chequear el grado de consecución del
Objetivo del Sprint. Asegura que el trabajo se basa en el Backlog del Sprint y facilita la tarea de
alcanzar el objetivo. Se desafía al Equipo de Desarrollo durante el Scrum Diario a trabajar
conjuntamente como un equipo auto-organizado a través de discusiones detalladas, en las cuales puede
que tengan que adaptar o repetir el trabajo del resto del Sprint.
Es el Scrum Master quien asegura que esta reunión se realiza a diario, aunque está dirigida por el
Equipo de Desarrollo. Los Scrum Masters aseguran que el equipo no se sobresale de los 15 minutos, y
hacen cumplir las reglas de participación.
Los beneficios del Scrum Diario son numerosos, incluyendo la mejora en la comunicación, la no
necesidad de otras reuniones, la identificación de trabas al desarrollo, la rápida toma de decisiones y el
aumento del conocimiento general del Equipo de Desarrollo. Hace un tiempo escribí un artículo sobre
“Cómo llevar a cabo un Scrum Diario efectivo”, al que puedes echar un vistazo.

Revisión del Sprint

La Revisión del Sprint se lleva a cabo una vez que el Sprint ha finalizado. En ella, se inspecciona el
Incremento y se adapta el Backlog de Producto si fuera necesario. Cuando la Revisión del Sprint tiene
lugar, el Equipo Scrum y las partes interesadas evalúan qué se ha hecho durante el Sprint.
El resultado de la discusión podría llevar a adoptar cambios en el backlog de Producto, así como a la
revisión de lo que podría ser optimizado con el objetivo de añadir valor. La revisión sirve para
compartir información y no es una reunión sobre el estado del proyecto. Solo se mantiene para
conseguir algo de feedback y para asegurar que existe colaboración. Duraría unas cuatro horas si el
Sprint fuera de un mes. Si el Sprint fuera más corto, también lo sería la reunión.
Incluye los siguientes elementos:
• Asistencia del Equipo Scrum y de las partes interesadas, invitados por el Product Owner
• El Product Owner explica qué elementos del Backlog de Producto están “Finalizados” y cuáles
no.
• El Equipo de Desarrollo explica qué funcionó durante el Sprint y qué no funcionó, y cómo se
solventaron los problemas
• El Equipo de Desarrollo revela qué se ha “Finalizado” y propone preguntas sobre el Incremento
• El Product Owner habla sobre el estado del Backlog de Producto y posibles fechas de
finalización de los proyectos
• El grupo al completo colabora en los siguientes pasos, de manera que la Revisión del Sprint
proporciona información valiosa para la Planificación de próximos Sprints
• Revisar el mercado o el posible uso del producto, cualquier cambio, y lo mejor para hacer a
continuación
 • Revisar el cronograma, el presupuesto, las capacidades y el mercado para el lanzamiento del
producto
Después de la Revisión del Sprint, el Backlog de Producto se suele revisar, y se definen los elementos
del Backlog de Producto que se utilizarán probablemente en el siguiente Sprint. Puede que se hagan
ajustes generales para encontrar nuevas oportunidades.

Retrospectiva del Sprint

Es una oportunidad para el Equipo Scrum de realizar una inspección sobre lo que se ha realizado y
desarrollar un plan para conseguir mejoras en el siguiente Sprint. Ocurre una vez que la Revisión del
Sprint se ha finalizado, antes de que la Planificación del Sprint vuelva a comenzar.
Es una reunión con una duración concreta de unas tres horas para Sprints de un mes. Sprints más cortos
darán lugar a reuniones más cortas. El Scrum Master se asegurará de que la reunión tiene lugar y los
asistentes entienden claramente su propósito.
El Scrum Master participará como un miembro del equipo para proporcionar información sobre las
responsabilidades en el proceso Scrum. El objetivo de esta reunión es:
• Inspeccionar el último Sprint
• Identificar y ordenar lo que funcionó y lo que necesita ser mejorado
• Desarrollar un plan para implementar mejoras al Equipo Scrum y la manera en que trabajan

El Scrum Master usará esta reunión para animar al Equipo Scrum a mejorar en las prácticas y procesos
del desarrollo. Esto asegurará que el siguiente Sprint sea más efectivo y disfrutable. Se implementan
los planes para elevar la calidad del producto, estableciendo una definición apropiada de producto
“Finalizado”.
Una vez que se ha completado la Retrospectiva del Sprint, el Equipo Scrum habrá identificado qué se
puede mejorar en el siguiente Sprint. Se adoptarán estas mejoras y serán inspeccionadas por el propio
Equipo Scrum. La Retrospectiva del Sprint es una oportunidad formal de centrarse en la inspección y la
adaptación.
Si te interesa este tema, puedes echar un vistazo a mi otro artículo: “La Guía Sobre Las Retrospectivas
Ágiles Que Te Convertirá En Un Magnífico Facilitador”. Mi amigo Marc Loeffler escribió este
artículo: “Las cinco preguntas más comunes sobre las Retrospectivas Ágiles”. Y, por supuesto, si
buscas nuevas ideas para tu Retrospectiva del Sprint, echa un vistazo a: “Ideas sobre las Retrospectivas
Ágiles”.

Elementos de Scrum
Representan el trabajo o valor para proporcionar transparencia, así como oportunidades para la
inspección y la adaptación. Se definen como específicamente diseñadas para maximizar la
transparencia sobre la información clave, de manera que todos tienen el mismo conocimiento del
elemento en cuestión.

El Backlog de Producto
Esto se refiere a una lista ordenada de todas las cosas que se requieren para desarrollar un producto.
Contiene todos los requisitos para cualquier corrección que se tenga que hacer a un producto; el
responsable de ello es el Product Owner.
Es un trabajo en progreso (WIP), y no llega a tener nunca una versión final. Establece los requisitos y
evoluciona a la vez que el producto. Sufre cambios basándose en qué es más conveniente, útil y
competitivo para el producto y existirá mientras que exista el producto.
Contiene una lista de todas las funciones, requisitos, características, mejoras y arreglos, que constituyen
los cambios que tienen que realizarse al producto en la siguiente release. Los elementos del Backlog
del Producto tienen una descripción, orden, estimación y valor.
Cuanto más se use el producto, y obtenga valor, más feedback puede esperarse del mercado. Esto
resultará en el crecimiento del Backlog del Producto, al mismo tiempo que los requisitos evolucionan.
También puede sufrir cambios basados en los requisitos de negocio, condiciones del mercado y la
tecnología.
Donde hay muchos Equipos Scrum, puede que necesiten trabajar juntos en un producto. En Este caso,
solo un Backlog de Producto será utilizado para describir el producto. Para refinar el Backlog del
producto, los detalles, las estimaciones y el orden de los elementos podría ser modificado.
Esto lo realizan mediante la colaboración el Product Owner y el Equipo de Desarrollo. Mientras se
refina, también se revisan los elementos que se quedan dentro. Es el Equipo Scrum quien decide cómo
se realizará el perfeccionamiento, de manera que no se coja más del 10% de la capacidad del Equipo de
Desarrollo. El Product Owner tiene la capacidad de actualizar los elementos del Backlog del Producto
en cualquier momento.
Hay elementos del Backlog del Producto ordenados más arriba y otros más abajo, siendo los que están
más arriba los más aclarados y detallados. Son los que están arriba los elementos que pueden ser
“Finalizados” por el Equipo de Desarrollo, y pueden ser considerados como “Listos” para la selección
en la Planificación del Sprint.
El Equipo de Desarrollo es responsable de todas las estimaciones, ya que son los que van a realizar el
trabajo.

Monitorizar el Progeso de Cara a Conseguir un Objetivo

Es posible calcular la cantidad de trabajo necesaria para alcanzar un objetivo. Durante la Revisión del
Sprint, el Product Owner establecerá cuánto trabajo queda por hacer. Se realiza una comparación entre
el trabajo sobrante de Revisiones de Sprint pasadas y el progreso necesario para completar el Sprint
actual en el tiempo que se ha establecido. Esta información se comparte después con todas las partes
que están involucradas.
Para pronosticar el progreso, se utilizan gráficos burn-up y burn down y diagramas de flujo acumulado.
Allá donde existe un ambiente complejo, el resultado podría ser desconocido, de manera que solo lo
que ha ocurrido en el pasado sería tomado en cuenta a la hora de tomar decisiones.

Backlog del Sprint

Se conoce a los elementos del Backlog de Producto que se han seleccionado para el Sprint como el
Backlog del Sprint. Incluyen también el plan para entregar el Incremento del Producto y alcanzar el
Objetivo del Sprint. Fundamentalmente, el Backlog del Sprint es un pronóstico del Equipo de
Desarrollo que se centra en saber cuán funcional será cada Incremento, así como el trabajo que es
necesario para convertir la funcionalidad en un Incremento “Finalizado”.
El Backlog del Sprint asegura que todo el trabajo realizado por el Equipo de Desarrollo es visible y que
se puede alcanzar el Objetivo del Sprint. El Backlog del Sprint es esencialmente un plan que contiene
el detalle necesario para que en el Scrum Diario se comprendan los cambios realizados.
El Equipo de Desarrollo puede modificar el Backlog del Sprint durante todo el Sprint y después surgir
durante el Sprint, mientras que el Equipo de Desarrollo trabaja en el plan. Esto se debe a que se
aprende más sobre el trabajo necesario para alcanzar el Objetivo del Sprint.
Si existe la necesidad de finalizar el trabajo, el Equipo de Desarrollo lo añade al Backlog del Sprint.
Mientras se completa, el trabajo restante se actualiza. Por el camino, se elimina cualquier elemento del
plan que no sea necesario.
Solo el Equipo de Desarrollo puede cambiar el Backlog del Producto en el curso de un Sprint. El
Backlog del Sprint es como una huella visible para el Equipo de Desarrollo y pertenece solamente a
este equipo.

Monitorizar el Progreso del Sprint

Durante el Sprint, se puede resumir el Backlog del Sprint en cualquier comento. Depende del Equipo
de Desarrollo el monitorizar en cada Scrum Diario el trabajo restante para alcanzar el Objetivo del
Sprint. Monitorizarlo le permite al Equipo de Desarrollo gestionar el progreso del proyecto.

Incremento
Se puede resumir todo el trabajo que resta del Backlog del Sprint en cualquier momento. El Incremento
es la suma de esto y del valor de cualquier otro Incremento de Sprints previos. El incremento final al
terminar el Sprint debería estar “Finalizando”, que significa que está en una condición utilizable y
cumple con la definición establecida por el Equipo Scrum. La condición utilizable es indispensable, sea
cual sea la decisión del Product Owner de lanzarlo o no.
Transparencia en los Elementos
Para que el método Scrum sea como es, la transparencia es esencial. Es la base de las decisiones que se
toman para optimizar el valor y el control del riesgo. El grado de cumplimiento de la transparencia
determina si las decisiones son correctas o no. Si los elementos no son completamente transparentes,
entonces las decisiones tienen defectos y su valor disminuye. Además, el riesgo aumentará.
El Scrum Master debe trabajar con todas las partes participantes, incluyendo el Product Owner y el
Equipo de Desarrollo, para asegurar que los elementos son totalmente transparentes. En el caso de que
no exista una fuerte transparencia, hay prácticas para salir adelante.
El Scrum Master debe a ayudar a todos a aplicar las prácticas más apropiadas para conseguir una buena
transparencia. Un Scrum Master puede detectar una transparencia incompleta mediante la inspección
de los elementos, el razonamiento sobre los patrones y la observación cuidadosa de toda la información
disponible.
Desde aquí, se pueden detectar las diferencias entre los resultados reales y los esperados. El Scrum
Master ha de trabajar con el Equipo Scrum y la organización para aumentar la transparencia de los
elementos. Esto se consigue mediante el aprendizaje, el convencimiento y los cambios, y requiere un
largo camino.

Definición de “Finalizado”
El término “Finalizado” ha aparecido bastantes veces en este texto. Cuando se dice que un elemento del
backlog del Producto o un Incremento está “Finalizado”, es muy importante que todas las partes
involucradas entiendan el significado.
Está directamente relacionado con completar el trabajo y asegura que existe transparencia. Para el
Equipo Scrum, “Finalizado” significa que el trabajo está completado en el Incremento del producto.
Hace un tiempo, escribí un ejemplo de una “Checklist de la Definición de Finalizado”. Es esta la
definición que servirá como guía para el Equipo de Desarrollo en el número de elementos del Backlog
del Producto que deberían seleccionarse durante la Planificación del Sprint. La razón de existencia de
cada Sprint es entregar Incrementos de funcionalidades potencialmente liberables que cumplan con la
definición de “Finalizado” del Equipo Scrum.
Con cada Sprint, el Equipo de Desarrollo debería entregar un Incremento de funcionalidades del
producto. Es utilizable y un Product Owner podría decidir lanzarlo inmediatamente. En el evento en el
cual la definición de “Finalizado” para un Incremento es parte de las costumbres o estándares de la
organización de desarrollo, entonces todos los Equipos Scrum deben seguirla.
En el evento en el cual la definición de “Finalizado” no es un estándar de la organización de desarrollo,
entonces se pide al Equipo de Desarrollo del Equipo Scrum traer una definición de “Finalizado” que
vaya en la línea del producto. Allí donde hay muchos Equipos Scrum trabajando en el lanzamiento del
producto, los Equipos de Desarrollo de todos ellos deben definir mutuamente el término “Finalizado”.
Cada Incremento es acumulable a los Incrementos anteriores y se prueba minuciosamente. Esto asegura
que todos trabajan conjuntamente.
A la vez que los Equipos Scrum maduran, sus definiciones de “Finalizado” se expanden para incluir
más criterios. Aquí presento algunas sugerencias para empezar con este acercamiento. Todos los
sistemas y productos necesitan una definición de “Finalizado”, que es el estándar que se aplica al
trabajo realizado en ellos.
Creo que esto resume todo acerca de “Qué Es La Metodología Scrum”. Puedes comentar debajo lo que
te apetezca.

Trabajar Conmigo o Con Evolution4All

He desarrollado el “Organisational Mastery”. El objetivo de este producto es crear un aliado que
impulse los cambios y la innovación interna junto a la distribución de la información en toda la
organización. Es muy adecuado para las empresas que quieren mejorar drásticamente la alineación
entre el liderazgo ejecutivo y los equipos de ejecución.

Cómo utilizar la metodología Scrum para

acometer proyectos complejos
(24 votes, average: 4,54 out of 5)

Eduardo Martínez

¿Sabes qué es la metodología Scrum? La gestión de procesos y equipos es una de las partes más
complicadas para cualquier empresa. No se trata solo de recursos. La optimización del tiempo,
coordinación del equipo, definición de protocolos y la asignación de tareas es un asunto de peso, que
requiere de conocimiento, buen criterio y mucho tiempo para su implementación.
Índice de contenido:
• ¿Qué perfiles intervienen en la metodología Scrum?
• ¿Cómo funciona la metodología Scrum?
• ¿Cómo son las reuniones con la metodología Scrum?
• ¿Qué ganamos con la metodología Scrum?
¿A qué lleva la falta de planificación? Sobrecostes, retrasos en la entrega de proyectos, conflicto con
los clientes u otros departamentos. ¿Y el uso de procesos anticuados? La diferencia de criterios entre
los propios integrantes a la hora de realizar su trabajo, la falta de unificación de herramientas o la
disgregación de procesos de trabajo lleva a malgastar tiempo, dinero y, en último término, a la
desmotivación del equipo.
¿Lleva tiempo esta planificación e implementación de nuevas técnicas? Sí. ¿Compensan? Si
analizamos los costes indirectos de una mala gestión, no hay duda de que la respuesta es sí.
Como respuesta a esta problemática surgen las metodologías ágiles. Nuevos sistemas de gestión que
apuestan por una gestión dinamizada y muy coordinada de los procesos para llevar a un nivel óptimo el
uso que demos a nuestros recursos.
¿En qué consiste exactamente? La metodología Scrum permite abordar proyectos complejos
desarrollados en entornos dinámicos y cambiantes de un modo flexible. Está basada en entregas
parciales y regulares del producto final en base al valor que ofrecen a los clientes.
Es una opción de gestión ideal para acometer proyectos desarrollados en entornos complejos que
exigen rapidez en los resultados y en los que la flexibilidad es un requisito imprescindible. Scrum
ofrece agilidad y el, resultado, siempre, valor.

Perfiles de la metodología Scrum

Como decíamos, este método no sería posible sin el concepto de «equipo de trabajo».
Por una parte, tenemos al Product Owner representa la voz del cliente y del resto de interesados no
implicados directamente en el proyecto. Este perfil es el encargado de definir los objetivos del proyecto
y de garantizar que el equipo trabaja del modo adecuado para alcanzar dichos objetivos.
No está solo. El Scrum Master es el encargado de asegurar que el resto del equipo no tiene problemas
para abordar sus funciones y tareas. Guía y ayuda al Scrum Team para garantizar el cumplimiento de
objetivos. En otras palabras, este perfil ayuda al equipo a mantenerse activo y productivo.
El Scrum Team es el equipo encargado de desarrollar y entregar el producto. Su trabajo es
imprescindible: estamos hablando de una estructura horizontal auto-organizada capaz de auto-
gestionarse a sí misma.
Y, finalmente, tenemos que hablar de los Stakeholders. Este grupo comprende aquellos perfiles
interesados en el producto: directores, dueños, comerciales. Se trata de perfiles que si bien no forman
parte del Scrum Team deben ser tenidos en cuenta.

Funcionamiento de la metodología Scrum

El proceso comienza con la elaboración del llamado Product Backlog. Se trata de un archivo genérico
que recoge el conjunto de tareas, los requerimientos y las funcionalidades requeridas por el proyecto.
Cualquier miembro del equipo puede modificar este documento pero el único con autoridad para
agregar prioridades es el Product Owner, responsable del documento.
La segunda etapa pasa por la definición del Sprint Backlog, documento que recoge las tareas a
realizar y quién las desempeña. Es interesante asignar las horas de trabajo que va a suponer realizar
cada una de ellas y asignarlas un coste. Si su volumen es muy grande, crear metas intermedias será un
acierto.
El Sprint es el periodo en el que se realizan todas las acciones pactadas en el Sprint Backlog y supone
entregas parciales para ir testeando el producto final.
El ciclo anterior deberá repetirse hasta que todos los elementos del Blacklog hayan sido entregados.
Entre los distintos Sprints no se deben dejar tiempos sin productividad.
Todas las acciones que realicemos han de tener un control. Es en el Burn Down donde marcamos el
estado y la evolución del mismo indicando las tareas y requerimientos pendientes de ser tratados.

Las reuniones, concretas y trabajadas con anterioridad

¿Quién no ha perdido horas de trabajo inútiles en reuniones poco productivas porque estaban mal
preparadas? Esto no tiene cabida en los métodos ágiles. Cada minuto cuesta dinero. Las reuniones han
de estar también planificadas, como una parte más de proceso. En este «Sprint Planning Meeting» el
Product Owner prioriza las tareas contenidas en el Product Backlog.
Con estas tareas en mente se determina el objetivo del nuevo sprint priorizando las tareas a realizar por
el Scrum Team y asignando tiempo a cada una de ellas. El objetivo debe ser alcanzable y el equipo sólo
abordará un conjunto de tareas asumible.
Diariamente se hace un seguimiento del proyecto en esta reunión en la que se controla el cumplimiento
de las tareas asumidas. Quizás has oído hablar de la Daily Scrum, que es el nombre adoptado del
inglés. En dicha cita se pactan los objetivos para el día siguiente y se analizan los posibles problemas
que hayan limitado o impedido directamente el cumplimiento de los objetivos.

Beneficios de la metodología Scrum

Los beneficios son amplios y repercuten en el equipo, en los Stakeholders y en la organización en su
conjunto.
Se fomenta el trabajo en equipo, focalizando todos los esfuerzos en alcanzar un objetivo común. Se
trata de un modelo basado en la auto-disciplina y la auto-gestión, lo que repercute positivamente en la
responsabilidad. Respecto al aspecto comunicativo, esta metodología fomenta la comunicación entre
los distintos miembros del equipo.
Los Stakeholders tienen un mayor control y transparencia sobre el proyecto, permitiendo una mejor
organización. El cliente puede hacer seguimiento más cercano de lo que pasa, sin tener que esperar a un
resultado final que no le convenza. Con las metas intermedias se minimizan riesgos.
En definitiva, la adopción de estas buenas prácticas permite reducir el tiempo de desarrollo de
productos, más capacidad de adptación y flexibilidad frente a un entorno y unos requisitos
cambiantes aumentando el valor que se aporta a los clientes.
¿Qué te ha parecido este artículo? Si quieres formación en métodos ágiles para afrontar entornos
dinámicos y exigentes… ¡Pulsa el enlace!

Los 11 Pasos para Implementar metodología

SCRUM

Para que puedas tener una visión más global de Scrum y su implantación, aquí encontrarás un resumen
original de Jeff Shuterland (Creador de SCRUM) de lo que necesitas para poner en marcha un proyecto
Scrum.
Si no te apetece leer mucho puedes ver un video de nuestro curso sobre gestión de proyectos mediante
Scrum.
Es un descripción rápida de todo el proceso, pero te va a venir de maravilla para poder empezar con el
«cómo se hace en scrum». ¡Menos rollos y mas madera!

1. Elige un responsable de producto.

Esta persona es la que tiene la visión clara de lo que se necesita, se va a hacer, fabricar o conseguir.
tendrá en cuenta riesgos y compensaciones, qué es posible y qué es factible.
2. Elige un equipo.
¿Quién va a hacer el trabajo real? Este equipo necesita tener las habilidades necesarias para
convertir en realidad la visión del responsable de producto. Los equipos tienen que ser pequeños: entre
3 y 9 personas es lo normal.

3. Elige un Scrum Master.

Es la persona que conducirá a todos los demás por el sistema de trabajo Scrum ayudando al equipo a
eliminar todo aquello que les frene. Quitar desperdicios.

4. Elabora y prioriza una lista de objetivos o backlog.

El Backlog no es más que una lista de todo lo que debe hacerse para convertir la visión en realidad.
Esta lista existe y evoluciona a lo largo del proceso, es el mapa o la hoja de ruta del producto.
En cualquier momento del proyecto, la lista de objetivos pendientes es la única y definitiva vista
panorámica «de todo lo que el equipo podría hacer, por orden de prioridades». Existe una sola lista de
objetivos pendientes. Esto quiere decir que el responsable de producto tiene que tomar decisiones sobre
las prioridades del proceso.
Debería consultar con todos los interesados y con el equipo para asegurarse de que representan tanto lo
que quiere el cliente como lo que es factible construir.

5. Haz una estimación afinada de la lista de objetivos pendientes.

Es crucial que las personas que realmente van a llevar a cabo los ítems enumerados en la lista, calculen
el esfuerzo que les llevará cada uno. El equipo deberá ir ítem por ítem para decidir si realmente es
factible hacerlo.
¿Hay información suficiente para llevar a cabo cada uno? ¿Es lo suficientemente pequeño para poder
calcular? ¿Hay una definición de «hecho»? ¿Todo el mundo está de acuerdo en los requisitos que hay
que cumplir para considerar que una cosa está «hecha»? ¿Ofrece un valor visible?
Cada ítem tiene que poder presentarse, tiene que estar listo para, idealmente, poder ser puesto en
marcha. No hagas estimaciones de la lista de objetivos pendientes en horas, porque a las personas se
nos da fatal calcular el tiempo. Haz estimaciones sobre el tamaño: pequeño, mediano o grande. O
incluso mejor: utilizae la sucesión de Fibonacci y calcule el punto de valor de cada una de las entradas
de la lista: 1, 2, 3, 5, 8,13, 21, etc. Lo que se conoce como el Póker de Planificación.

6. Planificación de sprints.
Ésta es la primera reunión Scrum. El equipo, el Scrum Master y el responsable de producto se sientan a
planificar el sprint.
Los sprints siempre duran una cantidad determinada de tiempo, que es menos de un mes.
Habitualmente, casi todo el mundo hace sprints de una o dos semanas. El equipo mira el principio de la
lista de objetivos pendientes y hace una previsión de cuánto pueden tener terminado en este sprint. Si el
equipo ya ha hecho algún sprint, deberían tener en cuenta los puntos que hicieron en el último. Ese
número se conoce como la velocidad del equipo. El Scrum Master y el equipo deberían estar siempre
intentando aumentar esa cifra en cada sprint. También es el momento para que el equipo y el
responsable de producto se aseguren de que todo el mundo entiende exactamente cómo estos ítems van
a lograr crear la visión. Además, en esta reunión todos deben ponerse de acuerdo en la meta, lo que
todos quieren lograr en ese sprint.
Uno de los pilares del Scrum es que una vez que el equipo se ha comprometido con lo que creen que
pueden terminar en un sprint, no hay vuelta atrás. No se puede cambiar y no se le puede añadir nada. El
equipo tiene que ser capaz de trabajar de forma autónoma durante todo el sprint, para terminar lo
que previeron que podían hacer.

7. Haz que el trabajo sea visible.

La forma más habitual de hacer esto es con una pizarra de Scrum y sus tres columnas: Pendiente,
En proceso, Hecho. Los post-it representan los ítems que hay que completar y el equipo los cambia de
sitio en la pizarra, a medida que se van terminando, uno por uno.
Otra forma de hacer que el trabajo sea visible es crear un diagrama burn down o de trabajo pendiente.
En uno de los ejes está el número de puntos que el equipo ha llevado al sprint y en el otro el número de
días. Cada día el Scrum Master registra el número de puntos que se han completado y los anota en el
diagrama de trabajo pendiente. Lo ideal sería que hubiera una curva descendente que llegara a cero
puntos en el último día del sprint.

8 Scrum Diario. Reunión Diaria de pie.

Éste es el pulso vital del Scrum. Cada día a la misma hora, durante no más de quince minutos, el
equipo y el Scrum Master se ven y responden a tres preguntas:
¿Qué hiciste ayer para ayudar al equipo a terminar el sprint?
¿Qué vas a hacer mañana para ayudar al equipo a terminar el sprint?
¿Qué obstáculos se interponen en tu camino o el del equipo?
Ya está. En eso consiste la reunión. Si dura más de quince minutos usted está haciendo algo mal. Esto
ayuda al equipo a saber exactamente en qué punto está cada ítem del sprint.
¿Se van a terminar todas las tareas a tiempo? ¿Existe la posibilidad de ayudar a otros miembros del
equipo a superar obstáculos? Las tareas no se asignan desde arriba, el equipo es autónomo; son ellos los
que deciden. No hay que despachar detalladamente con los directivos. El Scrum Master es el
responsable de eliminar los obstáculos que impiden que el equipo avance.
¿Quieres certificarte cómo Scrum Master?

9 Revisión o demostración del sprint.

Ésta es la reunión en la que el equipo muestra lo que ha construido durante el sprint. Puede estar
presente cualquiera, no sólo el responsable de producto, el Scrum Master y el equipo, sino los
directivos de la empresa, los jefes, los clientes, todo el que quiera. Es una reunión abierta en la que el
equipo explica lo que han podido pasar a la columna de «hecho» durante el sprint.
El equipo debería mostrar únicamente lo que se ajuste perfectamente a la definición de «hecho».
Aquello que esté completamente terminado y que se puede entregar porque no necesita más trabajo.
Puede no ser un producto terminado, pero debería ser una característica del mismo, que está lista para
empezar a funcionar.

10 Retrospectiva del sprint.

Después de que un equipo haya mostrado lo que ha conseguido durante el último sprint se sientan a
reflexionar sobre lo que ha ido bien, lo que podría hacerse mejor y lo que se podría perfeccionar en el
siguiente sprint. ¿Qué mejora puede incorporar el equipo al proceso de forma inmediata?
No estamos buscando a quién echarle la culpa; estamos analizando el proceso. ¿Por qué eso fue así?
¿Por qué se nos escapó aquello? ¿Qué podría hacernos ser más rápidos? Es crucial que la gente asuma
la responsabilidad de su proceso y resultados y trate de encontrar soluciones como equipo. A su vez, las
personas tienen que tener la valentía de plantear los problemas con los que realmente se están
encontrando de una forma constructiva. Para solucionar y no a acusar. El resto del equipo debe tener la
madurez de escuchar esa opinión, tenerla en cuenta y buscar una solución, en lugar de ponerse a la
defensiva.
Al final de la reunión, el equipo y el Scrum Master deberían haberse puesto de acuerdo en una mejora
del proceso que incorporarán en el siguiente sprint. Ese proceso de mejora, que se conoce también
como kaizen, debería incluirse en la lista de objetivos pendientes del siguiente sprint, con tests de
aceptación. Así, será fácil para el equipo ver si realmente han implementado la mejora y qué efecto ha
tenido en la velocidad.

11 Empieza inmediatamente el siguiente ciclo de sprints.

Teniendo en cuenta la experiencia anterior del equipo con obstáculos y la incorporación de mejoras.

Pues ahí es nada, cientos de horas de reflexión concentradas en 11 puntos. Espero que sea de tu ayuda y
puedas implementar con éxito el SCRUM.
La metodología Scrum es un marco simple que facilita la colaboración en equipo en proyectos
complejos. Se trata de un enfoque de trabajo muy sencillo, aunque su implementación en la práctica no
suele serlo tanto.
Scrum enfatiza el trabajo en equipo, haciendo hincapié en la rendición de cuentas y la necesidad de
abordar las tareas en base a iteraciones.
La claridad de los objetivos es crucial para avanzar hacia una versión cada vez mejor y más
completa de los entregables. Scrum es parte del desarrollo de software ágil aunque, a día de hoy, se
trata de un método que muchas compañías de diferentes sectores han incluido como parte de su
estrategias
Scrum es reconocida por ser la metodología ágil más prestigiosa internacionalmente en el sector
empresarial. De ella sabemos la rápida aceptación que ha tenido desde su creación, en el año 1992,
cuando el teórico norteamericano Jeff Sutherland sentó las bases para su posterior desarrollo.

Durante muchos años Scrum ha liderado el denominado grupo agile, es decir, una categoría en la que
se agrupan las metodologías que surgieron en las últimas dos décadas como respuesta a los modelos
tradicionales de gestión.
También sabemos de sus excelentes resultados en distintas áreas empresariales, sobre todo cuando se
trata de gestionar proyectos demasiado complejos o que requieran la ejecución de actividades
simultáneas.

Contents [hide]
• 1 ¿Qué es Scrum?
• 2 ¿Cómo aplicar la metodología Scrum para proyectos?
• 3 Implementación de la metodología Scrum
• 4 Scrum: ventajas y desventajas del modelo
• 4.1 1) Usos y ventajas:
• 4.2 2) Limitaciones:

¿Qué es Scrum?
El marco de trabajo que propone Scrum es un método ágil en base al cual se proporcionan
descripciones completas y detalladas de cómo hacer que todo salga adelante dentro de un
proyecto. Se trata de decisiones consensuadas en las que participa todo el equipo, puesto que sus
integrantes son los que, por su experiencia y formación, mejor pueden conocer las diferentes formas de
resolver cualquier problema que se pueda presentar.
Scrum está relacionado con un equipo autoorganizado y multifuncional, donde destacan figuras
como el ScrumMaster, que es quien ayuda al equipo a lograr trabajar al máximo rendimiento, y el
propietario del producto, que es quien representa el negocio, los clientes o usuarios, y guía al equipo
hacia la construcción del producto correcto.

¿Cómo aplicar la metodología Scrum para proyectos?

Antes de aplicar la metodología Scrum a proyectos es preciso tener claro que, aunque no existe
ningún tipo de capacitación especial necesaria para comenzar, sí que hay que superar la limitación que
impone el lenguaje propio de esta metodología.
Para aplicar Scrum a un proyecto es preciso mantenerse fiel a las reglas de esta metodología y conocer
la jerga. Entre los puntos básicos destacan los siguientes:
• Scrum comienza con la designación de un propietario del producto. Esta es la persona que
representa el mejor interés del usuario final y tiene la autoridad para decir qué se incluye en el
producto final.
• El propietario del producto se encarga de realizar el backlog, una lista de tareas y requisitos que
el producto final necesita. Aquí hay una parte importante: el backlog debe ser prioritario y eso
es tarea del propietario del producto.
• Las prioridades se establecen en base a la funcionalidad. Lo más importante es que el
producto pueda ponerse en uso, mientras que cuestiones accesorias o relativas al diseño
ocuparían un segundo lugar.
• El Sprint, otro término clave en la jerga Scrum, es un marco de tiempo predeterminado
dentro del cual el equipo completa los conjuntos de tareas del Backlog. El tiempo depende
de las necesidades del equipo, pero suele fijarse en torno a las dos semanas.
• Los equipos se reúnen todos los días para proporcionar actualizaciones de progreso en el Daily
Scrum. Mucha gente también los llama “Daily Stand-Ups” o “Stand -up meetings”.
• Cada Sprint finaliza con una revisión, o retrospectiva, donde el equipo revisa su trabajo y
analiza formas de mejorar el próximo Sprint.

Implementación de la metodología Scrum

La implementación de la metodología Scrum puede completarse en 7 pasos:
Paso 1. Identificar al propietario de un producto que pueda asumir el rol de creación y facilitar la
creación de la acumulación de productos.
Paso 2. Crear el Backlog.
Paso 3. Calcular el tiempo aproximado para la creación del backlog del producto
Paso 4. Planificar los Sprint cuidadosamente, idealmente deberían ser de 30 días.
Paso 5. Decidir el presupuesto del Sprint, para tener una idea aproximada de la cantidad de horas
disponibles que el equipo tiene para trabajar.
Paso 6. Habilitar un espacio de colaboración para el equipo de Scrum.
Paso 7. Preparar un gráfico diario de burndown que permita rastrear el progreso diario.

¿Listo para probar un enfoque de trabajo ágil con la metodología Scrum?

 Créditos fotográficos: liubomirt

Scrum: ventajas y desventajas del modelo

No obstante, como cualquier propuesta de gestión presenta dos caras. Si bien se adapta a ciertas
circunstancias como los ambientes de crisis, el retraso en las entregas o las dificultades de coordinación
de tareas, también presenta vacíos o limitaciones. Pese a sus múltiples beneficios, no se trata de una
fórmula mágica.
¿Cuánto sabes de este método? ¿Podrías mencionar al menos tres beneficios de Scrum? ¿Y algunas
desventajas? No te preocupes, si no lo sabes aquí te ahorramos trabajo. Echa un vistazo a lo que viene a
continuación:

1) Usos y ventajas:
Scrum es una propuesta de gestión basada en la división del trabajo en iteraciones, es decir, fases con
objetivos y tareas específicas. Esto hace que necesariamente aporte beneficios en aspectos como los
siguientes:
• Gestión de las expectativas de los clientes. Los clientes pueden participar en cada una de las
iteraciones y proponer soluciones. De hecho, el proceso en su conjunto está pensado para un
tipo de evaluación conjunta.
• Resultados anticipados. Cada iteración arroja una serie de resultados. No es necesario, por
tanto, que el cliente espere hasta el final para ver el producto.
• Flexibilidad y adaptación a los contextos. Se adapta a cualquier contexto, área o sector de la
gestión. No es una técnica exclusiva de ninguna disciplina.
• Gestión sistemática de riesgos. Del mismo modo, los riesgos que pueden afectar a un proyecto
son gestionados en el mismo momento de su aparición. La intervención de los equipos de
trabajo es inmediata.

2) Limitaciones:
Pero ojo, antes de que te decidas por esta metodología de gestión, viene bien que mires las siguientes
limitaciones en cuanto a su implementación:
• Funciona sobre todo con equipos reducidos. Las empresas grandes, por ejemplo, deben estar
sectorizadas o divididas en grupos con objetivos concretos. De lo contrario, el efecto de la
técnica se perderá.
• Requiere una exhaustiva definición de las tareas y sus plazos. Cuando estos dos aspectos no
se definen adecuadamente, Scrum se desvanece. Recuerda que la división del trabajo en
iteraciones (y de éstas en tareas específicas) son la esencia de esta metodología.
• Exige una alta cualificación o formación. No es una modalidad de gestión propia de grupos
junior o que apenas estén en proceso de formación. Gran parte del éxito de Scrum radica en la
experiencia que aportan los profesionales de los equipos, quienes por lo general acumulan años
de experiencia.
¿Cuáles son las ventajas y desventajas de
agile/scrum?

3 respuestas

Sergio Herrera Arteaga, Project Manager en Banco Galicia (2017-presente)

Respondió 14 Mar. 2017 · El autor tiene 90 respuestas y 254,5k vistas de respuestas

Bueno esta Metodologías Ágil para proyectos tienen muchas ventajas y desventajas, primero que nada
no solo es para el desarrollo de software, sino también es aplicable a distintos proyectos de tecnología y
por que no, en otras áreas, ahora cito las principales conocidas y luego te doy un plus especial de mi
experiencia:
Ventajas:
 • Entregables en tiempo y forma, puedes ir enviando entregables al cliente mientras vas atacando
los objetivos mas sencillos, eso te hace ganar tiempo para atacar los objetivos mas complejos.
• el ScrumMaster tiene el conocimiento necesario para lograr el objetivo primario y secundario
por lo cual puede ir controlando el proyecto y delegando roles.
• Cada persona sabe que es lo que tiene que hacer y no es necesario estar reorganizando una y
otra vez los Tracks de cada persona.
• Se involucra desde un principio y se da un rol a todos los stakeholders (personas que van a
participar en el proyecto incluyendo cliente final, QA, Testers, etc.)
Desventajas
• Algunos miembros de tu equipo pueden saltar pasos importantes en el camino rápido para llegar
al “sprint” final.
• El cliente siempre va a esperar los informes con la fecha exacta, y muchas veces los va a pedir
antes, cuando capaz no pudiste avanzar en nada.
• Demasiadas Reuniones para poco avance, a veces es muy cansador y estresante reunirse
demasiadas veces por el mismo tema, algunos van perdiendo el interés en el proyecto.
• Si una persona renuncia o hay algún cambio es complicado remplazar ese rol ya que es la
persona que se lleva el conocimiento especifico y afecta a todo el proyecto.
• No es aplicable a grandes escalas o cuando el sector IT es variado.

Mi opinión personal y experiencia: Las metodologías son aplicables solo en cierta medida, es bueno
seguir las buenas practicas y tratar de planificar el mejor escenario, o ir combinándolas con otras
mas evolucionadas como es la Metodología RUP Agile, pero por más mejorada que este, siempre vas a
tener Stoppers y Semaforos Amarillos y Rojos, y es que no hay una receta del éxito especifica de un
proyecto, por que hay variables no controlables, sino mas bien lo veo como una herramienta que nos
sirve para ir mejorando el proceso del proyecto, aplicar metodologías(Ágiles, Espirales, Prototipadas,
etc.) en pequeños grupos controlables es lo ideal y lo que me ha dado resultados.
ratare de ser breve, Scrum tiene muchas ventajas y también desventajas
Ventajas
• Mejora la comunicación entre los integrantes del equipo de desarrollo y el resto de la compañia:
Esto es debido a promocion de pocas reuniones pero efectivas (time boxing)
• Evita el Context Change: El equipo de desarrollo toma la decision en que va a trabajar durante
el Sprint sin interrupciones por parte de factores externos.
• Promueve la agilidad: Si un requerimiento esta ambiguo o muy grande, éste se rechaza ya que
no cumple con la definicion de listo (Definition of Ready) . En su lugar se entrega lo que es
posible durante un Sprint y el cliente puede familiarizarse.
• Reduce el Riesgo: Se entrega el resultado del sprint y el Product Owner puede rapidamente ver
el resultado, si éste no es suficiente se puede tomar alguna acción (Fail Fast)
Desventajas
 • Desarrolladores que se esconden: Debido a que es el equipo de desarrollo el responsable, puede
darse que desarrolladores con poca experiencia o mala actitud (funciona en mi PC, no es mi
problema), se escondan detras y no aporten nada al proyecto.
• Poca importancia a las técnicas ágiles: Scrum no dice nada acerca de tecnicas agiles como por
ejemplo: Unit Testing, CI, Code Review, Funtional Testing, etc. Entonces el equipo tiende a no
trabajar en actividades no directamente relacionadas - ya que estos esfuerzos no tienen
visibilidad con la administración -
Mi opinión personal es que antes de una iniciativa Scrum en la compañia deberá previamente trabajarse
en actividades de integración de equipos. Promover un ambiente para Geeks.
Obviamente en unas industria como la banca, seguros y gobierno donde dar la impresión de mantener
las cosas bajo control es mas importante que la calidad del producto final, no es buena idea utilizar
Scrum ya que las personas tienden a simplemente decir que hacen Scrum solo para complacer a la
administración y a la larga les quita tiempo valioso. En un Startup por otro lado, yo utilizaria KanBan
ya que es menos estricto que Scrum

Metodologia scrum ventajas y desventajas al

crear software
Piero Ramos agosto 31, 2017
Los proyectos desarrollados por equipos de trabajo pueden ser una maravilla o una pesadilla
dependiendo del tipo de gestión que se emplee. Para el desarrollo de proyectos de software y tecnología
una de las mejores metodologías es la conocida como “Scrum”, por ello hoy hablaremos sobre la
metodologia scrum ventajas y desventajas de su aplicación.
Se incluye dentro de la corriente llamada “Gestión de Proyectos Agiles”, en donde es definida como un
proceso que regula las practicas colaborativas entre equipos que deben obtener resultados rápidos y
constantes sobre determinado proyecto; la urgencia de resultados es lo que caracteriza el empleo de este
método.
El Scrum en el desarrollo de software
En el software especialmente se trabaja con iteraciones, entregables que no son más que funciones
determinadas del software que deben estar listas en un periodo de tiempo determinado.
Así, cada iteración debe ir añadiendo funciones y arreglando fallas. Las funciones más urgentes son las
primeras en crearse y luego se van agregando gerarquicamente.
Todos los proyectos tienen una cabeza, la metodología Scrum establece que este sujeto es el Scrum
Master. Las caracteristicas de Scrum Master lo hacen ser el facilitador del proyecto, dictamina las
reglas y guía la compenetración dentro de los equipos y entre equipos.
En los equipos de desarrollo de software puede o no ser él quien se encarga de guiar la colaboración
con el cliente, para desarrollar el software según sus exigencias.

Ventajas
• Reduce la aparición de riesgos: Al ser dividido e entregables, los errores y los cambios se hacen
en diferentes etapas del proyecto.
• El producto se lanza al mercado con mayor rapidez: Quizás no el producto completo, pero si las
características más importantes.
• Máxima productividad: Roles definidos acorta los tiempos al máximo.
Desventajas
• Puntualidad: Como en todas las metodologias de proyectos agiles, el ofrecer puntualidad es un
arma de doble filo.
• Susceptibilidad a la ausencia de un miembro: Si cualquier persona de cualquier equipo falta o
falla, todo el trabajo se atrasa.
• Limitado por tamaño: Es recomendado aplicarlo solo en equipos pequeños y medianos y con
proyectos de tamaño moderado.
En definitiva, la metodologia Scrum debe ser conocida por todos los equipos de desarrollo de software
que quiere tener éxito en proyectos con entregas a corto plazo.