Para muchos equipos que empiezan a implantar agilidad, son bastante comunes las dudas sobre cuándo se debería estimar. La teoría dice que en Scrum hay una reunión, el llamado Sprint Planning, a la que se llega con las historias de usuario (los requisitos), se estiman y se sale de ella con qué se va a desarrollar en el Sprint.
Pero en ocasiones, el anterior esquema tiene algunos problemas, principalmente, que a veces el tiempo del Sprint Planning se hace muy corto y, por otro lado, que esta estrategia deja poco margen de maniobra al Product Owner para reflexionar sobre la mejor manera de ordenar el Product Backlog y con ello las prioridades.
Para solucionar estos problemas, es muy típico hacer uso de la llamada “Reunión de refinamiento del product Backlog” (o Backlog Refinement Meeting, también antes llamada Scrum Backlog Grooming, nombre este último lo suficientemente feo como para no volver a usarlo). Así que esta no es una reunión “oficial” en Scrum… pero es muy típico usarla.
Ken Schwaber, cofundador de Scrum, recomienda que los equipos Scrum dediquen al menos un 5% del tiempo que dura el Sprint a la “reunión de refinamiento del product Backlog”. En ella colabora todo el equipo (Scrum Master, equipo de desarrollo y Product Owner), es una reunión previa al Sprint Planning, muchos equipos la hacen justo a la mitad de un Sprint, y en ella se preparar el Product Backlog de cara al Sprint Planning.
Resumiendo, en la reunión de refinamiento del Product Backlog (Backlog Refinement Meeting) se prepara el próximo Sprint Planning, por ello se estiman algunos ítems del Product Backlog, se clarifican los requisitos y se descomponen los ítems en otros más pequeños cuando si fuese necesario.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Gracias Javier por el artículo. Aunque ha quedado claro, solo remarcar que uno de los fallos mas habituales de uso de esta reunión es para modificar el sprint actual y no planear el siguiente y eso no es bueno.
Aunque nunca se puede estar cerrado del todo a modificar un sprint en curso es muy mala señal si esto sucede con frecuencia ya que perdemos el ritmo y la posibilidad de ser mas previsibles.
Hola Israel,
Buen apunte, coincido totalmente, esta reunión no debe ser justificación para la replanificación (salvo causa mayor)
eso no es buena cosa
Saludos!
javier… Si un equipo novato estima mal la cantidad de HU que puede realziar en un Sprint y sobra tiempo de ese Sprint. Que debe hacer en el tiempo que sobra. Mas tareas? un refinamiento del Backlog? Que es lo mejor? Sabiendo obviamente que debe ser mas juicioso para estimar en el siguiente Sprint.
Hola,
Siempre debe «sobrar» tiempo, por aquello de que el ciclo es iterativo además de incremental, y debe dejarse tiempo explícito para refactoring, bugs imprevistos críticos, etc., Mira el patrón equipos que terminan antes aceleran más rápido.
Si ya sobra pero mucho decide el P OWner.
Y eso sólo debe pasar si hay un imprevisto grande o en los muy primeros Sprints, ya que la velocidad no está aún
A nosotros en 233 nunca nos ha pasado eso, en la vida, después de 90 Sprints 🙂
Saludos
Al contrario lo que casi siempre sucede es que no alcanza el tiempo estimado para terminar el sprint. Siempre aparecen requeriemintos nuevo o mwejoras por parte del PO y a veces los sprint se hacen interminables