Las reglas de Scrum (I): El Sprint Planning Meeting
Ya he comentado en este blog que Scrum es una metodología ágil que me gusta especialmente, y que uno de los motivos por los que me gusta es porque tiene reglas claras. Creo que una buena aproximación para conocer Scrum es conocer sus reglas y por eso he decido traducirlas al castellano. La fuente de estas reglas es el libro Agile Project Management with Scrum de Ken Schwaber.
El Sprint planinng meeting es una reunión que tiene una duración fija de no más de 8 horas, divididas en dos partes iguales de 4 horas. La primera parte sirve para seleccionar el Product Backlog y la segunda para preparar el Sprint Backlog.
- Los asistentes son el ScrumMaster, el Product Owner y el Equipo. Otras partes pueden ser invitadas por cualquiera de los anteriores para proporcional información adicional sobre el dominio del negocio o la tecnología, pero saldrán una vez proporcionen esta información. No hay gallinas como observadores.
- El Product Owner debe preparar el Producto Backlog antes de la reunión. En ausencia del Product Owner o del Product Backlog, el ScrumMaster debe construir un Product Backlog antes de la reunión y sustituir al Producto Owner.
- El objetivo de la primera parte, o las primeras 4 horas, es que el Equipo seleccione aquellos elementos del Product Backlog que cree que puede comprometerse a transformar en un incremento de funcionalidad potencialmente entregable. El Equipo demostrará esta funcionalidad al Product Owner y a los stakeholders en el Sprint review meeting al final del Sprint.
- El Equipo puede hacer sugerencias, pero la decisión de que elementos del Product Backlog pueden formar parte del Sprint es responsabilidad del Producto Owner.
- El Equipo es responsable de determinar que parte del Product Backlog, seleccionado por el Product Owner para ese Sprint, va a tratar de implementar durante ese Sprint.
- Limitar el tiempo para la primera parte a 4 horas significa que este es todo el tiempo disponible para analizar el Product Backlog. Un análisis más profundo debe ser realizado durante el Sprint. El Producto Backlog de alta granularidad y alto nivel puede no ser entendido con suficiente profundidad durante esta parte del Sprint planning meeting, lo que puede tener como consecuencia que el equipo no sea capaz de completar todos los elementos que seleccione del Product Backlog.
- La segunda parte del Sprint Planning Meeting ocurre inmediatamente después de la segunda y también durará como máximo 4 horas.
- El Producto Owner debe estar disponible para el Equipo durante la segunda parte para responder aquellas preguntas que el Equipo pueda tener acerca del Product Backlog.
- Es labor del Equipo actuar solamente en su propio nombre y sin ninguna dirección externa al mismo, para encontrar durante esta segunda parte como transformar la parte seleccionada del Product Backlog en un incremento de funcionalidad potencialmente entregable. Nadie más tiene permiso para hacer nada que no sea observar o preguntar para buscar más información.
- El resultado de la segunda parte del Sprint planning meeting es una lista, llamada Sprint Backlog, de tareas, estimaciones de tareas y asignaciones que dará comienzo al trabajo del Equipo para desarrollar la funcionalidad. La lista de tareas puede no ser completa, pero debe ser suficientemente completa para reflejar el compromiso mutuo por parte de todos los miembros del Equipo y guiarles durante la primera parte del Sprint, durante la cual el Equipo puede encontrar más tareas a añadir en el Sprint Backlog.
He decidido dejar en inglés algunos términos centrales de la metodología porque lo habitual es citarlos en inglés (o al menos en spanglish). Las partes directamente traducidas, aparecen en cursiva. Lo que busco con esta traducción es para que os animéis a comentar estas reglas: si creeís que son buena idea, si veis posible llevarlas a la relalidad, si ya usaís alguna parecida en vuestra metodología actual etc... Me gustaría que se generase un poco de debate sobre Scrum, en definitiva.