El Sprint Backlog consiste en una lista de historias y para cada una de ellas una simple lista de tareas que serán desarrolladas por el equipo para que al final de cada sprint podamos entregar incrementos funcionales de software.

La creación del Sprint Backlog sucede en la reunión de Planificación del Sprint con la participación de todo el equipo. Prestar atención a este proceso es clave para que el equipo tenga una mejor comprensión de lo que se debe hacer y planificar mejor el día a día del Sprint, pero muchos equipos todavía pecan a la hora de crear su lista de tareas, espero que estos consejos los puedan ayudar.

1. Implicar a todo el equipo en el proceso - Nunca está de mas repetir, la participación de todo el equipo en el proceso de descubrimiento del Sprint Backlog es crucial. En un equipo multidisciplinario todos pueden ayudar en las actividades en virtud de las distintas perspectivas que cada uno tiene sobre los temas a ser desarrollados, generando un Sprint Backlog mucho más rico que si sólo participan los desarrolladores o, simplemente, el gurú técnico, etc.

2. Discutir la forma en que la historia será implementado - La lista de historias es sólo uno de los resultados de la Planificación del Sprint , antes de escribir las historias en post-its y luego dividirlas en tareas, es necesario que el equipo realmente discuta la manera en que cada historia será definida. La mayor parte de la reunión debería dedicarse a la comprensión de la forma en que el equipo irá a abordar el problema, definir un diseño básico de la solución, verificar el código existente, analizar las posibilidades de la arquitectura y así sucesivamente. Esta comprensión general del problema y las posibles soluciones hará que las historias y tareas identificadas expresen realmente el trabajo por hacer.

3. Tener una definición de Terminado - Disponer de una "Definición de Terminado" disponible y visible para todo el mundo es muy, muy
importante, esta definición sirve como una guía de lo que se debe hacer, recordando a todos los criterios de aceptación general para
todos los temas del Product Backlog.

4. Identificar cualquier tipo de tarea - Muchos equipos se centran mucho en las tareas de codificación, pero sólo codificar no es suficiente para entregar software funcionando de verdad. Todos los tipos de tareas se deben incluir, las actividades de modelado, codificación, aprendizaje, tareas de base de datos, todos los tipos de pruebas posibles, etc. La "Definición Terminado" ayuda al equipo a pensar en los diversos aspectos del trabajo. Trabajando de esta manera, el equipo entenderá mucho mejor cual es la verdadera carga del Sprint.

5. Revisar el compromiso para el Sprint - Después de la identificación de las tareas, el equipo tendrá una mejor comprensión acerca del real esfuerzo necesario, en ese momento el compromiso del Sprint debe ser revisado. La seleccción del Product Backlog realmente cabe en el Sprint? en el caso que no, hay algunas alternativas. Las historias de menor prioridad pueden ser removidas o dividivas en pequeños temas, estudiar las técnicas de división Historias de Usuarios es muy útil en este caso. Lo importante es que ahora el equipo se pueda comprometer a realizar el alcance del Sprint.

6. No utilice tiempo de mas - Respete el time-box. Establezca el tiempo de la reunión y no lo pase, haga que el equipo se concentre y trabaje intensamente en el debate de los temas, así las historias y tareas serán descubiertas más fácilmente. No siempre el equipo puede
identificar todo aquello que se realizará durante el Sprint, pero esto no es un problema, la comprensión general es más importante.

7. Actualizar las tareas durante el Sprint - en el día a día del sprint el equipo tendrá una mejor comprensión acerca de cada tema que aún se está desarrollando, nuevas ideas pueden aparecer, viejas ideas pueden ser descartadas, el listado de tareas debe acompañar estos cambios. La Reunión Diaria es un excelente momento para crear nuevas tareas y desechar las tareas que son innecesarias.