Cualquier cosa que pida un cliente, y pague por ello… ¿Va al Product Backlog? ¿Qué va a un Product Backlog? (2/2)

Vamos hoy con la segunda parte de aquel post que empecé ayer, que iba a ser cosa de poco, que pensé que incluso no me daría para post y mira en lo que se ha convertido. Aquí está el enlace a la primera parte, por si no la has leído.
.
.

2 – ¿Y qué pasa con las Historias Técnicas?

Las mal llamadas Historias Técnicas. Digo lo de mal llamadas, porque creo que aclara más quitarles la palabra «Historias» y llamarlas Tareas Técnicas, que luego se olvida lo de «Técnicas» y se quedan en «Historias».

Aquí meto tareas del tipo a «Montar una BBDD», «instálame otra versión», «actualízame», etc., que muchos pueden argumentar que no son «quitar Deuda Técnica», ni funcionalidad, y que nos pudiera pedir, explícitamente, un Cliente (por lo cual tampoco serían Tareas derivadas de una Historia), incluso pagar por ellas.

En este caso, como son de cara al cliente, las pide él, paga por ello… mi consejo es que vayan al Product Backlog, como una Historia de Usuario. Así será el Product Owner quien negocie, y decida, que prioridad tienen.

Pero ojo, que aquí se puede abrir una puerta al Lado Oscuro e incluso a Mordor… ¿y si esas cosas que pide el cliente no son ni Historias de Usuario ni son Tareas operativamente Técnicas? ¿Y si son papel? ¿Me pide Análisis, Mockups, etc.? ¿Qué hacemos? mmm… lo dejo para el caso número 4.

3 – ¿Y los bugs van al Product Backlog?

En este caso un bug, entendido como un error que reporta un usuario, o detecta el Product Owner, o algún Stakeholder o algún habitante de la galaxia. Este tema es de negocio y de producto… parece razonable que estén en el Product Backlog y que sea el Product Owner quien los priorice frente a otros Items.

Otro tema, en el que no voy a entrar porque se me iría el post (ya bastante se ha ido), es que NO deberían contar en la Velocidad, no deberían sumarse sus Puntos Historia al computo de cómo ha terminado el Sprint, sería engañoso para los Clientes el hacerlo… ¿qué pinta tendría un Sprint que termina con muchos Puntos Historia y en el que sólo se han resuelto bugs de antiguas Historias que ya, en su momento, también sumaron Velocidad? ¿no te suena a los viejos tiempos? Sí, aquellos de facturo las horas del desarrollo… y también las horas de arreglar lo que no desarrollé bien, eso que se llamaba mantenimiento (En agilidad… ¿Existe el “mantenimiento”?) ¿recuerdas?

4 – Y otras cosas que pide el cliente, o que le vamos a facturar… ¿van al Product Backlog?

Hablo de otras cosas… ¿que otras cosas, que no sean Historias (funcionalidad), Historias Técnicas o bugs, quedan que un Cliente (que no digo usuario) nos pueda pedir? Y que al pedírnoslas un Cliente pudieran entrar en el ámbito Product Owner – Product Backlog: el papel. Informes, estudios, análisis, mockups, word, ppt, pdf, etc.

Todos los anteriores crean bastante confusión, porque muchos argumentan… «¡vaya si tienen Valor esas «historias» para el negocio! ¡nos pagan por ello!». Cierto, pero quizá Valor en un negocio de toque oscuro (aunque lucrativo pudiera ser).
Valor, esa palabra digna de Hodor, simple, tan repetida como mal interpretada y que es la clave de todo. ¿Valor para el cliente? ¿para el usuario? ¿para el producto? o ¿para nosotros?

¿No te suena raro que estén esos Items en el Product Backlog? No suena a Cascada, a predictibilidad. A un Product Backlog que esconde un cascada. A terminar con papeles e invertir trabajo que luego puede nunca llegen a ser una funcionalidad del producto. A que se pudiera dar el caso de que rompamos con la buena práctica de que un Sprint debiera terminar con un ->Producto<- Potencialmente Entregable (que no Papel Potencialmente Entregable). A no estar pensando en MVP (->Producto<- Mínimo Viable). ¿Añaden valor directo al Producto? ¿Y a los Usuarios?… o sólo al Cliente… ¿Vamos a facturar por cosas que probablemente luego quedarán en un cajón?

Si nos agarramos a lo que decía nuestra sección «Shu», que tiraba de la Guía de Scrum, ahí salían muchas cosas, pero siempre la palabra… producto. Añadir al Producto, no al word.

En este caso, puedes hacer lo que quieras, o puedas, mételas en el Product Backlog, pero me suena a que no has entendido lo que buscábamos con la Agilidad. Y si lo has entendido… sal pronto de esa estrategia.

Terminando…

De todo lo anterior, vuelvo a reforzar la idea de la importancia de llamar a las cosas por su nombre, una Historia de Usuario es funcional, end-to-end, etc., una mejora de Deuda Técnica no es una Historia de Usuario, un bug no es una Historia, etc.

Si a todo lo que hay en unProduct Backlog le llamas historia… mal asunto.

Me repito de otros post: esto es lo que yo pienso y lo que yo he experimentado y lo que mejor me ha funcionado… hasta que encuentre otra mejor opción. Salvo caer en el Lado Oscuro… experimenta. Duda y humildad.

Hay un post algo viejuno, de 2013, pero que en gran parte es aún valido, el de Cómo gestionar bugs e incidencias en un proyecto ágil que puede complementar este.

*Quizá sobre decirlo pero lo de Shu es por aquello de aplícate el Shuhari

3 comentarios en “Cualquier cosa que pida un cliente, y pague por ello… ¿Va al Product Backlog? ¿Qué va a un Product Backlog? (2/2)”

  1. Pues hoy no estoy de acuerdo contigo. Si creemos que lo que nos pide el cliente no tiene valor, una de dos: el cliente se equivoca o no entendemos el valor que tiene. Si el cliente se equivoca, hacerlo y punto es una mala praxis, desde mi punto de vista. Así que siempre recomendaré, cuando no entendamos el valor, revisarlo con el cliente hasta entender. Si paga, es por algo.
    Y luego, decir que «producto» es software y nada más me parece limitado. ¿Un informe no es un producto que se le entrega?
    Por otro lado no entiendo la comparativa con cascada. ¿Qué tiene que ver como nos entregamos para ir aportando valor con la tipologia de la tarea? ¿Acaso no podemos aplicar MVP igualmente a un informe? Por ejemplo, un manual que en vez de hacer el super manual, se hace el mínimo viable y luego se va ampliando. Si el departamento tiene mucha rotación (ejemplo: un call center) será un documento muy útil.
    Además, no será la primera vez que me han pedido un informe o una presentación y hemos acabado haciendo un reporting automático. O que nos piden una actualización masiva de datos y acaba en una pantalla para que el usuario lo pueda hacer él sólo. Si entendemos el valor, mejor podemos ayudar.
    Resumen: Si no vemos valor -> Hay que entenderlo. Hacer sin entender el valor, malo. No todo es software en la vida, y no todo el valor viene de ahí.

    1. Hola, buenos días.
      Trabajar con un Backlog lleno de informes (pdf, papel) es muy lícito… pero poco ágil. Y se puede ser feliz (y ganar mucha pasta) sin ser Ágil, y no pasa nada, no hay porque sentirse mal por ello (o sí, eso depende de muchas cosas).
      No lo digo yo, lo dice el Manifiesto Ágil… Working software over comprehensive documentation. Lo único que tocaría del anterior valor es cambiar «software» por «solutions»
      Saludos

      1. Lo dicho, pensamos diferente. Y por eso te leo. (Si no que aburrido sería leer lo que ya pienso).
        Creo que el espíritu del manifiesto es la documentación generada por y para el equipo. Su traducción oficial: «Software funcionando sobre documentación extensiva». Análisis sin fin. Procesos tediosos. UML to the limit. Eso es lo que se intenta evitar.
        Pero algo que va a otorgar valor al cliente (porque si creemos que no, ya lo he dicho: hay que hablarlo) deberíamos hacerlo. Este tendría que ser nuestro objetivo: maximizar el valor entregado.

Deja un comentario

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

Share This
Ir arriba