El marco Scrum — Segunda edición

Este capítulo conserva el contexto histórico y práctico de la segunda edición. El temario de la tercera edición también está disponible en el índice que aparece a continuación.

---

Ejemplo de Scrum: un caso real para equipos ágiles de alto nivel

En este artículo queremos presentarte un ejemplo de la metodología Scrum que puede inspirar a tus equipos Scrum, a otras partes interesadas del negocio y a las personas relacionadas con tus proyectos. Hemos visto muchos casos en los que las empresas cuentan con profesionales formados en Scrum, pero la falta de experiencia práctica les plantea dificultades en sus operaciones Scrum diarias y en la implementación de productos.

Este problema suele impedir que los equipos Scrum alcancen su velocidad óptima y entreguen sus resultados a tiempo y dentro del presupuesto. De ahí la importancia de este ejemplo de la metodología Scrum.

Por eso, en este breve artículo intentaremos ayudarte a ver el panorama general del marco Scrum: desde la construcción de procesos Scrum que generan un valor sin precedentes para los negocios, productos y servicios y ofrecen una gran experiencia de agilidad a tus clientes, hasta la configuración y el uso del gráfico de trabajo pendiente de Scrum para mejorar y mantener la velocidad de tus equipos.

Con este ejemplo de la metodología Scrum te ayudaremos a comprender cómo funciona un equipo Scrum y cómo puede beneficiar a tu organización. Los datos indican que, en la mayoría de las empresas, los equipos Scrum suelen estar formados por un Product Owner, un Scrum Master y desarrolladores, que juntos constituyen el Scrum Team y trabajan en iteraciones cortas llamadas Sprints para entregar incrementos valiosos del producto. Este enfoque iterativo permite flexibilidad, adaptabilidad y una respuesta más rápida.

Estos son los protagonistas de este ejemplo de la metodología Scrum:

• Alex, el Product Owner Scrum.
• Frank, el Scrum Master.
• El equipo Scrum.

Antes de comenzar el primer Sprint

Alex es nombrado Product Owner Scrum de un nuevo proyecto de desarrollo de software. Una de sus primeras tareas consiste en iniciar la ingeniería de requisitos. Anota los casos de uso más importantes y los comenta con los arquitectos, los representantes del cliente y otras partes interesadas. Tras reunir los casos de uso y requisitos de alto nivel, los incorpora al Product Backlog Scrum e inicia una sesión de estimación y priorización con los arquitectos y algunos desarrolladores sénior. Como resultado, todos los elementos del Product Backlog Scrum reciben una estimación inicial aproximada y una prioridad. A continuación, empieza a descomponer los requisitos de alto nivel en historias de usuario más pequeñas. Con esta lista, convoca la primera reunión de Planificación del Sprint.

Introducción a Scrum: un ejemplo real a través de distintas fases y Sprints

Sprint 1 - Día 0

Durante la reunión de Planificación del Sprint, Alex presenta los elementos del Product Backlog Scrum de mayor a menor prioridad. El equipo aclara las dudas y analiza, para cada elemento, si dispone de capacidad suficiente, de los conocimientos necesarios y de todo lo demás que se requiere. Tras esta conversación, se comprometen a completar las historias 1, 2, 3, 6, 7 y 8 al final de este Sprint. Los elementos 4 y 5 no pueden realizarse en este Sprint, porque todavía falta parte de la infraestructura técnica.

Tras la reunión de Planificación del Sprint, Frank, el Scrum Master del equipo, reúne a sus miembros para definir cómo se implementarán los elementos seleccionados. Las tareas resultantes se anotan en las tarjetas del tablero de tareas del Sprint preparado para ello. Ahora cada miembro del equipo Scrum selecciona una tarea en la que trabajar.

Consejo para equipos Scrum:

Alex, como Product Owner Scrum, dirige un nuevo proyecto de desarrollo de software dentro de su organización. Su función se parece a la de un director de orquesta en la que cada persona aporta su parte. Esta función transversal conlleva una gran responsabilidad y se centra en crear marcos autoorganizados de desarrollo ágil de software, donde la mejora es continua. El marco no es una solución universal, sino una ruta trazada para orientar el trabajo de los desarrolladores. Alex toma el pulso a la empresa y se asegura de que los productos finales sean los que necesitan los clientes. Un enfoque ágil como este itera continuamente y favorece el perfeccionamiento constante de productos y métodos.

A continuación, Alex impulsa una sesión de estimación y priorización utilizando historias de usuario (consulta más información sobre Historias de usuario Scrum) y puntos de historia como técnica de estimación relativa. La visualización al estilo Kanban puede complementar este trabajo al hacer visibles las tareas y el flujo para todos los miembros del equipo. Como resultado, todos los elementos del Product Backlog Scrum reciben una aproximación inicial y una prioridad. Alex aprovecha su experiencia en gestión de proyectos para descomponer los requisitos de alto nivel en historias centradas en el usuario, un enfoque que convierte eficazmente los requisitos en partes entregables. Estas historias de usuario, como ejemplos concretos de lo que quieren los clientes, muestran caminos para alcanzar los objetivos del proyecto. Con esta lista, convoca la primera reunión de Planificación del Sprint, fomentando una colaboración estrecha entre los miembros del equipo de desarrollo de software.

Sprint 1 - Día 1

Por la mañana, todo el equipo se reúne para su Daily Scrum. Cada persona explica brevemente qué ha conseguido, actualiza la estimación de las horas restantes en las tarjetas del tablero de tareas del Sprint, cuenta qué tiene previsto hacer ese día e indica si algún impedimento está bloqueando el progreso. Hoy, un miembro explica que necesita una nueva licencia para una de sus herramientas de software. Frank comprueba si otros miembros tienen el mismo problema y dice que se ocupará de ello después de la reunión. Al cabo de 15 minutos, todos vuelven al trabajo.

Después de la reunión, Frank actualiza el gráfico de trabajo pendiente del Sprint. Luego llama al proveedor de la herramienta, solicita las licencias y las hace llegar a quienes las necesitan.

Consejo para equipos Scrum:

Durante la Planificación del Sprint, Alex presenta los elementos del Product Backlog Scrum ordenados por prioridad. Dentro de la organización, le corresponde asegurarse de que todas las personas comprendan el objetivo general del proyecto. Las reuniones diarias del equipo facilitan conversaciones abiertas para aclarar funciones y resolver posibles problemas.

Frank, el Scrum Master, también desempeña una función clave en este equipo diverso. Ayuda a que las conversaciones de cada reunión diaria se centren en el Objetivo del Sprint cuando hace falta. Los desarrolladores son responsables de su plan y eligen sus tareas de forma colaborativa; Frank no les asigna el trabajo.

Sprint 1 - Día 2

Por la mañana, todo el equipo vuelve a reunirse para su Daily Scrum. Por la tarde, un miembro del equipo no tiene claros los detalles de una historia de usuario. Llama a Alex, el Product Owner Scrum, y comenta con él las dudas pendientes. Después de aclarar qué debe hacer, el miembro del equipo puede continuar con su implementación.

Sprint 1 - Día 28

Es el último día del primer Sprint y Frank, el Scrum Master, ha invitado al equipo a la Revisión del Sprint. El equipo ha preparado un equipo informático con la implementación actual del software. Alex, el Product Owner Scrum, se sienta ante él y comprueba si la implementación cumple sus expectativas y si las funcionalidades están documentadas como se requiere. Al final de la revisión, concluye:

• Las historias 1, 2, 6 y 7 están terminadas según lo esperado.
• La historia 3 no se pudo terminar a tiempo y no se presentó.
• La historia 8 tiene algunos aspectos que necesitan refactorización.

Por la tarde, el equipo se reúne para la Retrospectiva del Sprint y comenta qué ha ido bien y qué se podría mejorar. Una de las observaciones es que el equipo considera que no conoce suficientemente la arquitectura general del sistema. Frank se encarga de invitar al arquitecto del sistema para ofrecer una introducción más detallada.

Ejemplo de la metodología Scrum

Consejo para equipos Scrum:

Al llegar el último día del primer Sprint, Frank guía al equipo en la Revisión del Sprint. Su colaboración constante da lugar a un prototipo tangible que refleja el compromiso y el esfuerzo del equipo.

Por la tarde, el equipo celebra la Retrospectiva del Sprint. Intercambian impresiones sobre su progreso y vuelven a examinar los aspectos que necesitan mejorar en los próximos Sprints. Esta reunión resulta esencial para el enfoque ágil y aporta un valor considerable al conjunto del proyecto.

Al planificar el siguiente Sprint, vuelve a destacar la función de Alex como Product Owner Scrum, incorporando nuevos elementos al Product Backlog Scrum a partir de sus recientes reuniones con clientes. Al comenzar el segundo Sprint, resulta evidente que el trabajo en equipo, la transparencia y la gestión eficaz del proyecto siguen impulsando el éxito de este equipo dedicado al trabajo del conocimiento.

Sprint 2 - Día 1

Alex, el Product Owner Scrum, añade elementos al Product Backlog Scrum basándose en sus últimas reuniones con clientes. También incorpora elementos para refactorizar la historia 8. A continuación, invita al equipo a la reunión de Planificación del Sprint 2. El equipo debate y se compromete con las historias con la ayuda de Frank, el Scrum Master, y comienza el segundo Sprint.

Consejo para equipos Scrum:

El segundo Sprint pone en práctica lo que ha aprendido el equipo: el Product Backlog revisado refleja las opiniones de los clientes, se reconsidera el trabajo no terminado y la colaboración continúa en torno al siguiente Objetivo del Sprint.

Estudiar ejemplos y casos prácticos de Scrum es fundamental para las organizaciones que aspiran a crear equipos eficientes y de alto rendimiento. Analizar situaciones reales proporciona información valiosa sobre implementaciones exitosas y, algo igualmente importante, ayuda a identificar errores frecuentes que conviene evitar. Al aprender de estos ejemplos, los equipos pueden avanzar más deprisa para situarse entre los mejores, aprovechar las buenas prácticas, evitar posibles errores y conseguir logros rápidos en sus iniciativas Scrum.

Mantente al tanto de nuevos casos y situaciones reales que ampliarán tu comprensión del marco Scrum y de sus aplicaciones prácticas.