Buenas y malas prácticas en las ceremonias del marco de trabajo Scrum: parte 2.

En la primera parte de esta serie, hablamos sobre las buenas y malas prácticas en las ceremonias Planning y Daily. En esta segunda parte y final, hablaremos sobre las ceremonias Sprint, Sprint Review, Sprint Retrospective y Grooming.

Ceremonia Sprint

Es un proyecto de no más de un mes, cuyo objetivo es conseguir un incremento.

Malas prácticas

• Atender las tareas de manera desorganizadas, lo que genera que al momento de integrar sea imposible lograr un entregable funcional.
• Subestimar los bloqueos, sean cuales sean, ya que muchos no permitirán un entregable funcional.
• Individualidades en el equipo.
• Establecimiento de silos de especialización dentro del equipo.
• Que Scrum master, Product owner o Stakeholders asignen tareas al equipo de desarrollo.
• Subestimar y obviarse los perfiles necesarios para la formación del equipo de trabajo para lograr el Sprint goal.

Buenas prácticas

• Las tareas deben atenderse coherentemente y ordenadamente con un fin claro. De esta manera, el incremento será funcional.
• El equipo debe ser multidisciplinario en lo posible, todos deberían estar en la capacidad resolver cualquier tarea del Sprint.
• Si es necesario, acceder a consultoría de expertos en algún área de conocimiento, para la asistencia al equipo de desarrollo. Debe el Scrum master velar porque se cubra esa necesidad oportunamente.
• El equipo de desarrollo debe trabajar cohesionado, integrado y con un sprint goal claro.
• El equipo de desarrollo debe auto gestionarse y cumplir con los lineamientos del facilitador Scrum master.
• El Producto Owner debe dar una prioridad a las historias a realizar, el Scrum master debe facilitar y organizar de manera que las historia se logren estratégicamente según las prioridades establecidas.
• El Scrum master debe facilitar y acompañar al equipo de desarrollo a lograr el Sprint Goal, buscando satisfacer resolver los bloqueos que se presenten de manera oportuna.

Ceremonia Sprint Review

Es la reunión de negocio por excelencia en Scrum. Al mismo acuden el equipo Scrum y Stakeholders. El Product Owner lo organiza y lidera; durante el Sprint Review, se inspecciona el Incremento y se adapta el Product Backlog.

Malas prácticas

• Presentar el incremento en láminas, presentaciones, escritos, o cualquier medio de información distinto a una solución funcional con datos funcionales.
• Improvisar en la entrega del incremento, producto no funcional.
• No invitar a Producto owner o stakeholders a esta ceremonia.
• El incremento sea presentado por el Scrum Master.
• Que la presentación del incremento supere las 4 horas.

Buenas prácticas

• Debe estar invitado todo el equipo de desarrollo, Scrum master, Product owner y stakeholders.
• El equipo de desarrollo debe presentar con anticipación el incremento al Product owner, por ejemplo 1 o 2 día antes de esta ceremonia, para que Product owner tome control del mismo, pueda revisar los logros y prepare sus argumentos para el turno de las preguntas y sugerencias de este evento. Además, el equipo de desarrollo ya posee un Feedback del incremento.
• El equipo de desarrollo expone el objetivo del Sprint goal, la lista de funcionalidades que se incluían y las que se han desarrollado.
• El equipo hace una introducción general del Sprint y demuestra el funcionamiento de las partes construidas.
• El equipo de desarrollo relata sus vicisitudes para lograr el incremento.
• Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el propietario del producto y el equipo en general, puedan mejorar la visión del producto.
• El Product owner identifica las historias de usuario que se pueden considerar “hechas” y las que no.
• Al ver y probar el incremento, el Product owner, y el equipo en general obtienen feedback relevante para revisar la pila del producto.
• La ceremonia no debe durar más de 4 horas
• Asegurar que los ítems entregados cumplen con el Definición of Done.
• Inspeccionar juntos el Product owner y los stakeholders los cambios del mercado y el potencial uso del producto.
• El Scrum Master, de acuerdo con las agendas del Product owner y el equipo, cierra la fecha para la reunión de preparación del siguiente sprint.

Ceremonia Sprint Retrospectiva

Es una oportunidad para el equipo de inspeccionarse a sí mismo, y crear un plan de mejora que se pondrá en marcha inmediatamente, en el siguiente Sprint.

Malas prácticas

• Reunión para evaluar Sprint, historias, tareas.
• Reunión para seguimiento y control.

Buenas prácticas

• El objetivo de la revisión del sprint es analizar “QUÉ” se está construyendo, mientras que una reunión retrospectiva se centra en “CÓMO” lo estamos construyendo: “CÓMO” estamos trabajando, con el objetivo de analizar problemas y aspectos mejorables.
• Las reuniones “retrospectivas” realizadas de forma periódica por el equipo para mejorar la forma de trabajo, se consideran cada vez más un componente del marco técnico de Scrum. Si bien no es una reunión para seguimiento de la evolución del producto, sino para mejora del marco de trabajo.
• Reunión que se realiza tras la revisión de cada sprint, y antes de la reunión de planificación del siguiente, con una duración recomendada de una a tres horas, según la duración del sprint terminado.
• En ella el equipo realiza autoanálisis de su forma de trabajar, e identifica fortalezas y puntos débiles. El objetivo es consolidar y afianzar las primeras, y planificar acciones de mejora sobre los segundos.

Ceremonia de Grooming o Refinamiento

Reuniones de Grooming o refinamiento del Backlog. Pese a no ser un evento oficialmente reconocido por Scrum.org, el propio Ken Schwaber, uno de los creadores del framework, reconoce la importancia de las reuniones de grooming, también conocidas como reuniones de refinamiento del Backlog.

Malas prácticas

• No realizar esta reunión y llegar al planning a analizar y refinar, para luego construir las tareas.

Buenas prácticas

• Es fundamental realizarlo antes de la planning. Con esto se logra poseer un entendimiento integral de la historia para construir las tareas.
• La historia debe cumplir el método (INVEST)
  I — Independent (independiente)
  N — Negotiable (negociable)
  V — Valuable (valiosa)
  E — Estimable (estimable)
  S — Small (pequeña)
  T — Testable (comprobable)
• Se deben realizar el desglose de historias en tareas y debe cumplir el método (SMART):
  S — Specific (Específico): Una tarea debe ser lo suficientemente específica para que todos puedan entenderla.
  M — Measurable (Medible): ¿Hace lo que se pretende? Es el equipo quien debe ponerse de acuerdo sobre lo que esto significa.
  A — Achievable (Alcanzable): ¿Es razonable la meta? Consejo: Es bueno establecer metas que representen un desafío, pero puede ser contraproducente no alcanzarlas.
  R — Relevant (Relevante): Cada tarea debe ser relevante, contribuyendo a la historia en cuestión.
  T — Time-Boxed (A tiempo): Una tarea debe estar limitada a una duración específica. No necesariamente debe ser una estimación formal en horas o días, pero debe haber una expectativa para que la gente sepa cuándo debe buscar ayuda.

Espero que estos consejos ayuden a hacer más eficientes tus ceremonias Scrum.

Conoce más sobre Trebol-IT aquí y síguenos en LinkedIn para más contenido de interés.