Imagínese este escenario: usted está en la calle, observando la ciudad delante de usted. Las construcciones, coches, personas y otros elementos se distribuyen desde donde usted se encuentra hasta el horizonte distante. Para describir lo que está viendo, ¿qué nivel de detalle puede utilizar en esta descripción? Ahora imagine su próximo trabajo de desarrollo de software. Al planificarlo, desde su inicio hasta, digamos, dentro de seis meses, ¿qué nivel de detalle puede utilizar en ese plan?
En la ciudad, al mirar lo que está más cerca de usted, es posible describir lo que ve con un excelente nivel de detalle. Pero, a medida que mira hacia más lejos, los detalles que puede utilizar en esta descripción van gradualmente disminuyendo. Si intenta describir entonces lo que se encuentra más alejado con un elevado nivel de detalle, al caminar hacia el horizonte, verá que su descripción no se corresponde completamente con la realidad. En realidad, mientras más lejos mire, más incorrecta será su descripción si esta es detallada.
Una planificación tradicional trata generalmente de describir detalladamente lo que se hará durante todo el proyecto o, al menos, todo el trabajo hasta la próxima entrega, por ejemplo. Es muy común ver estos planes descritos en gráficos de Gantt, que muestran tareas pequeñas y asignación de "recursos" en el tiempo. Esta práctica puede compararse con la de describir detalladamente todo el camino, desde lo que está más cerca de usted hasta lo que está allí en la línea del horizonte, por lo tanto con mucho más detalle de lo que es posible. El resultado de esta práctica es un plan con una posibilidad mínima de acierto. ¿Y para qué sirve un plan así?
En una planificación Ágil, utilizamos solo el nivel de detalle que podemos “ver”. Para planear un trabajo que debe realizarse para el siguiente día, por ejemplo, podemos utilizar un nivel de detalle bastante elevado; es decir, cada pequeña tarea que va a realizarse. Para las próximas dos semanas —por ejemplo, un ciclo de desarrollo— podemos utilizar un nivel de detalle razonablemente elevado todavía, aunque menos que solo para un día. Si prevemos una entrega que tendrá lugar en un plazo de dos meses o incluso el año completo del proyecto, la cantidad de detalles disminuye mientras más lejos miremos en el tiempo, de forma que podrán utilizarse poquísimos detalles para prever lo se halla más lejos.
La lista de necesidades de negocios de Scrum, denominada Product Backlog, refleja esta planificación Ágil. La parte superior del Product Backlog posee elementos con una granularidad más fina, es decir, elementos menores y que representan más detalles. Al mirar más abajo en el Product Backlog, vemos que los elementos son cada vez mayores y menos detallados. A medida que el proyecto avanza en el tiempo, los elementos del Product Backlog deben perfilarse continuamente cada vez con más detalle, reflejando solo aquello que conseguimos “ver” en cada momento.
