Close

Qué es scrum y cómo empezar

Guía de scrum: qué es, cómo funciona y cómo empezar

Buscar temas
Flecha de metodología ágil

Empieza gratis con la plantilla de scrum de Jira

Optimiza tu proyecto y planifica, supervisa y gestiona fácilmente el trabajo de los sprints. La plantilla de scrum de Jira incluye tableros, backlogs, hojas de ruta, informes y mucho más.

Usar plantilla

¿Qué es scrum?

Scrum es un marco de gestión de proyectos de metodología ágil que ayuda a los equipos a estructurar y gestionar el trabajo mediante un conjunto de valores, principios y prácticas. Al igual que un equipo de rugby (de donde proviene su nombre) cuando entrena para un gran partido, el método scrum anima a los equipos a aprender a través de las experiencias, a autoorganizarse mientras abordan un problema y a reflexionar sobre sus victorias y derrotas para mejorar continuamente.

Aunque son los equipos de desarrollo de software los que utilizan con mayor frecuencia el scrum del que estoy hablando, sus principios y lecciones se pueden aplicar a todo tipo de trabajo en equipo. Esta es una de las razones por las que es tan popular. Aunque se considera a menudo un marco de trabajo de gestión de proyectos ágil, scrum describe un conjunto de reuniones, herramientas y funciones que trabajan de forma coordinada para ayudar a los equipos a estructurar y gestionar su trabajo.

En este artículo, analizaremos cómo se compone un marco de trabajo tradicional de scrum con la ayuda de la guía de scrum y David West, director ejecutivo de Scrum.org. También incluiremos ejemplos de cómo nuestros clientes se desvían de estos principios para satisfacer sus necesidades específicas. Para ello, nuestra propia Megan Cook, responsable de producto para Jira y anteriormente orientadora ágil, proporcionará consejos y trucos en la serie de vídeos de orientador ágil:

Artículos sobre scrum

[CONTINUACIÓN]

Metodología ágil frente a scrum

Se suele pensar que scrum y la metodología ágil son lo mismo porque scrum se centra en la mejora continua, que es un principio básico de la metodología ágil. Sin embargo, scrum es un marco para realizar el trabajo, mientras que la metodología ágil es una mentalidad. La mentalidad ágil se centra en la mejora gradual continua mediante publicaciones pequeñas y frecuentes. En realidad, uno solo no puede "adoptar una metodología ágil", ya que requiere la dedicación de todo el equipo para cambiar la forma de pensar a la hora de ofrecer valor a los clientes. Lo que sí que se puede usar es un marco como scrum para ayudar al equipo a empezar a pensar de esa manera y poner en práctica la aplicación de principios de metodología ágil en la comunicación y el trabajo diarios.

La diferencia entre la metodología ágil y la definición de scrum se encuentra en la Guía de la metodología scrum y en el Manifiesto ágil. El Manifiesto ágil describe cuatro valores:

  • Las personas y las interacciones por encima de los procesos y las herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente por encima de negociación de contratos
  • Dar respuesta a un cambio por encima del seguimiento de un plan

La definición de scrum se basa en el empirismo y el pensamiento lean. Según el empirismo, el conocimiento proviene de la experiencia y las decisiones se toman en función de lo que se observa. El pensamiento lean reduce el despilfarro y se centra en lo esencial. El marco de trabajo de scrum es heurístico. Se basa en el aprendizaje continuo y en la adaptación a los factores fluctuantes. Reconoce que el equipo no lo sabe todo al inicio de un proyecto y evolucionará a través de la experiencia. Scrum está estructurado para ayudar a los equipos a adaptarse de forma natural a las condiciones cambiantes y a los requisitos de los usuarios, con el cambio de prioridades integrado en el proceso y ciclos de publicación breves para que tu equipo pueda aprender y mejorar constantemente.

Un diagrama del marco de scrum

Aunque scrum está estructurado, no es del todo rígido. Su ejecución se puede adaptar a las necesidades de cualquier organización. Existen muchas teorías acerca de cómo deben trabajar los equipos de scrum exactamente para tener éxito. Sin embargo, después de más de una década ayudando a los equipos ágiles a realizar el trabajo en Atlassian, hemos aprendido que la comunicación clara, la transparencia y la dedicación a la mejora continua siempre deben ser el núcleo del marco de trabajo que elijas. Y el resto depende de ti.

El marco de scrum

El marco de scrum está formado por un conjunto de valores, principios y prácticas que los equipos de scrum siguen para desarrollar un producto o servicio. Detalla los miembros de un equipo de scrum y sus responsabilidades, los "artefactos" que definen el producto y el trabajo que hay que hacer para crear el producto, así como las ceremonias de scrum que guían al equipo de scrum en su trabajo.

Miembros de un equipo de scrum

Un equipo de scrum es un equipo pequeño y ágil que se dedica a ofrecer incrementos de productos de forma comprometida. El tamaño de un equipo de scrum suele ser reducido, de unas 10 personas, pero es lo suficientemente grande como para llevar a cabo una cantidad considerable de trabajo en un sprint. El equipo de scrum debe componerse de tres roles específicos: el propietario del producto, el experto en scrum y el equipo de desarrollo. Y, puesto que los equipos de scrum son interdisciplinares, el equipo de desarrollo está formado por evaluadores, diseñadores, especialistas en experiencia de usuario e ingenieros de operaciones, además de desarrolladores.

El propietario del producto de scrum

Los propietarios de producto son quienes más conocen el producto. Están centrados en entender los requisitos empresariales, de los clientes y del mercado, para luego priorizar el trabajo que el equipo de ingeniería debe realizar para cumplirlos. Los propietarios de producto eficaces:

  • Crean y gestionan el backlog del producto
  • Se asocian estrechamente con el negocio y el equipo para asegurarse de que todo el mundo entiende los elementos de trabajo en el backlog del producto.
  • Aportan al equipo directrices claras sobre qué funcionalidades entregar a continuación.
  • Deciden cuándo lanzar el producto con predisposición hacia una entrega más frecuente

El propietario del producto no siempre es el gestor de productos. Los propietarios del producto se centran en asegurarse de que el equipo de desarrollo entrega el mayor valor a la empresa. Asimismo, es importante que el propietario del producto sea una única persona. Ningún equipo de desarrollo desea directrices cruzadas de varios propietarios del producto.

El experto en scrum

Los expertos en scrum son los principales especialistas de scrum dentro de sus equipos. Proporcionan formación sobre el proceso de scrum a los equipos, a los propietarios de producto y a la empresa, y buscan formas de perfeccionar esta práctica.

Un experto en scrum eficaz conoce profundamente el trabajo que realiza el equipo y puede ayudarlo a optimizar su transparencia y flujo de entrega. Como conseguidor principal, planifican los recursos necesarios (tanto humanos como logísticos) para organizar los plazos de los sprints, las reuniones rápidas, la revisión de sprints y las retrospectivas de sprints.

El equipo de desarrollo de scrum

Los equipos de scrum sacan el trabajo adelante. Son los que mejor conocen las prácticas de desarrollo sostenible. Los equipos de scrum más eficaces tienen una relación estrecha, se encuentran en la misma ubicación y están compuestos por entre cinco y siete miembros. Una forma de calcular el tamaño del equipo es usar la famosa "regla de las dos pizzas" de Jeff Bezos, el director ejecutivo de Amazon (el equipo debe ser lo suficientemente pequeño como para compartir dos pizzas).

Los miembros del equipo tienen habilidades diversas y se forman entre sí para que nadie se convierta en un cuello de botella en la entrega de trabajo. Los equipos de scrum sólidos se autoorganizan y enfocan sus proyectos con una clara visión colectiva. Todos los miembros del equipo se ayudan entre sí para finalizar los sprints con éxito.

El equipo de scrum impulsa el plan de cada sprint. Prevén cuánto trabajo creen que pueden finalizar a lo largo de la iteración en función de su historial de velocidad. Mantener una longitud fija de la iteración aporta al equipo de desarrollo feedback sobre su estimación y proceso de entrega, lo cual a su vez consigue que las previsiones sean cada vez más precisas.

Artefactos de scrum

Los artefactos de scrum ofrecen información importante que el equipo de scrum utiliza para definir el producto y el trabajo que hay que hacer para crearlo. Existen tres artefactos en scrum: un backlog del producto, un backlog de sprint y un incremento en tu definición de "finalizado". Son las tres constantes sobre las que un equipo de scrum debe reflexionar durante los sprints y a lo largo del tiempo.

  • Backlog del producto: es la lista principal del trabajo que debe realizar el propietario o el responsable del producto. Se trata de una lista dinámica de funciones, requisitos, mejoras y correcciones que actúa como la base del backlog de sprint. Básicamente, se trata de la lista de "tareas que hay que hacer" del equipo. El propietario del producto está constantemente revisando, cambiando las prioridades y realizando el mantenimiento del backlog del producto, ya que, a medida que sabemos más o que cambia el mercado, es posible que haya elementos que ya no sean relevantes o que los problemas se solucionen de otras maneras.
  • Backlog de sprint: se trata de la lista de elementos, historias de usuario o correcciones de errores, seleccionadas por el equipo de desarrollo, para su implementación en el ciclo actual de sprint. Antes de cada sprint, en la reunión de planificación de sprint (que analizaremos más adelante en el artículo), el equipo elige los elementos en los que trabajará para el sprint del backlog del producto. El backlog de sprint puede ser flexible y puede evolucionar durante un sprint. No obstante, no se puede poner en peligro el objetivo fundamental del sprint, lo que el equipo quiere lograr con el sprint actual.
  • Incremento (u objetivo del sprint) es el producto final utilizable de un sprint. En Atlassian, solemos demostrar el "incremento" durante la demostración de fin de sprint, donde el equipo muestra lo que se ha completado en el sprint. Es posible que no escuche la palabra "incremento" en ningún sitio, ya que a menudo se la conoce como la definición del equipo de "Finalizado", un hito, el objetivo del sprint o incluso una versión completa o un epic lanzado. Solo depende de la definición de "Finalizado" de tus equipos y de cómo defines tus objetivos del sprint. Por ejemplo, algunos equipos eligen lanzar algo a sus clientes al final de cada sprint. Por tanto, su definición de "finalizado" se correspondería con "lanzado". Sin embargo, es posible que esto no sea realista en otros tipos de equipos. Supongamos que trabajas en un producto basado en servidor que solo se puede lanzar a los clientes cada trimestre. Podrías elegir trabajar en sprints de 2 semanas, pero tu definición de "finalizado" podría corresponderse con la finalización de parte de una versión más grande que planeas lanzar toda junta. Por supuesto, cuanto más se demore el lanzamiento del software, mayor será el riesgo de que el software no cumpla lo que se espera de él.

Como puedes ver, hay muchas variaciones, incluso dentro de los artefactos, que tu equipo puede elegir definir. Por eso es importante estar abierto a la evolución en la forma de mantenimiento, incluso de los artefactos. Tal vez tu definición de "finalizado" hace que tu equipo tenga que deshacer tareas, y necesitas revisarla y elegir una nueva definición.

Consejo de experto

Debes ser tan ágil con tu marco de trabajo como lo eres con tu producto. Tómate el tiempo que necesites para comprobar cómo van las cosas, hacer los ajustes necesarios y no fuerces las cosas simplemente por razones de uniformidad.

Protocolos o eventos de scrum

El marco de scrum incluye las prácticas, los protocolos y las reuniones de scrum que los equipos de scrum celebran de forma regular. En los protocolos ágiles es donde observamos la mayoría de las variaciones para los equipos. Por ejemplo, algunos equipos consideran que realizar todos estos protocolos es engorroso y repetitivo, mientras que otros los utilizan como una sesión de control necesaria. Nuestro consejo es empezar usando todos los protocolos para dos sprints y ver cómo va. Después, puedes realizar una retrospectiva rápida y ver en qué puntos es necesario realizar ajustes.

A continuación, se muestra una lista de todas los protocolos clave en los que un equipo de scrum puede participar:

  1. Organización del backlog: este evento, que a veces se conoce como limpieza del backlog, es responsabilidad del propietario del producto. Los principales trabajos del propietario del producto son dirigir el producto hacia su visión del producto y estar al tanto del mercado y los clientes. Por tanto, él o ella realiza el mantenimiento de esta lista utilizando los comentarios de los usuarios y del equipo de desarrollo para ayudar a priorizar y mantener la lista limpia y a punto para trabajar sobre ella en cualquier momento. Puedes obtener más información sobre cómo mantener un backlog de la forma más adecuada aquí.

  2. Planificación de sprint: en esta reunión, todo el equipo de desarrollo planifica el trabajo que se va a realizar (alcance) durante el sprint actual. Esta reunión la dirige el experto o la experta en scrum y, en ella, el equipo decide el objetivo del sprint. Posteriormente, se añaden historias de usuario específicas al sprint desde el backlog del producto. Estas historias siempre se adecuan al objetivo y también son acordadas por el equipo de scrum para que sea factible implementarlas durante el sprint.

    Al final de la reunión de planificación, cada miembro del equipo de scrum debe tener claro qué se puede entregar en el sprint y cómo se puede entregar el incremento.

  3. Sprint: un sprint es el periodo real en que el equipo de scrum trabaja de forma conjunta para finalizar un incremento. La duración de un sprint suele ser de dos semanas, aunque algunos equipos manifiestan que les resulta más fácil una semana para el alcance o un mes para entregar un incremento valioso. Dave West, de Scrum.org, advierte de que cuanto más complejo sea el trabajo y más incógnitas haya, más corto debería ser el sprint. Pero realmente esto depende de tu equipo, y no debes tener miedo de cambiarlo si no funciona. Durante este periodo, el propietario del producto y el equipo de desarrollo podrán renegociar el alcance, en caso de que sea necesario. Aquí está el quid de la naturaleza empírica del scrum.

    Todos los eventos (desde la planificación hasta la retrospectiva) tienen lugar durante el sprint. Una vez que se establece un determinado intervalo de tiempo para un sprint, debe seguir siendo coherente durante todo el periodo de desarrollo. Esto ayuda al equipo a aprender de las experiencias pasadas y a aplicar ese conocimiento a futuros sprints.

  4. Scrum diario o reunión rápida: se trata de una reunión diaria de muy corta duración que tiene lugar siempre a la misma hora (normalmente, por las mañanas) y en el mismo sitio para simplificarla. Muchos equipos tratan de finalizar la reunión en 15 minutos, pero eso es solo una guía. Esta reunión también se denomina "reunión rápida diaria" y con ello se hace hincapié en que debe ser rápida. El objetivo del scrum diario es que todos los miembros del equipo estén en sintonía, se coordinen en torno al objetivo del sprint y cuenten con un plan para las próximas 24 horas.

    La reunión rápida es el momento de expresar cualquier inquietud que se tenga acerca del cumplimiento del objetivo del sprint o de notificar los impedimentos que se detecten.

    Una forma habitual de realizar la reunión rápida es que cada miembro del equipo responda tres preguntas en el contexto de alcanzar el objetivo del sprint:

    • ¿Qué hice ayer?
    • ¿Qué tengo planeado para hoy?
    • ¿Hay algún obstáculo?

    Sin embargo, hemos observado que esta reunión puede convertirse rápidamente en un momento donde los empleados leen sus agendas del día anterior y del día siguiente. La teoría detrás de la reunión diaria es que las conversaciones que pueden suponer una distracción tengan lugar en la reunión diaria, para que el equipo pueda concentrarse en el trabajo durante el resto del día. Entonces, si se convierte en una lectura en voz alta de la agenda diaria, no tengas miedo de cambiarla y dar rienda suelta a la creatividad.

  5. Revisión de sprint: al final del sprint, el equipo se reúne en una sesión informal para ver una demostración o inspeccionar el incremento. El equipo de desarrollo muestra los elementos del backlog que ahora están "finalizados" a las partes interesadas y a los compañeros de equipo para recibir comentarios. El propietario del producto puede decidir si publica o no el incremento, aunque en la mayoría de los casos el incremento se publica.

    Esta reunión de revisión también se produce cuando el propietario del producto repasa el backlog del producto basado en el sprint actual, que se puede utilizar en la próxima sesión de planificación de sprint. Para un sprint de un mes, pon el límite de tu revisión de sprint en un máximo de cuatro horas.

  6. Retrospectiva de sprint: la retrospectiva es donde el equipo se reúne para documentar y analizar qué ha funcionado y qué no ha funcionado en un sprint, un proyecto, en las personas o relaciones, herramientas o incluso para determinados protocolos. La idea es crear un lugar donde el equipo pueda centrarse primordialmente en lo que salió bien y en lo que debe mejorarse para la próxima vez, y menos en lo que salió mal.

Flecha de metodología ágil

Empieza gratis con la plantilla de scrum de Jira

Optimiza tu proyecto y planifica, supervisa y gestiona fácilmente el trabajo de los sprints. La plantilla de scrum de Jira incluye tableros, backlogs, hojas de ruta, informes y mucho más.

Valores de scrum

En 2016, se añadieron cinco valores de scrum a la Guía de la metodología scrum. Estos valores se enfocan en el trabajo, las acciones y la conducta del equipo de scrum. Se consideran esenciales para el éxito de los equipos de scrum.

Compromiso

Puesto que los equipos de scrum son pequeños y ágiles, todos los miembros del equipo desempeñan un papel importante en el éxito del equipo. Por lo tanto, cada miembro del equipo debe comprometerse a realizar las tareas que pueda completar y no a más. Debe haber una comunicación continua en relación con el progreso del trabajo, a menudo a través de reuniones rápidas.

Valor

El valor de un equipo de scrum es simplemente atreverse a cuestionar el statu quo o todo aquello que le impida alcanzar sus objetivos. Los miembros del equipo de scrum deben tener el valor de probar cosas nuevas y sentirse lo suficientemente cómodos haciéndolo. Un equipo de scrum debe tener valor y sentir seguridad a la hora ser transparente en relación con los obstáculos, el progreso del proyecto, los retrasos, etc.

Foco

En el centro del flujo de trabajo de los equipos de scrum se encuentra el sprint, un período de tiempo específico y enfocado en el que el equipo completa una cantidad determinada de trabajo. El sprint proporciona una estructura, pero también ayuda a completar la cantidad de trabajo planificada.

Honestidad

Las reuniones rápidas diarias promueven la transparencia que permite a los equipos hablar abiertamente sobre el trabajo en curso y los impedimentos. En Atlassian, solemos animar a nuestros equipos de scrum a que aborden estas cuestiones:

  • ¿En qué estuve trabajando ayer?
  • ¿En qué estoy trabajando hoy?
  • ¿Qué problemas me están bloqueando?

Esto ayuda a visibilizar el progreso e identificar los impedimentos. También ayuda a fortalecer al equipo cuando todos comparten el progreso.

Respeto

La fortaleza de un equipo ágil reside en su colaboración y en el reconocimiento de que cada miembro del equipo contribuye al trabajo con un sprint. Celebran los logros de los demás y se respetan unos a otros y respetan al propietario del producto, a las partes interesadas y al experto en scrum.

Scrum, kanban y la metodología ágil

Scrum es un marco de trabajo de metodología ágil tan popular que a menudo se confunde scrum y ágil, y se piensa que es lo mismo. También existen otros marcos de trabajo, como kanban, que es una alternativa popular. Algunas empresas incluso optan por seguir un modelo híbrido de scrum y kanban, que ha adquirido el nombre de "Scrumban o "Kanplan", que es kanban con un backlog.

Tanto scrum como kanban utilizan métodos visuales como el tablero de scrum o el tablero de kanban para realizar un seguimiento del progreso del trabajo. Ambos enfatizan la eficiencia y dividen las tareas complejas en bloques más pequeños de trabajo manejable, aunque sus enfoques hacia la consecución del objetivo son diferentes.

Scrum se centra en iteraciones más pequeñas y de longitud fija. Una vez finalizado el periodo para un sprint, se determinan las historias o las entradas de backlog del producto que se pueden implementar durante este ciclo de sprint. Sin embargo, en kanban, la cantidad de tareas o el trabajo en curso (límite de WIP) que se implementará en el ciclo actual se fija al principio. El tiempo necesario para implementar estas funciones se calcula al revés.

Kanban no cuenta con un marco de trabajo tan estructurado como scrum. Aparte del límite de trabajo en curso, está bastante abierto a la interpretación. Scrum, sin embargo, tiene varios conceptos categóricos aplicados como parte de su implementación, como la revisión de sprint, retrospectiva, scrum diario, etc. También insiste en la interdisciplinariedad, que es la capacidad de un equipo de scrum de no depender de miembros externos para lograr sus objetivos. Reunir a un equipo interdisciplinar no es tarea fácil. En ese sentido, el método kanban es más fácil de adaptar, mientras que el scrum puede considerarse como un cambio fundamental en el proceso de pensamiento y el funcionamiento de un equipo de desarrollo.

Empezar con scrum

El marco de trabajo de scrum es sencillo en sí mismo. Las reglas, artefactos, eventos y funciones son fáciles de entender. Su enfoque semiprescriptivo en realidad ayuda a eliminar las ambigüedades en el proceso de desarrollo, a la vez que ofrece suficiente espacio para que las empresas introduzcan su toque personal.

La organización de tareas complejas en historias de usuario manejables hace que sea ideal para proyectos difíciles. Además, la clara demarcación de funciones y los eventos planificados aseguran que haya transparencia y propiedad colectiva en todo el ciclo de desarrollo. Los lanzamientos rápidos mantienen al equipo motivado y contentos a los usuarios, ya que pueden ver el progreso en un corto periodo.

No obstante, conocer bien cómo funciona scrum puede llevar su tiempo, especialmente si el equipo de desarrollo está acostumbrado a un modelo en cascada típico. Los conceptos de iteraciones más pequeñas, reuniones de scrum diarias, revisiones de sprint e identificación de un experto en scrum podrían suponer un cambio cultural difícil para un equipo nuevo.

Pero, los beneficios a largo plazo superan con creces la curva de aprendizaje inicial. El éxito de scrum en el desarrollo de productos de software y hardware complejos en distintos sectores y mercados verticales lo convierte en un marco de trabajo convincente para adoptarlo en tu organización.

Para aprender scrum con Jira, consulta este tutorial.

Related resources

Claire Drumond
Claire Drumond

Claire Drumond es estratega de marketing, oradora y redactora de Atlassian. Es autora de numerosos artículos publicados en los blogs de Trello y Atlassian, y es colaboradora habitual de varias publicaciones en Medium, como HackerNoon, Art + Marketing y PoetsUnlimited. Habla en conferencias tecnológicas en todo el mundo sobre la metodología ágil, en las que trata de desmontar la estructura tradicional y crear empatía.

Flecha de metodología ágil

Empieza gratis con la plantilla de scrum de Jira

Optimiza tu proyecto y planifica, supervisa y gestiona fácilmente el trabajo de los sprints. La plantilla de scrum de Jira incluye tableros, backlogs, hojas de ruta, informes y mucho más.

Usar plantilla
A continuación
Sprints