La Planificación Inicial en SCRUM

Una de las primeras actividades dentro del proceso Scrum es la Planificación Inicial y vale la pena tomarse un tiempo extra para comprender la importancia de esta reunión, ya que es el punto de partida del proyecto y cuanto más completa y bien ejecutada esté, menos serán los cambios en las iteraciones.
La Planificación Inicial comprede dos etapas:
La Primera. Los usuarios dirigidos por el Product Owner definen su lista de necesidades o requerimientos, esto lo hacen de manera conjunta en una reunión, donde usando la técnica de lluvia de ideas hacen una lista de requerimientos funcionales que deberá satisfacer el sistema o software, esta lista viene a conformar un primer borrador del Product Backlog, esta lista no requiere ningún orden en particular, es simplemente una "lista de las cosas que los usuarios quieren que el sistema haga".
La Segunda. Con la lista preliminar se reunen el Product Owner, el Scrum Master y el equipo (Team), también pueden estar los usuarios pero estos pueden ser muchos por lo que no es muy necesario, lo importante es que el Product Owner tenga un buen conocimiento de las necesidades y de los procesos que se quieren en el producto. Entonces, las personas reunidas analizan cada uno de los requerimientos de la lista y fundamentalmente clarifican cada uno de ellos, viendo de que un requerimiento no sea muy genérico y sea más conveniente dividirlo en dos o más requerimientos más específicos o también lo contrario, viendo que un requerimiento no esté ya contenido en otro, por lo tanto se lo une.
También es importante aclarar la terminología usada por el usuario, no nos olvidemos que el usuario puede tener su propia terminología técnica y conviene a todo el equipo saber cuales son.
Una vez que todos los querimientos están definidos, nosotros como Team o como Scrum Master debemos sugerir algunas funcionalidades que son posibles de incorporar a las necesidad identificadas por los usuarios, ya que nuestra visión y conocimiento de lo que puede hacerse en una computadora es mayor a la que pueda tener el usuario.
Con esta lista actualizada que simplemente tiene un número correlativo de requerimiento y la descripción del requerimiento, el equipo (team) de desarrollo hace las estimaciones de esfuerzo en días de cada requerimiento funcional, este dato se coloca en una columna a la derecha de la lista. Luego, conjuntamente el Product Owner se define la prioridad de cada requerimiento desde la perspectiva del usuario, en otras palabras respondemos a la pregunta ¿Qué quiere el usuario que se desarrolle primero? y vamos colocando en una columna adicional en la lista un número correlativo de prioridad a cada requerimiento.
Esta nueva lista ya es casi el Product Backlog final, solo tenemos que ordenarlo según la columna de prioridad. Una vez que tengamos la lista ordenada se van agrupando los requerimientos en bloques de más o menos 30 días, de acuerdo a la columna de Estimación de esfuerzo. Esto lo que nos permite es definir los Sprints o Iteraciones, no nos olvidemos que cada sprint se recomienda que no pase de 30 días de trabajo.
La agrupación de los requerimientos  en Sprints nos permitirá determinar el número de iteraciones para desarrollar todo el proyecto. Acá el buen criterio es importante, el método sugiere que no pase el sprint de 30 días, pero lo más importante es que definamos QUÉ queremos que el usuario tengo como producto (Incremento) para poder estar usando desde la primera iteración o sprint, por lo tanto un sprint puede tener cualquier día menor a 30, lo importante es que se tenga un producto usable lo más pronto posible.
La lista que obtenemos de todo esto es el Product Backlog, esto lo veremos en más detalle en otra entrada.