Hace unos años, durante una sesión de PBR (Product Backlog Refinement), comentamos sobre algo nuevo que queríamos hacer que no estaba aún en el backlog. Entonces, vino la pregunta:
¿Las historias de usuario las vas a redactar para que las entendamos nosotros o para que la entienda negocio?
Arquitecto SW
Y es normal. Nunca he visto criterios claros más allá del INVEST. Se confunden mucho los nombres de los ítems que entran en un product backlog. Se incluyen tareas “técnicas”, escritas por y para desarrolladores al mismo nivel de jerarquía que otras.
Sin duda alguna, el product backlog es una de las herramientas más maltratadas del mundo del SW.
Ya está, ya lo he dicho.
¿Qué entiendo, deberían ser las historias de usuario?
Cualquier cosa que queramos hacer, contándolo como si fueras el que va a usarlo. Parece una definición muy naive pero es clave por un par de cosas:
La primera es por la transparencia. Estáis fabricando productos que van a utilizar (O gestionar) otras personas dentro de la empresa y todo el mundo va a querer siempre desarrollos. Un backlog que no está contado de tal manera que todo el mundo pueda entenderlo, no cuenta el plan que está detrás de esa priorización. No se conocerán los objetivos que se buscan y empezarán las malas caras.
La segunda es el encargarte del qué y no del cómo. Está genial que un PM/PO tenga conocimientos técnicos, de usabilidad, que conozca las soluciones implementadas al mayor detalle posible. Que pueda aportar su opinión sobre las nuevas en los correspondientes foros. Pero el equipo de desarrollo es el que debe decidir cómo hacer las cosas. Si no es así, se está entrando en micro-management. O estás trabajando de más o estás dedicando menos esfuerzo a estar con tu usuario y con el negocio viendo cómo está respondiendo tu producto.
Estar más atento a la estrategia que a la implementación
Imagina que estás en un negocio B2B, en el que el que te encuentras con lo siguiente:
- El número medio de compras por cliente al mes ha bajado de 2,7 a 2,5.
- Su ticket medio es de 100€.
- Tienes una media de 1000 clientes recurrentes.
- Se reciben 15 contactos al día en atención al cliente.
Con esas cifras, la empresa va a ingresar 20.000€ menos al mes, más de un 7% de su facturación. Poca broma con esto.
En principio, los contactos a atención al cliente no son un aluvión, pero es casi uno por cada cinco envíos. Una barbaridad muy poco escalable. Hablas con ellos y te dicen:
- La mitad de las preguntas están relacionadas con que no saben el estado de su envío.
- Un 20% a que no encuentran el producto que quiere.
- Un 20% porque no tienen su compra confirmada pasadas 24h del pago.
- El 10% restante llama por otros motivos.
Empezamos bien, sabemos qué abordar primero. Se plantean 2 historias de usuario dentro del backlog para dar visibilidad del envío al cliente:
- Saber si mi pedido ha sido enviado.
- Saber si mi pedido se va a poner en reparto.
Partes de ahí como dos puntos de contacto fundamentales para el cliente. Saber cuándo ha salido de tus instalaciones el envío y cuándo se le va a entregar. No sabes cómo vas a implementar la solución, pero tienes información suficiente para empezar a hablar con el equipo. Estamos en un mundo ideal hay varios desarrolladores que hacen que el equipo sea full-stack, hay conocimientos de usabilidad, es totalmente autosuficiente y el histórico te dice que hacen alrededor de 10 puntos por sprint de 2 semanas.
Acompañar al equipo a poner el foco
Salen varias opciones en la planificación de tu sprint: Notificar por email, SMS, WhatsApp o hacer un portal de seguimiento visible en la web. Los desarrolladores dicen:
- Informar al usuario por e-mail, con un esfuerzo de 5.
- Notificar por SMS con un esfuerzo de 2.
- Enviarle la información por WhatsApp, con un esfuerzo de 5.
- Hacer un portal de seguimiento dentro de la web con un esfuerzo de 21.
Piensan en que para hacer las notificaciones con el teléfono habría que pedir un móvil obligatoriamente, implicando 3 puntos más de esfuerzo.
En la segunda historia de usuario no tenemos que rehacer el trabajo de comunicar por SMS. Hay que pedir la información a la agencia de transporte. Trabajar con un equipo externo e integrarse con ellos siempre aumenta la complejidad y el esfuerzo. La agencia de transporte no te cobra un extra por esta información.
Lo que cuesta una implementación también define el backlog
Aquí, ya has investigado un poco y sabes que cogiendo un proveedor de envíos de SMS, te sale la notificación del envío a 0,02€ y por WhatsApp a 0,0380€. Con los 2.500 envíos mensuales que tienes actualmente, con 2 notificaciones por envío son 100€ y 190€ mensuales respectivamente. Bastante asumible, pero con emails lo haces por 19€ al mes.
El portal lo descartas por su coste de implementación, se te duplica el tiempo. Elegimos email por el coste y se decide priorizar la información de que el envío a salido de nuestras instalaciones, para informar al cliente lo antes posible y reducir así la llamadas.
Nos queda el siguiente backlog después de nuestra sesión de refinamiento con el equipo:
- Notificar por email que el pedido ha salido de nuestras instalaciones. 5 puntos.
- Notificar por email que el pedido se va a repartir hoy. 5 puntos.
Historias de usuario. Menos información, más claridad
Con meterse en el backlog y sin entrar a ver detalles de la implementación, cualquier persona de la compañía podría entender qué estamos haciendo. Se podría discutir si es lo más importante para la compañía. Tenemos los datos y podemos medir el avance de nuestras métricas de negocio.
Aunque haya mucho trabajo detrás, tienes visualización a alto nivel de lo que hay. Tienes un objetivo para el sprint y los desarrolladores ven que están pegados al negocio. Dentro de cada una de estas historias de usuario, se habrán sacado las tareas necesarias para llevar a cabo el trabajo y organizar el sprint.
Sé que como ejemplo estoy obviando muchos detalles dentro de un backlog y que lo normal es que sea más complejo. El gestionar deuda técnica, errores y esas mejoras que vienen del lado del desarrollador. Gestionar las iniciativas que vienen de otros departamentos. Las oportunidades comerciales que implican integraciones o desarrollos y deben ser para ya.
Pero si partimos de que el PO/PM no escriba su backlog para que cuente una historia clara, poco podemos hacer con todo lo demás.
¿Y en tu empresa, cómo se escriben historias de usuario?
