Está en la página 1de 3

El Backlog del producto

El resultado de la seleccin de requisitos candidatos es una lista


de los requisitos priorizados y estimados que se tendrn en cuenta
para el proyecto. Scrum, uno de los mtodos giles ms populares, da
el nombre de backlog de producto a esta lista.
El backlog es una lista priorizada de trabajo pendiente para
finalizar el proyecto de desarrollo.
El contenido ms habitual de un backlog son los requisitos
funcionales. Habitualmente, en los proyectos giles, estos
requisitos se documentan en forma de historia de usuario; pero
tambin se pueden documentar en forma de caso de uso o utilizando
cualquier otra tcnica de documentacin de requisitos funcionales.
Adems, un backlog tiene que incluir los requisitos no funcionales
y, en general, cualquier otra tarea necesaria para finalizar el
proyecto, como por ejemplo, tareas de preparacin del entorno, tareas
de lanzamiento, etc.
Se denomina entrada de backlog a cada uno de los elementos que
forman un backlog de producto, ya sean historias de usuario, casos
de uso, otros requisitos funcionales o no funcionales o tareas que
se deban hacer.
De hecho, no es necesario que todas las entradas del backlog sean
homogneas. Se puede tener un backlog donde se describen los
requisitos funcionales como historias de usuario y donde tambin se
describe un requisito de usabilidad, por ejemplo, mediante un pequeo
esbozo a mano alzada de las pantallas.
Ciertos especialistas en el tema establecen que, adems de estar
estimado y priorizado, un buen backlog tiene que tener las cualidades
de estar detallado apropiadamente y de ser emergente.
Un backlog est priorizado, habitualmente, porque las entradas que
contiene se ordenan de ms a menos prioridad. En algunos casos, sin
embargo, puede ser til etiquetar cada entrada con un nmero o
descripcin que indique la prioridad.
Un backlog est estimado porque todas las entradas estn estimadas
de tal modo que, para cada una, se tiene una estimacin del costo de
desarrollo que aquella entrada implica. Un backlog est detallado
apropiadamente cuando usa niveles de detalle diferentes para las
entradas que contiene (y el nivel de detalle es el adecuado para

cada entrada). Un backlog es emergente porque puede evolucionar a


medida que cambia el conocimiento que se tiene sobre las necesidades
de los stakeholders y las tareas que hay que hacer en cada momento.

El backlog y otros documentos de requisitos


El uso de un backlog no excluye al equipo de desarrollo de usar
cualquier otro documento de requisitos complementario que considere
necesario. As, adems del backlog, un equipo puede usar un modelo
del dominio en forma de diagrama de clases UML, esbozos de las
pantallas a mano alzada, mapas navegacionales para interacciones
elaboradas entre el usuario y el sistema en forma de diagramas de
estados UML, o cualquier otro artefacto que sea til para comunicar
requisitos.

Los cambios en el backlog


Cuando los requisitos cambien, habr que aadir, modificar o eliminar
entradas del backlog para reflejar estos cambios. As, cuando se
descubran nuevos requisitos habr que aadirlos como entradas en el
backlog (estimndolos y priorizndolos). Si un requisito cambia,
puede ser necesario reestimarlo o repriorizarlo. Finalmente, se
puede descubrir que un antiguo requisito deja de serlo y habr que
eliminar la entrada de backlog pertinente.
Por todos estos motivos es importante dedicar cierto tiempo en cada
iteracin a revisar y mantener el backlog, aadiendo, quitando o
modificando las entradas que haga falta a medida que los diferentes
factores de cambio (sean internos o externos) provoque cambios en
los requisitos o en la estimacin de su costo o valor. Adems, el
backlog tiene que reflejar el trabajo hecho hasta la fecha en el
desarrollo. Si una entrada de backlog ha sido ya desarrollada y
verificada, se eliminar del backlog e, inmediatamente, la siguiente
entrada ms prioritaria pasar a ocupar su lugar.
As, a medida que se completan entradas, las que eran menos
prioritarias van ganando prioridad relativa, en el sentido de que
van avanzando hacia arriba en la lista y pasan a ocupar las primeras
posiciones. Por otro lado, tambin se dice que el backlog tiene que
estar detallado apropiadamente. La finalidad de esto es no dedicar
esfuerzos a las entradas que tienen ms probabilidades de sufrir
cambios (las menos prioritarias, que son las que estn ms lejanas
en el tiempo).

As, las entradas ms prioritarias tienen que ser requisitos con


objetivos de ms bajo nivel, de granularidad ms fina. Estas son
entradas que se tendrn en cuenta antes. A medida que tienen menos
prioridad, las entradas tienen que tener niveles de objetivo ms
generales, tienen que tener una granularidad ms gruesa.
Se dice que el backlog tiene que tener forma de iceberg, donde la
parte de arriba contiene las entradas sobre las que se est
trabajando actualmente, pequeas, de granularidad muy fina, y la
parte de abajo, a medida que se aleja de la punta, contiene entradas
de granularidad cada vez ms gruesa, con menos nivel de detalle y,
por lo tanto, ms grandes.

El objetivo de esta manera de detallar el backlog es no destinar


demasiado tiempo a detallar unas entradas de backlog que an no se
usarn porque no son suficientemente prioritarias. A medida que se
van consumiendo entradas de backlog, se van descomponiendo, y
detallando cada vez solo las entradas ms prioritarias que quedan en
el backlog.