Si lo desearas de verdad, podrías conocer la visión del corto y medio plazo de tus productos con una sola mirada.
Un product owner trabaja definiendo y priorizando un backlog de producto para que sea implementado por el equipo de desarrollo. Dentro de todos los items del backlog hay algunos más significativos para la empresa, por el valor e impacto que van a tener en el producto. Si cogemos todos estos proyectos más significativos de todos los productos, podemos visualizarlos en un mismo panel y tener así una big picture de lo más relevante que se está cocinando en nuestra empresa.
Product Owners Board
La estructura de este panel permite visualizar tanto la carga de trabajo de cada product owner, como en el equipo.
- To do alberga peticiones de negocio ordenadas por prioridad para que el PO empiece a hacer grooming de ellas.
- Grooming representa las peticiones que están siendo desgranadas por parte del product owner.
- Ready contiene las peticiones que están validadas por parte de los stakeholders y el equipo de desarrollo. Los proyectos están ordenados por prioridad para empezar su desarrollo.
- In progress muestra los proyectos que el equipo de desarrollo está implementando en este momento.
- Done tiene los últimos cambios que hemos incorporado al producto.
Trabajando con dos tipos de prioridad y WIP
El PO tiene un flujo de trabajo propio desde que recibe una petición de negocio hasta que ésta se incorpora en el producto del cliente. En este flujo hay dos tipos de prioridades a manejar:
- La prioridad de grooming, es aquella que el product owner debe decidir con los stakeholders respecto las peticiones en la columna To Do.
- La prioridad de desarrollo, es aquella que el product owner debe decidir con los stakeholders respecto las peticiones en la columna Ready, para planificar el Sprint Backlog del equipo de desarrollo.
Esta visión general, permite a los product owners y los stakeholders ver la carga de trabajo que hay en el lado del product owner y equipo de desarrollo, existe un work in grooming limit respecto el número de peticiones en grooming al mismo tiempo para un product owner, así como un work in progress limit a nivel de cuántos proyectos hay en fase de desarrollo en un mismo equipo.
Qué contiene y qué no contiene este panel
En algunos entornos, existen proyectos transversales que deben aplicarse a todos los productos de la empresa, por ejemplo, cambios en la arquitectura. Las personas que se encargan de este tipo de proyectos, consideran que su definition of done es cuando el cambio se ha aplicado en todos los productos. Este panel sirve de gran ayuda para visualizar aquellas necesidades que son comunes a todos los productos.
Las tareas técnicas que ayudan a mejorar la plataforma en la que desarrollamos así como el rendimiento de nuestros productos, entre otros aspectos no funcionales, restarán tiempo dedicado al negocio puro y los stakeholders lo deben conocer.
Cuando creamos un backlog de producto, tan importantes son las funcionalidades del usuario, como que el producto siga técnicamente a la altura con el paso del tiempo.
Las historias de usuario o tareas técnicas cuyo impacto es menos significativo en el producto y además, llevan menos tiempo de definición para los product owners y no se representan en este panel, sino directamente en el panel del equipo Scrum.
Usando tags
Tal y como se ha comentado en el apartado anterior, el panel contiene peticiones que implican a varios productos a la vez, bien porque el cambio se debe aplicar en todos ellos, bien porque hay dependencias entre sí pues el cambio en el producto implica a otros equipos como sistemas, calidad, etc.
Los tags de colores nos ayudan a visualizar rápidamente estos casos y las implicaciones que tienen estos proyectos con otros equipos de trabajo, por ejemplo:
- ARQ, es un tag donde indicamos cambios de arquitectura, en estos casos el equipo de desarrollo está trabajando junto con el equipo de sistemas.
- QA, es un tag donde señalamos una petición del equipo de calidad sobre la cual el equipo debe hacer una inversión notable.
- DEP, representa que existen dependencias y por tanto, los product owners están trabajando juntos y alienados en ese proyecto.
Cómo mantener este panel actualizado
Este panel lo estamos actualizando semanalmente, ya que las peticiones que muestra no son de un día o dos, son hitos de cada sprint del equipo. Los product owners en vez de una daily meeting, hacen una weekly meeting. Esta sesión dura aproximadamente 15′-25′ en un equipo de 10 personas, donde están los product owners y los líderes de los equipos de sistemas, calidad, etc. donde cuentan cómo están abordando los proyectos marcados con sus tags.
Lo decidimos así porque diariamente no había muchos cambios que contarnos, pero semanalmente sí, ya que algunos productos habían hecho release esa semana, mencionaban lo que pasaba a done y los nuevos proyectos en progreso, en otros casos el producto estaba en medio del sprint y se veía mas movimiento en los proyectos que pasaban a grooming o ready. Sea como fuere, es lo que en nuestro entornos nos resulta útil y necesario.
Algo muy valioso que aporta esta weekly meeting es conocimiento sobre todos los productos de nuestra empresa, que un product owner tenga una visión no solo de su producto, sino de toda la compañía.
Un ejemplo real de Product Owners Board
Vanesa Tejada 