Product Backlog Físico vs Product Backlog Virtual

Product Backlog Físico vs Product Backlog Virtual

Scrum no requiere de complejas plataformas ni software sofisticado. Todos conocemos la historia de amor entre Scrum y los postits. Y es que nos basta con una pared vacía, unos rotuladores y unos postits para poder aplicar un Scrum que haría emocionarse al mismísimo Jeff Sutherland.

Como ya sabrás, en Scrum el Product Backlog es una pila, es decir, una lista priorizada de ítems de diversa naturaleza (requisitos funcionales, requisitos técnicos, descripción de incidencias, etc).

Pues bien, a efectos prácticos ¿cómo representamos el Product Backlog? ¿cómo almacenamos esa información para que sea cómoda de manejar, comprensible y transparente a todos?

En este post haré una comparativa entre crear un Backlog físico y crear un Backlog virtual mediante alguna herramienta software.

Veamos.

Todo comienza con el Product Backlog

El Product Backlog es el reflejo en tiempo real de los requisitos priorizados del producto, tanto funcionales como técnicos, representados mediante ítems del Backlog (PBI- Product Backlog Items). Los ítems que están más arriba en la pila que conforma el Backlog tendrán mayor prioridad y estarán más detallados. Conforme vayamos bajando en la pila iremos perdiendo en prioridad y en detalle.

Lógico, por otra parte, la falta de detalle según perdemos prioridad, ya que no tiene sentido dedicar tiempo en detallar unos requisitos que, si alguna vez se abordan, es muy posible que hayan cambiado cuando llegue el momento de desarrollarlos.

En cambio, lo prioritario, lo inmediato, no nos queda más remedio que tenerlo claro como el agua para poder abordarlo con garantías de no desarrollar algo diferente a lo que realmente necesita el usuario.

Bien, pues si ya tienes claro qué es el Product Backlog y cuál es su estructura, entenderás que no necesitas de mucha parafernalia para construir uno. Una simple lista en un papel podría bastar, aunque sería la forma más cutre de hacerlo ya que cada ítem no sólo tiene una descripción, también presenta más campos tal y como pudimos ver en este post.

Veamos las dos posibles representaciones de un Product Backlog: Backlog físico y Backlog virtual.

Product Backlog Físico

Una forma más optima de tener nuestro Product Backlog, en vez de tenerlo todo en una lista en un papel, es tener un panel físico con tarjetas.

La ventaja de las tarjetas es que puedes reflejar en ella toda la información de un ítem:

Ítem del Backlog físico

Como puedes ver, en esta tarjeta tenemos la información básica de la historia de usuario: código identificativo de la historia, nombre (descripción corta), descripción (con sus respectivos criterios de aceptación) y estimación (en el ejemplo, 2 storypoints).

Podemos añadir más información, por ejemplo la épica a la que pertenece esta historia de usuario, pero en principio con estos campos de la tarjeta es más que suficiente.

Estas tarjetas las agruparíamos en un orden que determine su prioridad. Es decir, en una pared o un panel podemos pegar las tarjetas de forma que las más prioritarias estén más arriba. Y también agruparlas en épicas. Así de sencillo.

Ventajas de un Backlog físico

  • Permite unir a su alrededor a todo el equipo para discutir cualquier aspecto del Backlog, ayuda a hacer grupo y que al gente no se despiste.
  • Priorizar o despriorizar un ítem es fácil, basta con subirlo o bajarlo de la lista.
  • El hecho de que esté siempre presente en la pared de tu sala agile es muy visual y un recordatorio continuo de lo que se tiene entre manos.

Inconvenientes de un Backlog físico

  • Ocupa mucho espacio. Es muy fácil que un proyecto llegue a tener Backlogs de muchos ítems, de modo que tener en una pared una pila de más de 100 postits puede no resultar muy práctico.
  • No siempre los equipos disponen de una gran sala donde pegar sus cosas en las paredes o tener paneles. En muchos casos, cada miembro del Equipo Scrum tendrá un puesto dentro de la oficina, con su silla y su mesa, y no tendrá mucho espacio.
  • No puedes consultar o modificar el Backlog si no estás en tu sala agile.

Product Backlog Virtual

Siempre nos queda la alternativa de utilizar alguna herramienta software para almacenar el Backlog.

Podemos usar una herramienta genérica, como Excel, o una específica para proyectos ágiles, como por ejemplo Jira, Redmine, etc.

El Backlog recogido en Excel puede estar en una carpeta compartida de forma que, estés donde estés, siempre puedas consultar y modificar los ítems. Sin embargo, excel es muy poco atractiva desde el punto de vista gráfico. Al final tendrías una enorme excel llena de columnas (una por cada campo de los ítems) que, personalmente, no me parece lo más visual.

Sin embargo, tenemos herramientas software específicas para este tipos de contenidos…

Backlog en Jira

Jira es una de las herramientas más populares para la gestión de proyectos agile. No me enrollaré mucho ahora sobre cómo utilizar esta aplicación, otra vez será, así que me centraré sólo en cómo representar el Backlog con ella.

Este sería el aspecto de un Product Backlog en Jira:

Product Backlog virtual en Jira

Disculpa la censura (ya sabes, aquello de la confidencialidad). Sin embargo, como ejemplo me vale.

En el área lateral izquierda podemos seleccionar varias opciones relacionadas con nuestro proyecto. En este caso, tenemos seleccionado Backlog. Lo seleccionado es lo que aparece en el área central.

Como se puede observar, tenemos una lista de ítems, cada ítem en una fila. La etiqueta verde representa que es una historia de usuario y la azul una historia técnica.

¿Es normal que una historia de técnica tenga más prioridad que una historia de usuario? Perfectamente posible, aunque no siempre lo entienda el Product Owner ya que, para él, son las historias relacionadas con requisitos de negocio lo que importa y puede que se niegue a priorizar una historia técnica.

Así que habrá que hacerle entender, sobre todo por parte del Scrum Master, que si, por ejemplo, no disponemos de un sistema de Base de Datos, difícilmente podrá desarrollarse ninguna funcionalidad y que los requisitos de negocio no son nada sin una base técnica que los sustente.

Pero no nos desviemos del tema. En cada fila, por cada ítem, tendremos su código y nombre, entre otras cosas. Haciendo clic sobre un ítem podemos ver su contenido completo. Veamos una de las historias de usuario:

Ejemplo de Historia de Usuario en Jira

En esta pantalla (igualmente censurada 🙁 ) vemos la información que incluye la historia de usuario: tipo de ítem (que sería User Story o Historia de Usuario), descripción, documentos adjuntos (por ejemplo, pantallas del prototipo asociadas a esta historia), etc.

Si no estás familiarizado con Jira puede chocarte un poco de primeras, pero te aseguro que es bastante intuitivo y agradable de usar.

Ventajas de un Backlog virtual

  • No tienes que estar físicamente en la sala agile para ver tu Backlog, como ocurriría con un Backlog físico. Puedes consultarlo en tu ordenador dónde y cuando quieras.
  • Es muy sencillo modificar un PBI y moverlo dentro del Backlog.
  • Podemos asociar mucha información a ese PBI en su apartado de Attachment: capturas de pantalla (por ejemplo del prototipo navegable), documentos, emails, etc.
  • Jira permite obtener un gran número de estadísticas a partir de la información de tu Backlog.

Inconvenientes de un Backlog virtual

  • Quizá no es tan interactivo como un panel físico, cada miembro del equipo tiende a contemplarlo de forma individual y no de forma colaborativa con el resto del equipo.
  • Los ítems quemados desaparecen del Backlog (o mejor dicho, en Jira desaparecen de la vista Backlog aunque sí que puedes encontrarlos en la vista Issues), lo que resta transparencia al Backlog, pudiendo ocurrir que se creen nuevas historias de usuario modificando funcionalidades que ya se hicieron en el pasado y no ser conscientes de ello. Es fácil perderse en un maremágnum de historias de usuario…

Cómo gestionar un Product Backlog grande

Como acabo de indicar, no es nada raro terminar perdiéndote en tu Backlog cuando éste alcanza cierto tamaño. Es fácil perder el control sobre las historias de usuario y no tener claro qué requisitos de negocio finalmente prevalecieron.

Por experiencia, te puedo decir que en estos casos de despiste es fácil que el Product Owner termine creando nuevas historias de usuario con requisitos que contradicen funcionalidades de historias de usuario ya terminadas en pasados Sprints.

En proyectos Waterfall, donde todos los requisitos están quizá en un único documento de definición dividido en apartados, es más sencillo guiarse. Basta con irse al apartado donde se describe una determinada funcionalidad y punto, tienes claro al momento qué se pidió desde negocio y qué no se pidió.

Pero cuando la funcionalidad se disgrega entre diferentes historias desarrolladas, además durante diferentes Sprints, y encima (como ocurre con Jira) las historias terminadas desaparecen de la vista de Backlog, seguir el hilo ya no es tan fácil…

Se supone que el Product Owner debería saberse el Backlog al dedillo y tener presente todas las historias de usuario y que éstas no se contradigan entre sí. Pero el pobre es humano, y cuando ya vas por 100 historias es fácil cometer errores.

¿Qué hacer entonces? ¿cómo mantengo el control? ¿cómo evitar rehacer o redefinir trabajo ya terminado?

Un truco muy útil es asociar las historias de usuario a las pantallas del prototipo navegable.

Al final, el prototipo debe mostrar todas las pantallas del aplicativo, con sus botones, sus menús, sus desplegables, etc. Y cada uno de estos componentes muestra o realiza una acción asociada a una o varias historias de usuario.

Pues bien, plasma ese asociación entre componente e historia o historias de usuario. Algo parecido a esto:

Utilizar el prototipo para organizar las Historias de Usuario

Puedes imprimir todas las pantallas del prototipo, asociarle a cada componente su historia o historias correspondientes, y pegar las pantallas en la pared de tu sala agile. Es un truco muy simple pero útil para no perder la perspectiva de tu Product Backlog 😉 

Puede que haya historias de usuario que no se asocien a ninguna pantalla en particular porque recojan alguna funcionalidad cross, o de tipo batch, o semejante. Bueno, pues mala suerte, deberás tenerlas en cuenta aparte. Nadie dijo que este truco fuera infalible.

Reflexión final

La cuestión de qué tipo de Backlog usar, si un Backlog físico o un Backlog virtual, depende de cada equipo, de sus circunstancias y gustos personales, de modo que no se puede sentar cátedra al respecto.

Los agile más tradicionales se pirran por todo lo físico. He conocido algún que otro gurú del asunto tirarse una mañana entera de trabajo pegando en una pared lo que ya estaba recogido en Jira. A mí me pareció una mañana de trabajo perdida, pero él me insistía en la utilidad de su labor. Sea como fuere, una semana después estaba el Backlog virtual completamente cambiado y los posits de la pared desactualizados…

Sin embargo, es verdad que los paneles físicos tienen bastantes ventajas que ya he citado en el post.

Yo te diría que no seas dogmático y no consideres imprescindibles cuestiones que, en realidad, tienen poca importancia.

Adapta tu metodología a tus circunstancias y no al revés, y haz que tu esfuerzo esté siempre en consonancia con el beneficio que te reporte.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario