Fundamentos de Scrum Framework: ¿Cómo planificar un Sprint? + Infografía | Autor: Alonso Álvarez | Ilustraciones de Patricia Parreira.

Este artículo forma parte de una serie en la que revisaremos los fundamentos de Scrum complementados con infografías que los explican. 

Puedes consultar los artículos sobre el Sprint,la Planificación , Retrospectiva y Review

La reunión más corta de Scrum es también una de las que más da que hablar. Los 15 minutos (como máximo) de la reunión diaria, Scrum diario, o Daily Scrum, o Daily a secas, han sido revisados y diseccionados hasta la extenuación. En realidad no da para tanto, pero es una buena oportunidad para revisar también qué ocurre durante ese periodo de “un mes o menos”, el Sprint, algo que “puede considerarse un proyecto corto” (entrecomillados de la Guía Scrum oficial). 

¿Qué es un Daily Scrum?

Empecemos por la reunión en sí. El equipo Scrum necesita sincronización, comunicación fluida, foco, conocer el avance hacia su objetivo y hacer ajustes si es necesario (esta es la esencia de la agilidad). Esto se puede conseguir de muchas formas, pero verse al menos una vez al día es una forma de garantizar que eso ocurra (o de detectar si no pasa). 

Así que cada día, durante no más de 15 minutos, los desarrolladores (recordemos que se trata de las personas del equipo que no tienen la responsabilidad de ser PO o SM) analizan el progreso hecho durante el Sprint hacia su objetivo y producen un “plan accionable” para el día siguiente.  

Siempre ha habido mucha polémica sobre si deben o no participar PO y SM. En su última edición, la Guía Scrum deja claro que si asisten es sólo en el caso de trabajar activamente como desarrolladores.  

Al igual que los restantes eventos de Scrum, la Daily se hace de forma regular, a la misma hora y en el mismo lugar y con el mismo formato. Es una forma de reducir complejidad, variabilidad y, en fin, de simplificar al máximo todo lo que no sea el foco de la acción del equipo. 

¿Qué se hace durante la Daily? 

“Inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario”. No hay un formato recomendado, o preguntas, u orden. Cada equipo puede como quiera siempre y cuando cumpla con el propósito del evento. Las famosas preguntas de “¿Qué he hecho? ¿Qué voy a hacer? y ¿Qué impedimentos tengo?” son una forma más de hacerlo que ha dejado de ser recomendada por los creadores de Scrum. Si les funcionan a los desarrolladores estupendo, y si no se adaptan y cambian. Esta es una forma de fomentar la autogestión del equipo. 

Así que ya se pueden desechar esas ideas como que “la Daily la hace el SM” o “debe estar obligatoriamente el PO” y otras muchas que han formado parte de la práctica habitual de muchos equipos. La Daily se reduce a 15 minutos autogestionados para asegurar que se va por el camino anticipado, y a definir acciones para mantenerse en él. 

Pero… ¿De qué hablamos?

La Daily ocupa 15 minutos (como máximo, piénsese en esa idea de que Scrum implica “estar todo el día reunidos”). ¿Qué hacemos el 97% restante del tiempo? Hacer cosas, trabajar para ofrecer valor al cliente.  

Riesgos

Durante las, al menos, 7 horas y 45 minutos del día, se trabaja ante todo para conseguir el Objetivo que se definió al comienzo del Sprint, y ese es el foco. Dentro de la adaptación del proceso y la autogestión del equipo, se pueden introducir cambios, pero nunca los que pongan en riesgo el Objetivo. 

Impedimentos

Además, la Calidad no se sacrifica, disminuye o pone en cuestión. Ahorrar en calidad es un mal negocio. Lo que hacemos escatimando en calidad es, en realidad, generar deuda que antes o después deberemos devolver. Además, sabemos que los defectos que se introducen en nuestro producto o servicio tienen mucho más impacto y son mucho más costosos de reparar cuanto más tiempo pase, especialmente cuando están ya en manos de sus destinatarios, clientes o usuarios. 

Necesidad de refinar

También el Sprint es el momento de la anticipación, refinando el trabajo pendiente. “Refinar” aquí quiere decir averiguar, conseguir más información, clarificar, reenfocar, trocear, experimentar, … y en fin, realizar actividades que faciliten el trabajo futuro. Nunca ha existido (oficialmente) una reunión de “Refinamiento”, pero refinar el backlog es imprescindible. Al igual que la daily es una forma hacer explícita la inspección y adaptación día a día, los equipos pueden encontrar mecanismos que les ayuden a avanzar en el necesario refinamiento. 

A medida que progresa el Sprint, también avanza el conocimiento, lo que puede requerir reorientar el alcance clarificando y negociando con el PO. Como ya dijimos a la hora de hablar de la Planificación, contar con un plan es imprescindible, para la flexibilidad a la hora de introducir las adaptaciones necesarias lo es aún más. 

“Scrum deja disponible casi el 97% del día
para trabajar.”

Las responsabilidades en el día a día 

Lo que antes se conocía como roles de Scrum, ahora son responsabilidades (“acountabilities” en el original inglés, lo que implica un matiz adicional de rendir cuentas) y dedican su día a crear ese valor que esperan nuestros clientes y usuarios, pero además: 

Product Owner 

Tiene dos misiones principales: anticiparse y ayudar al equipo. 

La primera se refiere al proceso continuado de refinar y actualizar el backlog, es decir, la forma en la que se plasma la definición del producto o servicio. Eso significa estar en contacto permanente con stakeholders (las partes interesadas y con capacidad de influencia, en mayor o menor medida en aquello que está llevando a cabo el equipo), recoger y entender sus necesidades, ordenarlas adecuadamente, analizarlas con el equipo, asegurar su viabilidad, convertirlas en unidades fácilmente digeribles, … en general lo que podemos considerar la “gestión eficiente del Product Backlog”. 

Por otro lado, los desarrolladores pueden necesitar aclaraciones, tener dudas, pedir orientación. La ausencia del PO es una causa habitual e innecesaria de bloqueo. 

Desarrolladores 

No olvidemos que, aunque Scrum nació en el mundo del software, hoy es un marco de aplicación universal, aunque conserva quizá por nostalgia y tradición nombres como estos. Pensemos en “desarrolladores” como los miembros de un equipo multidisciplinar con todas las capacidades y conocimientos necesarios para desarrollar el trabajo: diseñar una campaña de marketing, ejecutar un proceso de recursos humanos, diseñar un producto físico, poner en marcha un restaurante, … y también crear software ¿por qué no? 

Ese equipo pondrá todo su compromiso, responsabilidad, dedicación y buen hacer en la tarea de cumplir el Objetivo del Sprint, manteniendo el nivel de calidad necesario, gestionando el Sprint Backlog y adaptando el plan cada día en la Daily. 

Scrum Master 

Finalmente, a quien tenga la responsabilidad de actuar como Scrum Master le queda la tarea de hacer que todo esto suceda, manteniendo la efectividad del equipo, promoviendo la eliminación de los impedimentos, capacitando a los miembros del equipo, y sirviendo a todos como líder de Scrum. 

Descargar Infografía completa

¿Quieres conocer más prácticas Scrum?

Te recomendamos la formación “Agile Fundamentals”, un curso de 24h para empezar a aprender los conocimiento y habilidades de Scrum y Kanban, acreditado por ICAgile.

IR AL CURSO Agile fundamentals