Todos sabemos que el Product Owner es el responsable de maximizar valor de nuestro producto. El artefacto clave es el Product Backlog, donde debe estar “todo” lo que vamos a hacer (con el conocimiento que tenemos hoy) para producir ese valor. Este Product Backlog está ordenado de manera que los elementos que se van a abordar pronto se colocan en la parte superior y se detallan, mientras que dejamos para el fondo lo que abordaremos en un futuro (o puede que nunca hagamos).
El Product Backlog está muy bien pero… ¿Podemos utilizar otras herramientas adicionales aunque no estén en la guía Scrum? ¡Por supuesto que sí! A continuación estudiaremos unos cuantas, no obstante, me gustaría antes aclarar un punto:
Las herramientas son herramientas
Tenemos que tener muy claro que las herramientas son eso, herramientas. No son ni buenas ni malas. Un coche es un medio de transporte que se puede convertir en un arma si te dedicas a atropellar personas o puede transportar un corazón para una operación de trasplante. Las herramientas usadas bajo la mentalidad Agile donde hay incertidumbre, donde no hay exactitud, donde construímos productos pueden funcionar muy bien. Trato de hacer esta aclaración porque hasta un Diagrama de Gantt puede ser útil si lo usamos bajo este prisma y una Historia de Usuario puede ser una mala idea si estamos en proyecto y queremos tener los requisitos muy claros y sin ambigüedad. Vamos a estudiar cómo nos pueden ayudar desde estos dos puntos de vista cada una de las herramientas que propongo.
Work Breakdown Structure (WBS)
El WBS consiste en eso, en romper la estructura (el alcance) de un producto en pequeñas partes más manejables que nos puedan ayudar a entender mejor lo que vamos a construir. El PBS es una herramienta extraída del PMBook y es su arma principal para tener definido el alcance.
El WBS tiene la siguiente estructura:
¿Si es del PMP porqué puede ser útil para un Product Owner? En mi experiencia profesional he trabajado para empresas que en la fase de ideación previa a empezar a desarrollar (lo que llamábamos Sprint 0), utilizaban esta herramienta.
La idea de co-crear con el cliente el PBS de manera que podamos visualizar todo el alcance en un panel, funciona muy bien. Esto nos permite hacernos una idea de un alcance cuando tratamos con un cliente donde la confianza aún no está trabajada. Evidentemente, si tratamos con el PBS de buscar una fecha cerrada donde aseguremos que todo el trabajo estará finalizado, volvemos al paradigma de proyecto y seguramente nos estrellaremos. Ahora bien, si usamos esta técnica con un cliente y le decimos “esto nos permite tener una idea de por dónde empezar, una primera priorización y el coste aproximado será este”.
Como bien aprendí en una charla de la CAS 2016, esta técnica nos puede ayudar a hacer una oferta responsable, lo que se puede traducir en el inicio de una relación que acabe en mentalidad producto.
User Story Mapping
Jeff Patton fue quien trajo esta técnica para organizar ideas. Jeff veía que había un gap entre la visión de las Historias de Usuario (cortoplacistas e independientes) y la idea general de lo que construíamos. El User Story Mapping nos permite dar una coherencia a un conjunto de historias para saber cómo se comportará el sistema a medida que un usuario interactúa con él.
A diferencia del PBS, que se construye hacia abajo, el USM se escribe de izquierda a derecha ya que describe una historia en el tiempo que sigue un usuario. Podemos ver un ejemplo:
En este caso tenemos un objetivo: tareas desde que nos levantamos hasta ir a trabajar.
- Los postits azules son los primeros que se construyen y marcan lo que conocemos como el “sea level”. Estos postits deben de ser intercambiables. ¿Me ducho primero o desayuno?
- Dentro de cada zona azul tenemos los amarillos que representan subtareas, cuanto más hacia abajo representan menos probabilidad. “lavarme el pelo es menos prioritario que el cuerpo porque hay días no lo hago”.
- Después, los verdes sirven de agrupadores, lo que está entre uno y otro pertenecen al de la izquierda, ayuda para entender mejor y hacer agrupaciones. Mucho cuidado, los verdes no son los primeros postits que se colocan, y no son los módulos funcionales o las épicas.
- Los rosas representan hitos, en este caso se diferencia entre el día normal y el día en el que me levanto tarde y tengo 5 minutos “¿Desayuno si solo tengo 5 minutos?”.
- Por último, los naranjas representan ideas, sugerencias, dudas o cualquier otra cosa que queramos ir trabajando. Si atañen a otra idea se pueden poner encima.
El USM se puede utilizar principalmente para marcar flujos de trabajo o representar una experiencia completa de un usuario pasando por diferentes acciones representadas por Historias de Usuario.
Impact Mapping
El Impact Mapping (IM) es una herramienta muy importante para hacer pensar a un cliente en los motivos de hacer lo que hace. A diferencia del USM y del PBS no nos centramos tanto en qué hacer sino en mapearlo con los objetivos por los que abordamos este producto. Por este motivo, es una herramienta recomendada para hacer previamente a las otras dos. ¿Cuáles son los objetivos de mi producto? Esta herramienta te ayuda a descubrirlo.
El IM se divide en cuatro niveles principales. Primero se marcan objetivos, la dimensión “Qué”. Por cada objetivo nos hacemos la pregunta “Quíen” y rellenamos los actores. Estas personas son las impactadas por este objetivo, o personas que nos ayudarán a conseguirlo. Mi compañero Aday Guerra nos aclaraba que puede haber usuarios impactados de primero, segundo y tercer orden. Por ejemplo, en una casa de apuestas el primer orden sería el apostador, el segundo orden el financiero que lleva las cuentas y el tercer orden hacienda.
El punto diferenciador de esta herramienta es precisamente los “impactos”. Los impactos representan el valor diferencial que le aporto a mi actor para ayudar al objetivo. Los impactos deben ir acompañados de KPIs que definan cómo vamos a medirlo. Esos KPIs pueden contener desde valores mínimos a valores objetivos de manera que sepamos si realmente estamos impactando en nuestro usuario.
Por último, podemos rellenar los «derivables», que son las funcionalidades que voy a construir en mi producto. Con estas funcionalidades conseguiré ese impacto (que mido con KPIs), para ayudar a mi actor a conseguir su objetivo.
A la hora de rellenarno, Jeff Patton nos recomendaba hacer un primer objetivo en profundidad, y después ampliarlo en vertical. Recomendamos el taller de IM con el sponsor y los interesados clave, ya que nos puede ayudar a entender porqué construímos este producto y qué es lo más importante para la organización. Además, es de las pocas herramientas que trabaja los KPIs que nos dicen si vamos por el buen camino, ¡el resto de herramientas solo se centra en el alcance no en el éxito!
Plan de releases
El Plan de Releases o Plan de Sprint es una herramienta bastante útil de cara a la gestión de dependencias y riesgos futuros y a pensar un poco en lo que viene. Una vez más, mal utilizada se puede convertir en un plan tradicional donde nos comprometemos a unas entregas de alcance en fechas cerradas lo que lo convierte en una mala idea.
La idea es sencilla, consiste en ubicar los elementos del Product Backlog conocidos en el tiempo en Sprints. Lo recomendable es 3 o 4 Sprints como mucho. Quedaría una estructura parecida a esta:
De esta manera, podemos visualizar el futuro de nuestro producto y utilizar esa información para tratar dependencias. Por ejemplo, imagina que en el Sprint 3 tienes pensado abordar una funcionalidad que requiere de una aprobación que lleva tiempo. Esperar hasta el Sprint Planning del tercer Sprint puede provocar que no tengamos esa aprobación y dejemos trabajo sin terminar. De esta manera podremos trabajar esa dependencia un par de Sprints antes.
Esta herramienta la deberíamos de tener presente en cualquier momento en el que trabajemos el Product Backlog: Sprint Planning, Refinamientos, Sprint Review y cualquier otra reunión. El PR nos aporta una visión holística de nuestro producto, y de las funcionalidades que esperamos ir incorporando.
Mind Map
Los mapas mentales son herramientas muy útiles principalmente para memorizar. Básicamente, consiste en colocar una idea central (a poder ser con un dibujo) y después sacar ramas de cada uno de ellas con ideas relacionadas con la principal. Cada rama puede tener colores y se puede subdividir en más ramas según la profundidades que queramos acometer.
A nivel de equipo, le podemos dar dos usos. Por un lado, podemos utilizarlo para analizar el alcance de una manera mucho más visual. Esto nos permitirá construir con los stakeholders todas las ideas que queramos incluir en nuestro producto. De una manera visual podemos acabar teniendo una foto del alcance, aunque una vez más, tenemos que entender que en Agile la solución final la iremos descubriendo a medida que pase el tiempo y ganemos experiencia.
Por otro lado, es una muy buena herramienta de memorización. Esto ayuda a un desarrollador a hacer mejor su trabajo porque le permite tener en la cabeza los detalles del negocio que tiene que tener en cuenta.
https://www.illumine.co.uk/2006/07/coding-knowledge/
Roadmap
Un Roadmap es otra herramienta útil de cara a mirar al futuro de nuestro producto y la estrategia que queramos seguir. A diferencia del Release Plan, el Roadmap mira a un futuro más lejano, por lo que realmente juega con más incertidumbre y mayor riesgo de que un stakeholder interprete que hay compromisos a 6 meses o 1 año vista.
La herramienta fija un poco los próximos meses donde ubica al Product Backlog y después define líneas temporales lejanas donde ubicar ideas futuras que queramos incorporar en nuestro producto.
El RoadMap se utiliza para desbloquear presupuesto futuro, para trabajar expectativas muy futuras y de alguna manera demostrar que no abordamos esas ideas porque estamos ahora haciendo otras diferentes.
¿Agile Gantt?
Aquí tenemos a la joya de la corona. Aunque no lo he probado con ningún equipo lo he visto del libro “Product Owner 2015” y me pareció curioso:
Es un Diagrama de Gantt pero con tres características diferenciadoras. Por un lado, no se entra en detalle de tareas, solo en alto nivel como puede ser Historia de Usuario. Por otro lado, cada feature debe ocupar un Sprint completo, no es que tenga esa duración, es una manera de decir “al terminar el Sprint lo entregamos, pero no sabemos el orden”. Y por último, no se hacen asignaciones de las features a personas concretas del equipo, damos por hecho que el equipo se auto-organizará para acometerlo como un todo.
Este Agile Gantt puede ser útil para lugares donde el diagrama de gantt es obligatorio y, sin ello, no podemos desbloquear próximos pasos. Si hacemos un examen detallado, veremos que realmente es un «plan de releases encubierto».
Una vez más, una herramienta es una herramienta, en una cultura Agile cualquier nos puede ayudar, con una cultura waterfall, cualquiera puede hacernos daño.
¿Qué más herramientas utilizas con tus equipos?
Vaya que son buenas herramientas, yo en lo particular he ocupado para iniciar el Impact Mapping y posteriormente el User Story Mapping y me van de maravilla.
Saludos desde México.