Ese Backlog priorizado es el punto de partida para el trabajo de planificación.

La reunión
tiene que terminar con unos objetivos claros: conseguir la lista de historias a la que se
compromete el equipo a realizar, o Sprint Backlog; un propósito global y claro para el Sprint
que sugiere el Product Owner; el compromiso firme del equipo para realizar las historias que
ha seleccionado; la estimación que hace el equipo de la complejidad o esfuerzo preciso para
desarrollar cada una de las historias, lo que además da la velocidad o capacidad total de
trabajo del Sprint; y que todos los miembros del equipo entiendan el contenido y alcance de
cada una de las historias que propone el PO.
El Sprint Planning se divide a su vez en dos etapas. En la primera, con el concurso del
Product Owner, se revisa cada historia del Product Backlog siguiendo el orden de la
priorización. El PO las explica, detalla los criterios de aceptación que servirán para validar el
trabajo realizado y atiende a las preguntas, dudas y aclaraciones que plantee el equipo. Para
cada una de esas historias de usuario, el equipo hará una estimación, lo que servirá para
delimitar el alcance del Sprint una vez se conoce cuál es la velocidad o capacidad habitual
del equipo.
Esta estimación la hace el equipo usando algunos de los muchos sistemas ideados para
ello. La estimación se valorará como esfuerzo necesario para realizar cada historia de
acuerdo con el equipo. Una técnica muy habitual es la llamada Planning Poker, en la que se
usan unas cartas marcadas con números para que se asigne una valoración a cada historia
partiendo de lo que cada miembro del equipo vote usando su criterio y obteniendo el valor
final como una valoración media, un compromiso entre todos, o cualquier otro criterio
establecido de previo acuerdo.
Un elemento muy importante de cada historia de usuario es el criterio de aceptación que
define qué es lo que permite determinar si la historia se ha completado o no.
Cuando se ha alcanzado un número suficiente de historias como para ocupar el trabajo del
equipo durante el Sprint, se procede a su división en partes más manejables o tareas. Este
trabajo lo hace el equipo de forma autónoma y permitirá desmenuzar cada historia en un
conjunto de tareas más manejables y expresadas en el lenguaje del dominio de trabajo
(arquitectura, desarrollo software, marketing o el que aplique en cada caso). El equipo
incluirá para cada tarea una definición de completitud, definición de hecho o Definition of
Done, que es más concreta y describe los criterios que permitirán determinar desde un punto
de vista técnico si se han completado o no.
El conjunto de historias de usuario y las tareas en las que se dividen conforman el Sprint
Backlog, la definición del trabajo que se va a desarrollar durante la iteración o Sprint.

Daily Meeting o Scrum diario

Una vez arranca el trabajo, la mecánica es simple y repetitiva: cada miembro del equipo
selecciona la siguiente tarea que va a abordar de acuerdo con el resto de los miembros (para