Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Herramientas avanzadas para el Product Owner

2 comments
Herramientas avanzadas para el Product Owner

Más allá del Backlog de producto , en el cual el Product Owner debe hacer emerger las épicas y las historias de usuario del producto o servicio que está construyendo con el proyecto que tiene encomendado, hay una herramienta que puede ser de mucha utilidad tanto para el Product Owner, como para el equipo completo, e incluso para cualquier interviniente, sobre la cual leí por primera vez en el blog de Roman Pitchler , y es lo que llama el Backlog Board.

Sobre la base de ese concepto y ampliando más su enfoque, os traslado en este artículo un modelo ampliado del mismo y cuales son sus ventajas de cara al proyecto.

Es una herramienta poderosa que actua como radiador de información, irradiando hacia todo aquel que lo visualice una gran cantidad de información.

Pasemos a conocerlo un poco más en detalle:

¿Qué es un Backlog Board?.

  • Es un Lienzo o tablero ampliado que contempla un conjunto de aspectos clave para el desarrollo del producto más allá de las historias de usuario.

¿En qué se diferencia de un Backlog Tradicional? .

  • Incluye los requisitos no funcionales.
  • Proporciona una vista global del producto y todos los aspectos básicos del mismo. Visible y accesible.
  • Los backlogs son lineales. ( lista de características, mejoras , bugs).
  • Es más adecuado para un producto nuevo.

¿Qué aporta un Backlog Board?.

  • Reduce complejidad y aporta claridad.
  • Aporta una visión completa del producto.

¿Qué información podemos incluir?.

  • Area de Historias de usuario.
    • Zona para las historias que están Ready para el Sprint.
    • Zona para las historias que están siendo definidas por el PO y que serán objeto del siguiente Sprint.
    • Zona para resaltar las historias que están a la espera de obtener alguna definición por parte de algun usuario o interviniente.
  • Area de Restricciones. ( operacionales)
    • Se indican los aspectos operacionales del producto, o requisitos no funcionales que deben cumplirse para que el producto sea plenamente satisfactorio. ( rendimiento, robustez, seguridad…)
  • Area de Restricciones ( UX y Diseño.)
    • Se aportan los diseños de usabilidad y esquemas generales, scketches o mockups del proyecto.
  • Area de modelo.
    • Flujos de trabajo, Diagrama de clases ,elementos técnicos
    • Stackeholders clave y relaciones entre ellos. Interacciones de los Stackholders con las historias y epicas….

En la siguiente imagen, podéis ver un ejemplo de lo que os explicaba arriba.

Backlog Board

Ejemplo de un Backlog Board como radiador de información

Profundizando un poco más en su contenido, se puede observar que incluso podría ser considerado como un pre-backlog, pues en la zona de historias podemos definir un área para aquellas épicas o historias que han surgido como consecuencia del Feedback de una petición o recomendación, de una mejora solicitada por nuestros usuarios o clientes, etc, quedando en esta zona en tanto en cuanto se decide por parte del Product Owner la conveniencia o no de darle paso a un estudio más en profundidad pasándolas a la “zona Wait.”

Esta zona “Wait” puede servir tanto para lo anterior, como para irradiar información sobre las historias que están a la espera de algo: bien sea de ese estudio de oportunidad antes mencionado, o por estar a la espera de recibir más información por parte de alguien, antes de que sea arrastrada a la zona de “In progress”, la cual marcará que la historia está siendo estudiada o analizada por alguien.

Por su característica de radiador de información, cuanta más información pongamos en cada tarjeta de cada una de las zonas, será más visible y transparente. Así, por ejemplo, podemos colocar pequeños pos-it indicando ‘a quien estamos esperando’ para saltar de “Wait” a “In progress”, y desde que fecha se produce esa espera.

Toda esta información contribuirá a dar claridad y visibilidad al producto y el Product Owner, deberá basarse en ello para poder hacer mejor su trabajo.

Cuando la historia está ya lista para dar el salto a su siguiente etapa del camino, se pasaría a la zona  de “Ready”. Este camino de la historia es el que tendrá que recorrer hasta que haya sido planeada, estimada y descompuesta en tareas más pequeñas ya dentro de las habituales prácticas que realizan los equipos ágiles.

Por este motivo es por lo que considero esta herramienta como un poderoso pre-backlog.

Tan importante como las zonas de épicas e historias con sus estados, es la zona de restricciones y de modelo.

En la primera de ellas, vamos a colocar todos aquellos requisitos no funcionales que siendo sumamente importantes para la marcha del proyecto, no aparecen en otros radiadores de información habituales en los proyectos ágiles.  Las clasificamos como restricciones del proyecto que deben cumplirse o tenerse en cuenta en todo momento. Este es un buen sitio donde hacerlas emerger.

Las tarjetas de restricciones además, pueden esconder en su interior “secretos muy valiosos” , y no me extiendo más en ello porque lo vais a ver inmediatamente con estas tres imágenes a continuación.

Detalle de un backlog Board

Un ejemplo de tarjeta de restricciones en el Backlog Board

Dentro de la tarjeta, podemos incluir aquellas historias que están afectadas por dichos requerimientos en cuanto a rendimiento para que todo el equipo tenga presente y se haga palpable para todos a que afectan estas restricciones que normalmente en los proyectos son un tanto ambiguas.

Detalle BacklogBoard_2

En el interior de la tarjeta se incluye más información

Detalle BacklogBoard_3

Las historias de usuario afectadas por la restricción se incluyen aquí.

Por  último , en la zona de Modelo, podemos incluir cualquier diagrama que sea de utilidad para el proyecto, como por ejemplo un flujo de trabajo, un diagrama de componentes a alto nivel,etc. Y además en el apartado de Personas,  es de gran utilidad incluir las definiciones de nuestro público objetivo: sus necesidades, sus expectativas, que les mueve a usar el producto o servicio y cualquier otra información que nos ayude a tener siempre presente el foco de para quien estamos construyendo ese producto o servicio y asi tener siempre en mente sus necesidades.

Os animo a probarlo y a definir vuestros propios Backlog Board, y si algún valiente se anima y me envia su modelo, estaré encantado de publicarlo en este blog para compartirlo con toda la comunidad.

Hasta pronto.

  1. Jose Manuel Beas says:

    Hola Pepe,

    En el taller que tuve el placer de compartir con @ujue en la UXSP2013 usamos una adaptación de este tablón. En la práctica no lo he usado exactamente porque toda esa información suele estar un poco más dispersa e incluso en herramientas digitales (wikis, docs, hojas de cálculo…). Me cuesta transmitir el valor de visualizar y tener a mano lo que aporta valor. Dichoso síndrome de Diógenes de los managers. :(

    Pero bueno, basta de lamentos. Lo que quería aportar es que yo soy un fan absoluto de los User Story Maps (o versiones de esta técnica) que nos permiten tener un tablón organizado con todo el backlog y cómo queremos hacerlo crecer. Además, es ideal para hacer el refinamiento y tomar decisiones como “esto queda fuera del ámbito del proyecto”. Y todo ello con el valor que ofrece un radiador de información. 😉

    Un saludo,
    JMB

    • Pepe Vázquez says:

      Hola José Manuel. Gracias por comentar. Estas herramientas dan una tremenda visibilidad a un proyecto, pero no son fáciles de aplicar pues como dices, tenemos la tendencia a llevarlo de manera mecanizada en varios sitios dispersos y así se pierde esa visibilidad.Los managers deben creer en ello para que sea de verdadera utilidad y fomentar que las decisiones respecto al proyecto se tomen en equipo alrededor del tablero y poder revisitarlo a menudo para recordar porqué se tomó esta o aquella decisión, así como utilizarlo para que se comparta la visión de una manera gráfica.

Responder a Jose Manuel Beas Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*