---

¡Aprende el marco Scrum con un caso de estudio real! ¡Puede que te sorprenda!

Antes de comenzar el primer Sprint

Alex es el Product Owner de un nuevo proyecto de desarrollo de software. Una de sus primeras tareas es evaluar e identificar los requisitos para aportar el valor empresarial que busca su cliente.

Debe asegurarse de que el cliente reciba el software adecuado para lograr resultados empresariales tangibles. Anota los casos de uso esenciales y los comenta con arquitectos, representantes del cliente y otras partes interesadas de las áreas de TI y negocio. (Consulta nuestra Ejemplo de Scrum)

Tras recopilar los casos de uso y los requisitos generales, los incorpora al Product Backlog Scrum y organiza una sesión de estimación y priorización con el equipo Scrum. Como resultado, todos los elementos del Product Backlog reciben una estimación aproximada y una prioridad iniciales.

Durante estas sesiones, Anna, la Scrum Master, se asegura de que todos hablen el mismo idioma. Así, el Product Owner, los miembros del equipo y sus partes interesadas están alineados con los objetivos previstos. De este modo, tienen una comprensión adecuada de conceptos posiblemente nuevos para ellos, como caso de uso, Product Backlog, Sprint, etc. Y, sobre todo, el proceso Scrum de desarrollo y entrega de software se aplica correctamente en su entorno de trabajo.

Ahora Alex, el Product Owner, comienza a desglosar los requisitos generales en un primer borrador de historias de usuario más detalladas. Con esa lista convoca la primera Sprint Planning.

Sprint 1 - Día 0

Durante la Reunión de planificación del Sprint, Alex presenta los elementos del Product Backlog de mayor a menor prioridad. El equipo Scrum plantea y aclara las dudas pendientes. Para cada elemento, debate si tiene capacidad suficiente y los conocimientos necesarios para desarrollarlo y entregarlo. El equipo debe garantizar que todos los recursos humanos y técnicos necesarios estén disponibles antes de comenzar el Sprint. Deben confirmar que se cumplen los requisitos previos y las dependencias que puedan ser esenciales para entregar correctamente ciertas funcionalidades.

Durante la Sprint Planning: parte del qué, los Developers prevén completar las historias de usuario 1,2,3,6,7 y 8 al final del Sprint para apoyar el Sprint Goal acordado. Estas historias pasan ahora del Product Backlog al Sprint Backlog. Las historias 4 y 5 no pueden completarse en este Sprint, ya que aún falta parte de la infraestructura técnica necesaria.

Después de la parte del qué de la Sprint Planning, Anna, la Scrum Master, reúne al equipo para profundizar en cómo implementará las historias de usuario comprometidas: la parte del cómo. Las tareas que surgen se anotan en tarjetas y se guardan en el Sprint Backlog. Todos los miembros están preparados para seleccionar una tarea y comenzar a trabajar.

Sprint 1 - Día 1

Por la mañana, los Developers se reúnen para su Daily Scrum. Cada persona hace una intervención breve y concisa sobre lo que ha hecho y actualiza las estimaciones de trabajo pendiente en las tarjetas del Sprint Backlog. Explica qué prevé hacer hoy y señala cualquier impedimento que le dificulte avanzar en las tareas.

Hoy Melinda, una de las integrantes del equipo, comunica que tiene un problema con la licencia del entorno integrado de desarrollo que utiliza. Anna comprueba si otros miembros tienen el mismo problema y confirma que se ocupará del impedimento después de la reunión. Tras unos 15 minutos de Daily Scrum, todos vuelven al trabajo.

Después de la reunión, Anna actualiza el gráfico de trabajo pendiente del Sprint para visualizar el progreso del trabajo. Después llama al proveedor de software, solicita la licencia que falta y se la entrega a Melinda.

Introducción a Scrum: un ejemplo real o caso de estudio a lo largo de distintas fases y Sprints

Sprint 1 - Día 2

Por la mañana, los Developers vuelven a reunirse para su Daily Scrum. Por la tarde, James, un miembro del equipo Scrum, tiene dudas sobre el resultado esperado de una historia. Llama a Alex, el Product Owner, y la comentan para asegurarse de que James la comprende bien. Cuando tiene claro cómo proceder, continúa implementándola.

Sprint 1: día 6

El día vuelve a comenzar con la Daily Scrum. Anna observa que esta mañana la reunión tiende a superar los 15 minutos. Los miembros están debatiendo cómo optimizar consultas a la base de datos. Anna les recuerda que la Daily Scrum no está pensada para largos debates técnicos, sino para inspeccionar el progreso hacia el Sprint Goal y adaptar el plan de los Developers.

Después de la Daily Scrum, Alex (Product Owner) informa a Anna (Scrum Master) de que el cliente ha planteado nuevos requisitos que podrían afectar al Sprint actual y a los siguientes. Anna le recuerda amablemente que los cambios no deben poner en peligro el Sprint Goal. Los Developers y el Product Owner pueden aclarar o renegociar el alcance a medida que aprenden, sin tratar cada historia seleccionada como un compromiso inmutable. Por eso, Anna organiza una reunión de refinamiento del Product Backlog por la tarde para que Alex pueda informar al equipo de los nuevos requisitos.

Durante la reunión, el grupo ayuda a Alex a determinar cómo encajan estas historias en el plan general de desarrollo, su desglose inicial de tareas, sus estimaciones y sus prioridades.

Sprint 1: día 10

Por fin llega el último día de este primer Sprint. Anna, la Scrum Master, invita al equipo a la Reunión de revisión del Sprint. El equipo ha preparado un servidor ajeno a producción con la última versión del incremento de software entregable que ha creado.

Alex, el Product Owner, y el señor Rich, una de las partes interesadas del cliente, se sientan ante una instancia de la interfaz gráfica del software. Comprueban si la implementación cumple las expectativas y si el equipo ha documentado adecuadamente los detalles del estado actual de la aplicación.

Al terminar la Sprint Review, Alex concluye:

• El equipo entregó las historias 1,2,6 y 7 conforme a lo comprometido y esperado.
• El equipo no pudo terminar a tiempo la historia 3 y no la presentó. La historia inacabada vuelve al Product Backlog para reordenarla; su trabajo restante puede seleccionarse durante la siguiente Sprint Planning.
• La historia 8 no cumplió la Definition of Done (DoD) común. Vuelve al Product Backlog, donde el equipo puede aclarar sus criterios de aceptación y tareas pendientes antes de decidir cuándo seleccionarla de nuevo.

Alex, el Product Owner, y el señor Rich, la parte interesada del cliente, informan brevemente al equipo Scrum sobre los próximos cambios y retos de los requisitos del software y la dirección que debe seguir la estrategia general de este software. El señor Rich agradece al equipo sus esfuerzos y su compromiso y sale de la sala.

Después de la Sprint Review, el equipo se reúne para la Reunión de Retrospectiva del Sprint. Durante la reunión comentan qué fue bien y qué podría mejorar, para perfeccionar sus previsiones y no repetir los problemas de las historias 3 y 8 en próximos Sprints. Uno de los obstáculos identificados es el conocimiento insuficiente de la arquitectura global del sistema. Anna asume la tarea de incorporar a un arquitecto de sistemas que acompañe y oriente al equipo al comienzo del siguiente Sprint.

Sprint 2 - Día 1

Alex sigue añadiendo requisitos al Product Backlog a partir de sus últimas reuniones con el cliente. Además, aclara los criterios de aceptación y el trabajo pendiente de la historia 8, manteniendo la Definition of Done común, para que el equipo comprenda mejor el resultado esperado.

Alex invita después al equipo a la Sprint Planning del Sprint 2. El equipo Scrum acuerda un Sprint Goal y los Developers seleccionan y planifican las historias que lo apoyan. Anna ayuda a que el evento sea eficaz y comienza el segundo Sprint.