Al principio de cada Sprint, durante el evento de planificación o Sprint Planning, el Equipo Scrum al completo se reúne para generar el Sprint Backlog.
El Equipo selecciona ítems de entre aquellos de mayor prioridad del Backlog hasta alcanzar un compromiso sobre cuántos ítems podrán ser completados durante el Sprint. El Equipo de Desarrollo acuerda con el Product Owner qué ítems se seleccionan, pues éste querrá incluir cuántos más mejor pero el Equipo de Desarrollo deberá basarse en la velocidad alcanzada durante los últimos Sprints para determinar cuántos ítems puede comprometerse a completar.
Desde mi experiencia y perspectiva recomiendo los puntos de historia pues miden complejidad, incertidumbre, esfuerzo y productividad. Este tipo de medida tiene un cierto grado de anticipación de imprevistos (téngase en cuenta la incertidumbre) mientras que las estimaciones en horas se basan más en la idea de que todo salga como hemos pensado, incluso los imprevistos, para los cuales provisionamos una bolsa de horas concreta.
Si estimamos cuántos ítems seleccionar en puntos de historia podemos elegirlos del Product Backlog rápidamente y pasar de inmediato a generar el plan de trabajo, mientras que si nos basamos en horas debemos ir generando el plan a medida que estimamos cuántas horas dedicaremos a cada tarea, por lo que no sabremos cuántas historias de usuario podemos elegir hasta haber terminado toda la planificación.
Además de seleccionar los elementos del Product Backlog el Equipo de Desarrollo elabora un plan para llevarlos a cabo. Dicho plan consiste en analizar uno a uno cada elemento seleccionado y dividirlo en tareas técnicas de forma que cada componente necesario para completar una historia de usuario pueda ser llevado a cabo por un desarrollador, favoreciendo así el trabajo en paralelo y la generación de subtareas más fácilmente abordables y de incertidumbre acotada.
Las historias de usuario se refieren al Equipo Scrum al completo y al cliente, es decir, deben ser concebidas para facilitar la comprensión y la comunicación entre perfiles heterogéneos. Por otro lado las tareas técnicas, o simplemente tareas, son cosa del Equipo de Desarrollo. Ellos suelen referirse siempre a ellas hasta el punto de asimilar las unas con las otras.
Una vez finalizado el análisis y la generación de tareas técnicas el equipo puede reordenarlas ignorando la prioridad dada a las historias de usuario, localizando dependencias entre tareas y colocando éstas asegurándose que las tareas dependientes se abordan siempre después de las que generan la dependencia. El Equipo también puede asignar tareas a miembros concretos del Equipo de Desarrollo para optimizar el proceso, aunque se debe ser cuidadoso y evitar la generación de islas de conocimiento asignando siempre a la misma persona todas las tareas similares.
Una vez empezado el Sprint, y a medida que el Equipo aprende más sobre el trabajo necesario para desarrollar las tareas, puede decidir añadir tareas técnicas al Sprint Backlog o refinar las existentes si lo considera necesario así como replantear su orden.
