Scrum

Aprende a utilizar scrum de la mejor forma

Buscar temas

¿Qué es scrum?

Scrum es un marco de trabajo que permite el trabajo colaborativo entre equipos. Al igual que un equipo de rugby (de donde proviene su nombre) cuando entrena para el gran partido, scrum anima a los equipos a aprender mediante las experiencias, a organizarse de forma autónoma mientras se trabaja en 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 ágiles, scrum hace referencia a 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 de 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, gestora de productos de grupo para Jira Software y, anteriormente, orientadora ágil, proporcionará consejos y trucos en la serie de vídeos del orientador ágil:

Artículos sobre scrum

[CONTINUACIÓN]

El marco de trabajo

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. 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í puedes usar es un marco de trabajo como scrum para ayudar a tu equipo a empezar a pensar de esa manera y poner en práctica la construcción de principios de metodología ágil en tu comunicación y trabajo diarios.

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.

El marco de trabajo de scrum | Orientador ágil de Atlassian

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.

Artefactos de scrum

Empecemos identificando los tres artefactos en scrum. Cuando hablamos de "artefactos" nos referimos a algo que fabricamos, por ejemplo, una herramienta para solucionar un problema. En scrum, estos tres artefactos son un backlog del producto, un backlog de sprint y un incremento con tu definición de "finalizado". Estas son las tres constantes en un equipo de scrum que seguimos revisando y en las que continuamos invirtiendo horas extra.

  • El backlog del producto es la lista de trabajo maestra que se tiene que realizar y que debe mantener el propietario del producto o el gestor del producto. Es una lista dinámica de funciones, requisitos, mejoras y correcciones que actúa como entrada para el backlog del sprint. Se trata, básicamente, de la lista de tareas del equipo. El propietario del producto revisa, vuelve a priorizar y realiza el mantenimiento del backlog del producto constantemente porque, conforme más aprendemos o cambia el mercado, los elementos pueden dejar de ser relevantes o los problemas se pueden resolver de forma distinta.
  • El backlog del sprint es la lista de elementos, historias de usuario o resolución de errores seleccionados por el equipo de desarrollo para implementarlos en el ciclo de sprint actual. Antes de cada sprint, en la reunión de planificación del sprint (de la que hablaremos más adelante en este artículo), el equipo elige en qué elementos del backlog del producto va a trabajar durante el sprint. Un backlog de sprint puede ser flexible y puede evolucionar a lo largo del sprint. No obstante, no se puede poner en peligro el objetivo fundamental del sprint, es decir, lo que el equipo quiere lograr con el sprint actual.
  • El incremento (u objetivo del sprint) es el producto final que se puede usar y que se obtiene de un sprint. En Atlassian, solemos mostrar el incremento en la demo del fin del sprint, en la que el equipo muestra lo que se ha completado durante el sprint. Puede que no escuches la palabra "incremento" muy a menudo, ya que se utilizan otros términos para referirse a él, como la definición del equipo de "terminado": un hito, objetivo del sprint o incluso versión completa o epic lanzado. Depende de la definición de "terminado" de tu equipo y de cómo estableces tus objetivos de sprint. Por ejemplo, algunos equipos eligen publicar cosas para los clientes al final de cada sprint. Su definición de "terminado" coincidiría con "lanzado". No obstante, esta definición puede no ser la adecuada para otros tipos de equipos. Imagina que trabajas en un producto basado en servidor que solo se puede lanzar a los clientes una vez por trimestre. Puedes elegir que la duración de tus sprints sea de dos semanas, pero tu definición de "terminado" se referirá a completar parte de una versión más amplia que lanzarás en conjunto. Por supuesto, cuanto más se tarde en publicar software, mayor es el riesgo de que no esté a la altura.

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 va todo y hacer los ajustes necesarios, y no fuerces las cosas simplemente por razones de uniformidad.

Protocolos o eventos de scrum

Algunos de los componentes más conocidos del marco de trabajo de scrum son el conjunto de eventos secuenciales, protocolos o reuniones que los equipos de scrum realizan de forma periódica. En los protocolos 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 un registro necesario. 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, encontramos una lista con todos los protocolos clave en los que puede participar un equipo de scrum:

  1. Organizar el backlog: en ocasiones denominado "limpieza del backlog". Esta acción es responsabilidad del propietario del producto. Las tareas principales del propietario del producto consisten en orientar el producto hacia la visión de él que tiene y estar pendiente del mercado y los clientes de forma constante. Por ello, esta persona realiza el mantenimiento de la lista mediante comentarios de los usuarios y del equipo de desarrollo, de forma que pueda priorizar las tareas y organizar la lista para que se pueda trabajar en ella en cualquier momento. Puedes obtener más información sobre cómo mantener un backlog de forma adecuada aquí.

  2. Planificación de sprints: el trabajo que se va a realizar (alcance) durante el sprint actual se planifica en esta reunión, en la que participa el equipo de desarrollo completo. El experto en scrum dirige la reunión, en la que el equipo decide el objetivo del sprint. A continuación, se añaden historias de uso específicas del backlog del producto al sprint. Estas historias siempre se adaptan al objetivo y las acuerda el equipo de scrum, de forma que sea factible implementarlas durante el sprint.

    Al final de la reunión de planificación, todos los miembros de scrum deben aclarar qué se puede entregar en el sprint y cómo se va a entregar el incremento.

  3. Sprint: un sprint es el periodo real en el que el equipo de scrum trabaja en conjunto para finalizar un incremento. La duración de un sprint suele ser de dos semanas, aunque algunos equipos consideran que una semana es un periodo más sencillo para establecer el alcance o que un mes funciona mejor para entregar un incremento valioso. Dave West, de Scrum.org, advierte que cuanto más complicado y desconocido sea el trabajo, más cortos deben ser los sprints. No obstante, la decisión la tiene el equipo, y no debe daros miedo cambiarla si no funciona. En este periodo, se puede renegociar el alcance entre el propietario del producto y el equipo de desarrollo, si fuese necesario. Esta es la clave de la naturaleza empírica de la metodología scrum.

    Todos los eventos, desde la planificación hasta la retrospectiva, se desarrollan en el sprint. Una vez que se fija un intervalo de tiempo para un sprint, debe mantener la uniformidad durante el periodo de desarrollo. Esto ayuda a que el equipo aprenda de experiencias anteriores y aplique esa información a los sprints futuros.

  4. Scrum diario o reuniones rápidas: es una reunión diaria muy breve, siempre a la misma hora (normalmente por la mañana) y en el mismo sitio. Muchos equipos intentan que su reunión no dure más de 15 minutos, pero es solo una recomendación. Esta reunión también puede llamarse "reunión diaria rápida", un nombre que enfatiza en el hecho de que debe ser rápida. El objetivo del scrum diario es que todo el equipo esté en sintonía, que estén centrados en lograr el objetivo del sprint y establecer la planificación de las próximas 24 horas.

    En la reunión rápida, debéis compartir todas las preocupaciones que tengáis con respecto al cumplimiento del objetivo del sprint o cualquier impedimento.

    Una forma habitual de dirigir una reunión rápida es que cada miembro del equipo responda a tres preguntas relacionadas con lograr el objetivo del sprint:

    • ¿Qué hice ayer?
    • ¿Qué tengo previsto hacer hoy?
    • ¿Se presenta algún obstáculo?

    No obstante, hemos visto que algunas reuniones tratan solo de leer las agendas del día anterior y la del día siguiente. La teoría que subyace a las reuniones rápidas es que se traten de una charla distendida, para que el equipo pueda centrarse en su trabajo durante el resto del día, por lo que, si se convierten en una lectura diaria de la agenda, no tengas miedo de sacar tu creatividad y cambiar la mecánica.

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

    En esta reunión de revisión, el propietario del producto modifica el backlog del producto en función del sprint actual, lo que puede servir para la próxima sesión de planificación de sprint. En un sprint de un mes, contempla la posibilidad de establecer un límite de tiempo máximo de cuatro horas para la revisión del sprint.

  6. Retrospectiva del sprint: la retrospectiva es el momento en el que el equipo se reúne para documentar y comentar lo que ha funcionado y lo que no ha funcionado en un sprint, un proyecto, una herramienta, entre las personas o relaciones o incluso en un protocolo. La idea es crear un entorno en el que el equipo se pueda centrar más en lo que ha salido bien y lo que necesita mejorar para la próxima vez, y menos en lo que ha salido mal.

Tres funciones esenciales para alcanzar el éxito con scrum

El equipo de scrum debe componerse de tres cargos 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 del producto son los mayores expertos en su producto. Se centran en conocer los requisitos empresariales, de los clientes y del mercado, y priorizan el trabajo que debe realizar el equipo de ingeniería de acuerdo con esta información. Los propietarios de producto eficaces realizan estas tareas:

  • Crean y gestionan el backlog del producto.
  • Establecen una estrecha asociación con la empresa y el equipo para asegurarse de que todo el mundo conoce los elementos de trabajo del backlog del producto.
  • Les proporcionan a los equipos directrices claras acerca de las siguientes funciones que se van a proporcionar.
  • Deciden cuando se lanza el producto, con predisposición a que la entrega se realice de forma frecuente.

El propietario del producto no siempre es el gestor de proyectos. Los propietarios de producto se centran en asegurarse de que el equipo de desarrollo trabaje de la forma más beneficiosa posible para 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 de producto.

El experto en scrum

Los expertos en scrum son los mayores especialistas de scrum en el equipo. Proporcionan formación a los equipos, a los propietarios del producto y a la empresa en el proceso de scrum, y buscan formas de perfeccionar su 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 trabajo. Como moderador principal, planifica los recursos necesarios (tanto humanos como logísticos) para organizar la planificación de 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 más 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" ideada por 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 distintas habilidades 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 organizan de forma autónoma y enfocan sus proyectos con una clara actitud colectiva. Todos los miembros del equipo se ayudan entre sí para asegurar una finalización satisfactoria del sprint.

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.

Scrum, kanban y la metodología ágil

Scrum es un marco de trabajo de metodología ágil tan popular que, a menudo, se malinterpretan scrum y metodología ágil, y se piensa que son lo mismo. También existen otros marcos de trabajo, como kanban, que es una alternativa también 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 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 trabajo en curso) 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, la retrospectiva, el scrum diario, etc. También insiste en la interdisciplinariedad, que es la capacidad de un equipo de scrum para 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.

Entonces, ¿por qué elegir 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 ayuda, en realidad, 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 delimitació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 percibir progreso en poco tiempo.

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


Aun así, los beneficios a largo plazo sobrepasan con creces la curva de aprendizaje inicial. El éxito del scrum en el desarrollo de productos complejos de hardware y software para varios sectores y ejes verticales lo convierte en un marco solvente para adoptarlo en una organización.

Claire Drumond
Claire Drumond

Claire Drumond es estratega de marketing, ponente 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 basada en compartimentos estancos y crear empatía.

A continuación
Sprints