La gestión de alcance de un Sprint tiene un procedimiento similar al de gestionar el alcance de un proyecto. Es decir, antes de iniciar el Sprint debería existir coherencia entre el esfuerzo asociado al trabajo que se hará en el Sprint respecto de la Capacidad del equipo para abordar dicho trabajo durante el Sprint. Tal como se explica en ¿Cómo gestionar el alcance de un proyecto? las tres alternativas para calcular dicha coherencia son: "Al ojo", usando Puntos, o usando Horas Ideales. Las tres alternativas pueden ser igual de efectivas, además como la duración de los Sprint es corta, la alternativa elegida se puede evaluar periódicamente y si es necesario se podría cambiar.


Una cuestión importante antes de trabajar con Sprints es acordar el grado de preparación que deberían tener las UT cuando se inicie el Sprint. En Organización del trabajo con Worki se comenta que los Sprints pueden ser flexibles en cuanto a duración y/o a contenido (sus UT). Otro aspecto de la flexibilidad puede ser el grado de preparación con el cual empiezan las UT en un Sprint. Con preparación nos referimos a la especificación o definición suficientemente detallada del trabajo que conllevará cada UT. Obviamente, si durante el mismo Sprint se va definiendo el trabajo de una UT es más probable encontrarse con sorpresas y descubrir que la UT es más grande y/o compleja de lo que se había supuesto, esto podría llevar a no alcanzar a terminar UT en un Sprint, o a tener que aumentar su duración para terminar alguna UT. Así pues, mientras más rígidos se quiera ser con la duración de los Sprints más importante será que la mayoría o todas las UT de un Sprint estén preparadas antes de ser ejecutadas en el Sprint.  


Veamos ahora un ejemplo de cómo preparar y ejecutar Sprints en Worki. Usaremos Horas Ideales para gestionar el alcance del Sprint, pero alternativamente podríamos usar Puntos. A continuación, se muestran los elementos definidos en Elementos del sitio.


En nuestro ejemplo, existe una Línea de trabajo llamada TotalCombat y tenemos definida para ella el Sprint 1 como se muestra a continuación. Es un Sprint de 3 semanas de duración.


 


Por otra parte, para el desarrollo de TotalCombat utilizaremos el workflow "WF Desarrollo usando Sprints" cuya definición se muestra a continuación. La única actividad que se ha marcado como "Estimable" es Programar. Con lo cual, aunque podríamos estimar todas las actividades, Worki considerará solo la actividad Programar para hacer los cálculos de estimaciones y de progreso del trabajo, y solo advertirá cuando esta estimación falte en una UT.



Toda UT tiene en general un trabajo asociado a su preparación y otro a su ejecución. La preparación incluye la definición del trabajo que debe realizarse, su estimación y cualquier otra tarea antes de comenzar efectivamente a ejecutar el trabajo definido. En la ejecución además del trabajo de implementación de la UT también se realiza el trabajo de pruebas. Así pues, en todo workflow se pueden identificar dos grupos de actividades/estados, un primer grupo de preparación y otro de ejecución. Cuando se trabaja con Sprints es recomendable incluir una actividad/estado específico que separe dichos dos grupos de actividades de forma que las UT preparadas para ejecutarse en un Sprint no pasen a actividades de ejecución hasta que el Sprint no comience. En el workflow de nuestro ejemplo, dicha actividad de separación se llama "Esperar incluir en Sprint". Por otra parte, una vez que se disponga de una especificación suficientemente detallada de la UT, debería revisarse la estimación preliminar que se hizo de ella pues podría necesitar algún ajuste.

 

A continuación, vemos que en el Backlog de TotalCombat se han identificado 27 UT y ya han sido priorizadas.  



El total de las 27 UT en el Backlog han sumado 839 Horas Ideales de Programación. Si nuestro equipo tiene una Capacidad de 120 Horas Ideales de Programación al mes, proporcionalmente tendría alrededor de 90 en un Sprint de 3 semanas. Según esto, se podrían incluir en el Sprint 1 las tres primeras UT que suman 70 Horas Ideales de Programación, dejando para más adelante la UT "Pérdida de movilidad del personaje" (que tiene una estimación de 60 Horas Ideales de Programación) porque la suma total de esfuerzo estimado sobrepasaría demasiado las 90 horas indicadas antes.


En estos casos, conseguir un resultado de Sprint más completo (con más UT) se puede hacer una negociación en dos niveles, primero negociar intercambio de UT que entrarían o se quitarían del Sprint, manteniendo más o menos el Orden establecido. Cuando se tiene un caso como el del ejemplo, donde las tres UT que podrían entrar al Sprint son grandes (Épicas) en esta primera negociación no conseguiría una solución de contenido de Sprint que sea satisfactoria para el cliente, pues al Product Owner probablemente le gustaría que el Sprint incluyera más funcionalidad. En el segundo nivel de negociación se intenta reducir el tamaño de las Épicas planteándolas con desarrollo incremental, es decir, dividir la UT original en una UT para una primera versión y otra UT para representar el resto del trabajo por hacer, así podemos incluir en el Sprint una primera versión acotada de la Épica y dejar en el Backlog el resto de la Épica para que compita en el siguiente Sprint. Supongamos que se convierte la UT "Pérdida de movilidad del personaje" en dos UT; "Pérdida de movilidad del personaje - primera versión" y a otra UT "Pérdida de movilidad del personaje - resto", la primera con 10 Horas Ideales de Programación y la segunda con 20. Así mantenemos como candidata en el Sprint 1 a la primera de estas UT. Obviamente esto debe ser acordado con el Producto Owner. Por otra parte, podríamos hacer algo similar con la UT "Premiso especiales", es decir, convertirla en dos UT, por ejemplo una llamada "Premios especiales de puntaje" con una estimación de 40 Horas Ideales de Programación estimadas y "Otros tipos de premios especiales" con 20 Horas Ideales de Programación estimadas. Así, el Backlog quedaría como se muestra a continuación.



De esta forma ya tendríamos un conjunto de UT, más satisfactorio para el Product Owner como contenido del Sprint 1 y coherente con la Capacidad del equipo (90 Horas Ideales de Programación para un Sprint de 3 semanas). A continuación, estas 4 UT candidatas se pasarían (según nuestro workflow de ejemplo) a Especificar Requisitos y se les asignaría de momento el Sprint 1. La siguiente imagen ilustra estos movimientos en estas 4 UT. Nótese que en Worki cuando una UT se mueve desde el Backlog a un Sprint, o entre Sprints, pierde su valor de Orden. Esto se hace para remarcar las UT que acaban de llegar a un contenedor respecto de las que ya estaban. Una vez puestas la UT en un Sprint el Orden de ejecución lo decide el equipo, el Producto Owner asumirá que todo lo que se ha incluido en el Sprint se hará, sin importarle el Orden. Eso sí, puede que el equipo, conociendo qué es lo más importante para el Product Owner (el "Goal" del Sprint), pueda priorizar esas UT para evitar que puedan quedar postergadas y no terminarse en el Sprint.  El equipo podría también considerar dependencias o relaciones en general entre las UT del Sprint, y según esto establecer un Orden de ejecución dentro del Sprint.




Siguiendo el workflow, una vez finalizada la especificación de requisitos las UT irían llegando al estado "Esperar incluir en Sprint". Lo ideal sería tener suficientes UT preparadas para comenzar el Sprint. En un caso menos deseable podríamos arrancar el Sprint con alguna UT preparada y empezar a ejecutarla mientras dentro del mismo Sprint se terminan de preparar las UT restantes. Pero como ya hemos indicado esto tiene sentido si queremos o asumimos que nuestros Sprints sean flexibles pues al preparar las UT dentro del Sprint podemos llevarnos sorpresas respecto de su estimación.


Al arrancar el Sprint 1, y según nuestro workflow del ejemplo, todas las UT del Sprint 1 deberían estar en la actividad Programar. La siguiente imagen muestra un determinado momento del Sprint 1.




Nótese que en el tablero kanban y filtrando por el Sprint 1 de la Línea de trabajo TotalCombat solo se muestran 3 UT. Hay que remarcar que cuando una UT se termina ya no se muestra en el tablero kanban, el cual solo mostrará el trabajo NO terminado en el cual participa el usuario. Si queremos ver todas las UT del Sprint podemos hacerlo accediendo a la opción Buscar UT y filtrando por Línea de trabajo y Sprint, como se muestra a continuación.


 


En el resultado de la búsqueda se obtienen las 4 UT y se ve que la UT "Índice de daño" ya está terminada.


Cuando se trabaja con Sprints, y la Línea de trabajo tiene trabajo pendiente, lo normal (si dicha Línea de trabajo está entre las prioritarias) es que los Sprints sean consecutivos, es decir, apenas termina uno se comience el siguiente, y ojalá esto se haga siguiendo el proceso de reuniones recomendado por Scrum, que es el siguiente: al finalizar un Sprint inmediatamente se hace la reunión de revisión con el Producto Owner, a continuación la reunión de retrospectiva del equipo e inmediatamente después la reunión de planificación del siguiente Sprint con el Product Owner. Scrum sugiere que, en la reunión de planificación del Sprint, justo antes de comenzarlo, se prepare todo el trabajo del Sprint, es decir, que se concentre en ese momento la definición y estimación de todo el trabajo que se incluirá en el Sprint. Esta estrategia tiene la ventaja que el equipo durante el Sprint solo está concentrado en ejecutar el trabajo del Sprint, es decir, no se distrae en la preparación de trabajo para el siguiente Sprint. Pero como contraparte, si las UT que deben prepararse son Épicas o tienen alta complejidad, al concentrar todo el trabajo de preparación en la reunión de planificación puede que no haya tiempo suficiente para preparar todo el trabajo del Sprint. En TUNE-UP Process se recomienda una estrategia intermedia, que consiste en empezar a preparar el siguiente Sprint una vez que el Sprint actual se vaya extinguiendo, es decir, en los últimos días del Sprint actual. De esta forma los integrantes del equipo que ya no encuentren trabajo en el Sprint actual pueden trabajar en la preparación del siguiente Sprint. Así pues, es ese momento se repetiría el proceso de preparación y se procuraría tener suficientes UT preparadas para poder comenzar el Sprint siguiente una vez se termine el actual. De esta forma la reunión de planificación con el Product Owner consistiría simplemente en confirmar las UT que se incluirán en el siguiente Sprint, su preparación ya estaría hecha de antemano.    


Durante un Sprint lo normal es que no se añadan nuevas UT, a menos que estemos considerando Sprint muy flexibles. Sin embargo, sí que podría ser más común que se detecte que alguna UT ha sido subestimada (o sobre-estimada, aunque esto es menos frecuente). También podría suceder que alguna circunstancia haga que la Capacidad del equipo baje, por ejemplo, por no disponer de algún miembro del equipo que debía participar en el Sprint. Estos cambios en el esfuerzo asociado o de Capacidad del equipo, si son significativos, deberían llevar al equipo a re-negociar el alcance del Sprint (si se quieren mantener las fechas de término del Sprint). En este caso de re-negociación se utilizarían las mismas funcionalidades de Worki que ya hemos visto para volver a tener una consistencia entre el esfuerzo restante necesario para terminar las UT del Sprint y la Capacidad del equipo para el tiempo que queda antes de la fecha de término del Sprint.