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, ya que al momento de integrar es imposible lograr un entregable funcional.
Subestimar los bloqueos sea cuales sea 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 la consultoría de algunos expertos en algún área de conocimiento, para la asistencia al equipo de desarrollo. Debe el Scrum master velar por que 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.
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 mismo 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 invitados todo el equipo de desarrollo, el 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 prepara 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.
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.
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)
Specific (Específico): Una tarea debe ser lo suficientemente específica para que todos puedan entenderla.
Measurable (Medible): ¿Hace lo que se pretende? Es el equipo quien debe ponerse de acuerdo sobre lo que esto significa.
Achievable (Alcanzable): ¿Es razonable la meta? Consejo: Es bueno establecer metas que representen un desafío, pero puede ser contraproducente no alcanzarlas.
Relevant (Relevante): Cada tarea debe ser relevante, contribuyendo a la historia en cuestión.
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.
Por
Hugo R Piñango.
Lic. Informática
Magister en Gerencia de Proyectos (PMI)
Scrum Máster
DevOps (DEPC)
