¿Puede/debe aceptar nuevo trabajo un equipo Scrum en medio de una iteración?

Uno de los motivos para definir un tiempo corto y limitado (entre 1 y 4 semanas) en las iteraciones de Scrum es permitir acotar suficientemente el alcance del producto a desarrollar durante esas pocas semanas buscando con ello una mayor facilidad de estimación, priorización, y sobre todo, permitir al equipo focalizarse en un objetivo concreto. De este modo, está prohibido incluir trabajo extra en el backlog si no fue incorporado en el Sprint Planning Meeting.

Probablemente ésta sea una de las cuestiones que los equipos que comienzan su transición de un desarrollo tradicional a uno ágil se les queda más grabada a fuego en clara competencia con aquella máxima de que "un equipo ágil NO documenta" (que proviene de una mala interpretación del Manifiesto Ágil).

Centrándonos en el tema de la aceptación o no de nuevo trabajo en medio de una iteración deberíamos detallarlos un poco más, puesto que, al igual que el tema de la documentación suele generar confusión.

Ciertamente un equipo Scrum se compromete a finalizar una cantidad de trabajo determinada al comienzo de la iteración y este compromiso ha de intentar mantenerse tanto por parte del equipo como por parte del Product Owner (PO), de modo que no son bienvenidos los "cambios de rumbo" en medio de una iteración. Si el PO pretende cambiar el alcance porque erró en la priorización al comienzo del Sprint (y, ojo, es una cuestión de fuerza mayor) la única forma viable de cambiar el foco del equipo es deshacer la iteración y comenzar con un nuevo Sprint Planning Meeting para arrancar una nueva iteración (opción poco utilizada, por cierto, puesto que deja al descubierto un error por parte de negocio, es habitual en entornos pseudo-ágiles que el PO acceder al equipo para cambiar especificaciones después de iniciada la iteración).

Ahora bien, habitualmente nos encontramos en equipos que inician su transición al desarrollo ágil con el rechazo (injustificado) a añadir trabajo a la iteración proveniente de las pruebas realizadas durante la iteración. La justificación es que esas tareas no formaban parte del sprint backlog por lo que no pueden entrar en la iteración actual y deben esperar a la siguiente iteración. Esto implicaría que ninguna de las historias de usuario que se han desarrollado se pueden dar por finalizadas, puesto que no deberían cumplir la definición de DONE, y por tanto, la velocidad de dicha iteración sería cero.

En equipos más maduros sí es habitual (con respecto al testing) posponer a la siguiente iteración la automatización de parte de las pruebas realizadas durante la iteración en curso: un subconjunto que se considera de mayor interés automatizar y que al haber realizado ya su validación manual nos será más fácil estimar el esfuerzo (y retorno) que nos supondrá su automatización.

Otro error clásico es NO permitir añadir trabajo cuando debido a un error en la estimación o cualquier otro motivo se han finalizado antes de tiempo todas las historias de usuario de la presente iteración. En este caso es conveniente evitar dejarnos llevar por la Ley de Parkinson (recuerda que ya hablamos de Parkinson y otras "Leyes" en  Project Management... algunas "Leyes" a recordar) e intentar que el trabajo se expanda hasta ocupar por completo la iteración, en este caso se debe acordar con el PO la inclusión de alguna historia de usuario que tenga probabilidad de finalizar en el tiempo restante de la iteración.