Ágil es una mentalidad y no existe tal cosa como "hacer ágil". La mentalidad ágil se basa en el Manifiesto Ágil, que dice:
"Estamos descubriendo mejores formas de desarrollar software al hacerlo y ayudar a otros a hacerlo.
A través de este trabajo, hemos llegado a valorar:
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación exhaustiva
- Colaboración con el cliente sobre negociación de contratos
- Responder a los cambios sobre seguir un plan
Es decir, aunque hay valor en los elementos a la derecha, valoramos más los elementos a la izquierda.
El Manifiesto Ágil es la base de la mentalidad ágil. Ágil es una mentalidad que valora a las personas, productos de trabajo funcionales, colaboración con las partes interesadas y adaptación al cambio.
Dentro del paraguas ágil se encuentran múltiples metodologías para colaborar y funcionar como equipo, todas con la mentalidad y el manifiesto ágil en mente. De estas metodologías, la más ampliamente utilizada en el desarrollo de software es Scrum.
Si has trabajado en un equipo que ha hablado de "eventos de Scrum", "sprints", "refinamiento del backlog" y "revisiones de sprint", es probable que hayas trabajado con un equipo que intentaba operar utilizando la metodología Scrum. Recuerda, ágil es una mentalidad, Scrum es una metodología.
La metodología Scrum está definida en la Guía de Scrum, que fue actualizada por última vez a finales de 2020 por Ken Schwaber y Jeff Sutherland, quienes son considerados los padres fundadores de Scrum. Este artículo se basa en la Guía de Scrum de 2020 y se centra específicamente en los eventos de Scrum, proporcionando algunos consejos y trucos para aprovechar Scrum en tu organización.
Personalmente, he utilizado la metodología Scrum en muchos tipos diferentes de equipos y contextos, desde el desarrollo de Salesforce hasta la creación de contenido de capacitación.
He implementado Scrum y realizado sesiones de capacitación con numerosos equipos, muchos de ellos con contribuyentes dispersos a nivel global. Si eres nuevo en Scrum, es posible que quieras comenzar con una comprensión más profunda de la metodología en este artículo, la guía completa de Scrum. ¡Vamos a empezar!
¿Qué son los Eventos de Scrum?
Los eventos de Scrum (a veces llamados ceremonias de Scrum) son eventos o elementos importantes de la metodología Scrum que siguen la mentalidad ágil y se utilizan con frecuencia en el desarrollo de software o proyectos de tipo iterativo.
Existen cinco eventos de Scrum específicamente definidos:
- El sprint
- Planificación de sprint
- Scrum diario
- Revisión de sprint
- Retrospectiva de sprint
Los eventos de Scrum no son simplemente reuniones por el simple hecho de tener reuniones. Más bien, estos eventos de Scrum proporcionan el marco de trabajo para que los equipos realicen su trabajo de manera estructurada, ayudan a establecer expectativas, empoderan al equipo para colaborar de manera efectiva y, en última instancia, generan resultados.
Sin embargo, si no se gestionan adecuadamente, pueden saturar los calendarios y restarle valor a lo que se supone que deben proporcionar.
El propio Scrum, al igual que los eventos de Scrum, es deliberadamente ligero y sencillo. Scrum es fácil de aprender, pero puede ser difícil de dominar. Está diseñado para proporcionar un marco de trabajo para equipos multifuncionales para resolver problemas complejos.
En pocas palabras, Scrum es una metodología o proceso a través del cual se ejerce la mentalidad ágil. Si esto no te queda claro, vuelve al inicio del artículo y lee acerca del origen del ágil y del ágil como mentalidad. Luego, regresa aquí.
Los Roles en Scrum
Antes de avanzar demasiado, revisemos rápidamente los tres roles en Scrum.
- El product owner: Este rol representa al cliente y al negocio en general para el producto en el que están trabajando. Son dueños del backlog y determinan la prioridad de los elementos de trabajo para el equipo de desarrollo. Toman decisiones ejecutivas sobre el producto a diario. Traducen las necesidades del cliente en elementos de trabajo concretos para el equipo de desarrollo.
- El Scrum master: Los Scrum masters son responsables de asegurarse de que el equipo tenga lo que necesita para tener éxito, incluyendo una comprensión clara del proceso Scrum. Son un coach, consejero, defensor, eliminador de impedimentos, facilitador y mediador, todo en uno. Los Scrum masters son responsables de establecer Scrum según lo definido en la Guía de Scrum, pero no son gerentes de proyecto (¡cuidado con cualquier líder que crea que estos son el mismo rol!) — no son responsables del producto de trabajo. Además, un Scrum master no necesariamente es una persona individual o un trabajo a tiempo completo. Lee más sobre la diferencia entre Scrum masters y gerentes de proyecto aquí.
- El equipo de desarrollo: Este es un grupo de miembros del equipo multifuncionales enfocados en la entrega de software funcional o el resultado deseado del equipo. Es el sustantivo singular para cualquier desarrollador, diseñador, control de calidad y otros roles técnicos que deben colaborar en el desarrollo real de un producto. Idealmente, este grupo de 5 a 9 personas está completamente dedicado a un equipo de Scrum. En la realidad, y especialmente en agencias, puede verse un poco diferente. El equipo de desarrollo debe ser autoorganizado y motivado para proporcionar valor, y con la facilitación adecuada de un Scrum master y un product owner, pueden lograrlo.
Cada uno de estos roles tiene una participación única en cada uno de los eventos de Scrum. Cuando se facilitan de manera efectiva, los eventos de Scrum empoderarán a cada persona en su rol para tener una gran oportunidad de éxito.
Los 5 Eventos de Scrum Simplificados
En este artículo, desglosaremos los cinco eventos y ceremonias de Scrum, adentrándonos en su propósito, asistentes, y consejos para hacerlos más efectivos. Los cinco eventos de Scrum son:
- El Sprint
- Planificación de Sprint
- Scrum Diario
- Revisión de Sprint
- Retrospectiva de Sprint
Es importante destacar que cada uno de estos eventos está limitado en tiempo, es intencional y está al servicio del equipo de Scrum en su conjunto. En otras palabras, existen para hacer posible la entrega de resultados.
Nota: Llevar a cabo estos eventos de forma aislada no convertirá automáticamente a tu equipo en ágil, ni garantizará que tu equipo esté operando bajo la metodología Scrum. Para ejecutar Scrum de manera efectiva, estos eventos deben ser parte de un proceso más amplio, bien comprendido y articulado.
Deben facilitar conversaciones dentro del equipo ágil para lograr que las cosas se hagan. Y, ¿qué tipo de gerente de proyecto no quiere que las cosas se hagan?
El Sprint
¿Qué es un Sprint?
Un sprint en Scrum es un período de tiempo fijo (generalmente de un mes o menos) en el que las ideas se convierten en valor. El sprint es el latido del corazón de Scrum. Los sprints ocurren de manera consecutiva, uno tras otro, hasta que el producto esté completo (o sin fin). A menudo, los equipos miden su futuro en sprints.
¿Cuál es su Propósito?
El propósito del sprint es limitar el tiempo de trabajo y llevar a los equipos a cumplir con sus compromisos. Los sprints permiten establecer metas a corto plazo pero sólidas. Durante un sprint, nada debe cambiar que ponga en peligro el objetivo del sprint.
Los equipos se comprometen a entregar un conjunto específico o conjuntos de trabajo al comienzo del sprint y trabajan incansablemente para completar ese objetivo a lo largo del sprint. Al final del período, el equipo se reúne para revisar su trabajo y determinar qué trabajarán durante el próximo sprint, basándose en un backlog priorizado del product owner.
El sprint mantiene al equipo enfocado en la tarea, pero permite correcciones de rumbo o cambios de sprint en sprint. Los sprints permiten previsibilidad al asegurarse de que lo que el equipo de desarrollo se compromete a hacer se hará o se revisará en un corto período de tiempo. Con los sprints, el "ya veremos cuando suceda" desaparece. Sabemos cuándo sucederán las cosas porque se comprometen o no se comprometen en el sprint.
¿Quiénes Asisten?
Todo el equipo Scrum: el product owner, el equipo de desarrollo y el Scrum master.
¿Cuánto Dura?
Un sprint dura de 1 a 4 semanas, no más. Esta limitación permite que los equipos avancen y entreguen progreso incremental rápidamente, pero sin volver locas a las personas.
Cuando implemento Scrum con un equipo nuevo que no se dedica al desarrollo de software, a menudo comienzo con sprints de 1 semana, ya que generalmente podemos planificar con una semana de anticipación. También hay un ritmo natural en el sprint de 1 semana, ya que se alinea con la semana laboral.
Los equipos más avanzados, especialmente aquellos que entregan software, a menudo utilizan sprints de 2 semanas, lo que permite más innovación y pruebas durante el período de tiempo establecido. Si estás empezando, te sugiero intentar con sprints de 2 semanas y ver cómo funciona durante algunas iteraciones antes de hacer cambios.
¿Hay Algunos Consejos Útiles?
- Los sprints no son el enemigo, ni son específicamente un motivador. No trates de molestar o persuadir a las personas debido al sprint en sí. En su lugar, motiva a las personas a lograr el objetivo del sprint y entregar un producto incrementado.
- Considera cuándo va a comenzar y terminar tu sprint. Un sprint debe comenzar justo después de que el último sprint termine, literalmente dentro de horas. El tiempo entre el fin y el inicio del sprint debe ser simplemente tiempo para tu revisión de sprint, retrospectiva y planificación de sprint; ¡y luego todo comienza de nuevo!
¿Algo Más?
Los sprints no pueden alargarse ni acortarse. Un sprint solo puede cancelarse si el objetivo del sprint se vuelve obsoleto. Solo el product owner tiene la autoridad para cancelar el sprint.
Planificación de Sprint
¿Qué es una Reunión de Planificación de Sprint?
La planificación de sprint es el evento Scrum diseñado para asegurarse de que el equipo esté preparado para hacer las cosas correctas en cada sprint.
¿Cuál es su Propósito?
Esta reunión Scrum ocurre al comienzo de un nuevo sprint de Scrum y está diseñada para permitir que el product owner y el equipo de desarrollo revisen el backlog de productos priorizado. A través de una serie de discusiones y negociaciones, el equipo debe crear finalmente un backlog de sprint que contenga todos los elementos a los que se comprometen a completar al final del sprint.
Esto, junto con un resumen de lo que se entregará, se llama el objetivo del sprint. El objetivo del sprint debe ser un incremento de trabajo que se puede demostrar al final del sprint. Debe ser acordado por todo el equipo.
Aquí tienes un ejemplo de un objetivo de sprint: Implementar un sistema de retroalimentación de clientes integrado con la gestión de casos de éxito del cliente. El sprint asociado con este objetivo incluiría múltiples epopeyas e historias que contribuyan a lograr la implementación de un sistema de retroalimentación de clientes integrado con la gestión de casos de éxito del cliente.
El product owner es responsable de tener listo el backlog de productos priorizado para su revisión antes de que comience la planificación de sprint. Esto implica agregar criterios de aceptación, requisitos y detalles necesarios para que el equipo de desarrollo estime con precisión el esfuerzo requerido (a menudo en puntos de historia).
El product owner también debe poder aclarar cualquier pregunta o suposición que el equipo de desarrollo tenga sobre el trabajo. Solo entonces el equipo de desarrollo puede prever con precisión la cantidad de trabajo que puede realizar durante el sprint.
¿Quiénes Asisten?
Todo el equipo Scrum: el product owner, el equipo de desarrollo y el Scrum master.
¿Cuánto Dura?
La duración de la mayoría de los eventos de Scrum está relacionada con la duración del sprint. En cuanto a la planificación de sprint, debe durar 2 veces la duración del sprint (en horas). Por ejemplo, si tu sprint dura 2 semanas, la reunión de planificación de sprint no debe durar más de 4 horas. Para un sprint de 1 semana, no debe durar más de 2 horas.
¿Hay Algunos Consejos Útiles?
- Las epopeyas e historias de usuario se pueden dividir en tareas más pequeñas y asignar durante la planificación de sprint para que todos sepan a qué son responsables.
- Anima al equipo a esbozar tareas, errores y cualquier elemento que lo requiera durante esta reunión Scrum. Debe ser un evento extremadamente colaborativo.
- Una vez que se establece un objetivo de sprint, no debe ser interrumpido por trabajo competitivo. Sin embargo, el product owner puede cancelar el sprint si el objetivo ya no es relevante para el producto o los objetivos del negocio.
- Sigue tu límite de tiempo. Mantén un ojo en el reloj y, una vez que se alcance el tiempo, detente.
- Asegúrate de tener en cuenta cualquier tiempo libre, vacaciones, días festivos u otros detalles de programación durante el sprint para reflejar con precisión la cantidad de trabajo que se puede realizar.
- De manera similar, intenta tener una medida de la velocidad del equipo antes de que comience la planificación de sprint, suponiendo que hayas estado operando en la metodología Scrum durante algún tiempo.
- Cualquier cosa que no se haya completado en el último sprint pero se haya comprometido debe volver al backlog y considerarse para un próximo sprint, según la prioridad asignada por el product owner.
- Recuerda: ¡Estás planificando un sprint, no un maratón! Trata de no distraerte con elementos que no han sido considerados como listos por el product owner.
¿Algo Más?
La planificación de sprint permite al equipo Scrum responder a las preguntas "¿Qué se puede entregar en este próximo sprint? ¿Y cómo lograremos ese trabajo?" Ayuda a proporcionar previsibilidad y crea un entorno colaborativo para alcanzar el objetivo de cada sprint.
Scrum Diario (Reunión Diaria)
¿Qué es una Reunión Diaria de Scrum?
El Scrum Diario es la oportunidad del equipo de reunirse, celebrar los logros recientes, definir un plan para el trabajo del día y identificar cualquier obstáculo.
¿Cuál es su Propósito?
Este evento Scrum brinda una oportunidad frecuente y regular para que el equipo se reúna y comunique el progreso individual hacia el objetivo del sprint. No es una actualización de estado.
En cambio, debería iluminar cualquier obstáculo que el equipo esté experimentando. El Scrum master es responsable de eliminar estos obstáculos para que el equipo de desarrollo pueda concentrarse en entregar el trabajo identificado en la planificación de sprint.
El Scrum Diario es más que una actualización de estado; el equipo se reúne para una revisión rápida que debe iluminar cualquier obstáculo que esté frenando el progreso del equipo.
Durante el Scrum Diario, cada miembro del equipo de desarrollo debe responder brevemente a las siguientes preguntas (a menudo consideradas como una plantilla):
¿Qué hiciste ayer? ¿Qué harás hoy? ¿Existen obstáculos en el camino? Cada participante en esta reunión Scrum debe escuchar a los demás y permanecer presente durante toda la reunión. A menudo, los miembros del equipo de desarrollo identificarán oportunidades para trabajar juntos durante el día basándose en los comentarios durante el Scrum Diario.
¿Quiénes Asisten?
El Scrum master y el equipo de desarrollo. El product owner es un asistente opcional. En ocasiones, se pueden invitar a stakeholders externos a escuchar el Scrum Diario.
¿Cuánto Dura?
¡Esta es breve! No debe durar más de 15 minutos. Más fácil decirlo que hacerlo.
¿Hay Algunos Consejos Útiles?
- El Scrum master es responsable de mantener el ritmo en esta rápida reunión de Scrum. ¡Considera usar un temporizador!
- Realiza la reunión a la misma hora todos los días de la semana (generalmente por la mañana) y haz lo posible por hacer que esto sea lo más rutinario posible para el equipo Scrum.
- Si tu equipo está distribuido, utiliza software de videoconferencia para que el equipo aún pueda verse.
- Para las reuniones en vivo, considera lanzar una pelota alrededor de la habitación para indicar quién debería hablar en un momento dado.
- Si (o más bien cuando) algo surja en esta reunión que requiera una conversación más larga, anima a los miembros del equipo a sincronizarse tan pronto como termine el Scrum Diario para determinar cuándo quieren colaborar. Puede ser inmediatamente después de la reunión o más tarde en el día. Nuevamente, déjalos autoorganizarse.
- Existen herramientas e integraciones de Slack que permiten que las reuniones en pie se realicen de forma asincrónica. Si bien esto puede ser útil en ciertas circunstancias, se recomienda que estas reuniones se realicen en persona o a través de una videollamada.
- El Scrum Diario no debe cancelarse si un líder o Scrum master no puede asistir; la reunión no es para ellos, es para el equipo; realiza el Scrum Diario.
- El tono debe ser ligero y divertido, pero con un enfoque en recopilar y comunicar información.
¿Algo Más?
También conocida como la reunión diaria en pie o reunión de Scrum, esta revisión rápida debería preparar bien al equipo para el día. No dejes que consuma demasiado tiempo o tendrá el efecto contrario.
Esta reunión permite que el equipo esté sincronizado y construya confianza entre ellos. Deja que el equipo se responsabilice mutuamente de cumplir sus compromisos a diario.
Revisión de Sprint
¿Qué es una Revisión de Sprint?
La revisión de sprint es el evento Scrum donde todo el trabajo completado durante el sprint puede ser mostrado a los stakeholders.
¿Cuál es su Propósito?
Al final de cada sprint, la revisión de sprint brinda una plataforma para que el equipo de desarrollo muestre todo el trabajo que se ha completado. Esto permite que los stakeholders vean las cosas más temprano que tarde y examinen o adapten el producto a medida que emerge.
Las revisiones de sprint pueden llevarse a cabo de manera informal en un ambiente de "Demo Friday" o pueden organizarse de manera más estructurada. Todo depende de varias variables del equipo Scrum, como el ciclo de vida del producto y la planificación de lanzamientos.
Lo más importante es que todo el trabajo mostrado durante este tiempo debe ser completamente demostrable y cumplir con la definición de hecho que el equipo haya acordado. El equipo debe sentirse empoderado para mostrar el trabajo que ha logrado completar durante el sprint.
No debería sentirse como si estuvieran en juicio o defendiendo el trabajo que han hecho o estar en riesgo de ser criticados por los stakeholders en la revisión de sprint. Más bien, el contenido de la reunión debería centrarse en el valor comercial que se entrega a través del desarrollo del producto.
¿Quiénes Asisten?
El equipo Scrum: product owner, equipo de desarrollo y Scrum master. También suele incluir una mezcla de gerentes, stakeholders externos, clientes e incluso desarrolladores de otros proyectos. En cuanto a quiénes deben estar presentes, este evento Scrum es más flexible que los demás.
El product owner y el Scrum master deberían discutir quiénes deberían estar involucrados antes de la revisión de sprint y trabajar para asegurarse de que estén presentes.
¿Cuánto Dura?
1 hora por semana del sprint. Como ejemplo, una revisión de sprint de 2 horas debería programarse para un sprint de 2 semanas.
¿Hay Algunos Consejos Útiles?
- El Scrum master generalmente asume cualquier tarea administrativa, asegurando que las salas de reuniones estén reservadas, que haya ayudas adicionales para la presentación (como pizarras o papeles para pizarrón, por ejemplo) y que la reunión esté adecuadamente limitada en tiempo. Considera proporcionar refrigerios también.
- Los comentarios accionables recibidos durante la revisión de sprint deben convertirse en nuevos elementos en el backlog de productos para su posterior priorización y discusión.
- ¡Prepararse para esta reunión es una buena idea! Dado que a menudo asisten stakeholders fuera del equipo Scrum, asegúrate de incluir cualquier ensayo o preparación necesarios para preparar al equipo para el éxito.
- Enfoca la revisión de sprint en la experiencia del usuario y el valor comercial. No debería sentirse como si el equipo de desarrollo estuviera demostrando que las cosas funcionan.
- El product owner debe hacer preguntas a los stakeholders, recopilar comentarios y también proporcionar respuestas a cualquier pregunta que surja.
- Como product owner o stakeholder, ten cuidado de no empezar a criticar públicamente el buen trabajo del equipo de desarrollo, incluso si no está del todo correcto, ya que esto puede afectar significativamente la motivación y causar temor a futuras revisiones de sprint. El equipo estaba entregando según los requisitos establecidos por el product owner. Si los requisitos no eran correctos o no estaban lo suficientemente bien explicados como para obtener los resultados deseados, menciona esto al product owner para que se pueda manejar en una retrospectiva o planificación de sprint y obtener un mejor resultado la próxima vez.
¿Algo Más?
También conocida como la demostración de sprint, este evento Scrum ayuda a construir confianza entre los stakeholders y el equipo Scrum.
Es la forma más directa de recopilar comentarios tempranos y frecuentes que eventualmente se agregarán al backlog de productos. Haz todo lo posible para que el equipo brille y celebre el éxito tanto en el camino como en la revisión de sprint en sí.
Retrospectiva del Sprint
¿Qué es una Reunión de Retrospectiva del Sprint?
La retrospectiva del sprint es el último evento Scrum en la secuencia del sprint que permite al equipo revisar el trabajo que acaba de completarse e identificar elementos que podrían mejorarse en función de sus experiencias en el sprint anterior (ahora cerrado).
¿Cuál es su Propósito?
Después de que se haya llevado a cabo una revisión de sprint, el equipo Scrum necesita tener la oportunidad de reflexionar sobre el trabajo que acaba de ser presentado y discutir formas de mejorar tanto el resultado como el proceso.
La retrospectiva del sprint es esa reunión. Le brinda al equipo Scrum una plataforma para discutir lo que está funcionando bien, lo que podría funcionar mejor y algunas sugerencias de cambios.
Algunas preguntas comunes que se hacen son (a menudo consideradas como una plantilla):
- ¿Qué salió bien en el último sprint?
- ¿Qué no salió tan bien?
- ¿Qué podríamos hacer de manera diferente para mejorar?
En última instancia, este evento Scrum debería proporcionar un espacio libre de culpa para que los miembros del equipo brinden sus comentarios honestos y recomendaciones para mejoras. Debería impulsar el cambio.
Todos los comentarios accionables deben recopilarse y asignarse de la misma manera que otros epics o historias para que los miembros del equipo Scrum comprendan quién es responsable de qué y cuándo se implementarán los cambios.
Los elementos de trabajo que surjan como resultado de una retrospectiva deben incluirse en la planificación del sprint y comprometerse al igual que todos los demás elementos de trabajo.
Ágil se trata de la mejora constante, y este evento está diseñado específicamente para ayudar al equipo Scrum a mejorar.
¿Quiénes Asisten?
El Scrum master y el equipo de desarrollo. El product owner es un asistente opcional. No debe haber stakeholders externos involucrados en la retrospectiva (¡esto es muy importante!).
¿Cuánto Dura?
Por lo general, las retrospectivas del sprint no deben durar más de 1.5 horas para un sprint de dos semanas. Si tus sprints duran un mes, la retrospectiva no debe durar más de 3 horas.
Personalmente, facilito retrospectivas que duran entre 30 y 75 minutos en promedio. Cuando trabajo con equipos parcialmente remotos o completamente distribuidos, utilizo herramientas de colaboración activa como Mentimeter o Confluence para que las personas participen sin tener que desactivar el silencio y compartir su voz ampliamente. Esto es especialmente efectivo para equipos globales.
¿Hay Algunos Consejos Útiles?
- Enfóquense en la mejora continua y reúnan información basada en hechos, no solo en sentimientos.
- Mantén las cosas novedosas y considera diferentes formas de involucrar al equipo durante esta reunión Scrum. Hay una gran cantidad de recursos disponibles que proporcionan ejemplos para hacer que estas reuniones sean más efectivas. Un ejemplo se puede encontrar aquí (enlace en inglés).
- Genera ideas significativas a partir de la conversación. Si sientes que hay más que decir entre líneas, anima a los miembros del equipo a profundizar.
- Si se plantea una sugerencia de mejora, pregunta a otros miembros del equipo Scrum si están todos de acuerdo. Si es así, identifica cómo se llevará a cabo esa recomendación.
- Crea un espacio donde la conversación fluya más fácilmente. Si están en el mismo lugar, considera traer comida, marcadores de colores, notas adhesivas y otras cosas para fomentar la participación. Si la reunión es en un espacio virtual, incluso puedes probar fondos virtuales festivos para cambiar un poco las cosas y hacer que las personas participen de una manera diferente a la habitual.
- Con el tiempo, revisa las sugerencias anteriores para determinar si el equipo debe seguir haciéndolas.
- Desarrolla la capacidad del equipo para autoorganizarse.
¿Algo Más?
Asegúrate de crear un entorno de seguridad psicológica. Esto no es un juego de culpas. Estas reuniones a menudo iluminan recomendaciones para mejorar y mitigar riesgos en el futuro. Como Scrum master, asegúrate de entrenar al equipo para que brinde comentarios honestos y sea respetuoso durante el evento.
¿Por Qué Son Importantes los Eventos de Scrum?
Los eventos de Scrum son el latido del corazón de la metodología Scrum. Sin los eventos, Scrum puede volverse muy rápidamente un proceso difícil de seguir y desordenado. Es especialmente importante con equipos nuevos, animo a las personas a implementar Scrum tal como está escrito en la Guía de Scrum, realizar algunas iteraciones de sprint y luego determinar qué necesita adaptarse para que se ajuste mejor al equipo.
Nota: Probablemente hayas notado que no hablamos en absoluto de un tablero de sprint (a veces llamado tablero Kanban, pero eso es una discusión completamente diferente) en este artículo. Eso se debe a que no es un elemento central de ninguno de los eventos de Scrum. Los tableros de sprint son excelentes herramientas para usar en cada evento, pero no son un elemento requerido.
¿Qué Piensas?
Independientemente de la herramienta de gestión de proyectos que utilices o del producto en el que estés trabajando, estos eventos de Scrum están diseñados para brindar resultados. He descubierto que estas reuniones ciertamente proporcionan estructura y funcionan bien cuando todo el equipo está comprometido con una comprensión compartida de para qué sirve cada evento de Scrum. Nuevamente, Scrum es solo un marco de trabajo que se utiliza para entregar software de manera ágil.
Sin embargo, cada equipo es diferente y no existe un proceso perfecto. ¡El consejo más simple que he escuchado es mantener en mente los principios! Piensa en tus eventos de sprint como un producto: sigue iterando y mejorando.
¿Buscas software específico para Scrum? Comienza con esta lista de las mejores herramientas de Scrum. Siéntete libre de dejar un comentario abajo sobre tus experiencias dirigiendo eventos de Scrum, y aprendamos unos de otros.