Recientemente he concluido un programa de training como product owner de la Scrum Alliance. No difiere mucho del programa de Scrum máster y me deja más dudas que respuestas.

Sí, la figura del Product Owner está clara (no lo está) su responsabilidad ordenando el backlog, hablando con diferentes stakeholders…

Pero Scrum se centra en el equipo de desarrollo, en sus interacciones, habla de la entrega de valor por parte del equipo, pero se deja cosas importantes.

Si consideramos Scrum parte de un todo tendría dos interfaces claramente definidas, entrada y salida. La entrada es el backlog (y desde aquí tendríamos el upstream) y en la salida tendriamos el “Potentially shippable product increment” o increment directamente. El increment sería el downstream, la entrega, le seguiría el despliegue y la explotación (downstream).

Upstream

La parte de arriba de un río es el “upstream”, para Scrum (siempre en mi humildísima y muchas veces errada opinión) el upstream empieza en el backlog y habría que preguntarse que hay antes de él.

¿Cómo se llega al backlog? ¿Qué fuentes hay que tratar? ¿Cómo priorizar diferentes fuentes (bugs, nuevas funcionalidades, compliance). Incluso siendo más puristas, ¿cómo se almacena esa información? vuelve a la guía scrum y dime en qué punto se mencionan las historias de usuario, te lo adelanto: no las menciona.

El upstream queda descafeinado con un backlog ordenado de prioridades y con el hecho de que las historias de la parte superior deberían estar más refinadas, y listas. De nuevo te reto a visitar la guía oficial y decirme dónde está el definition of ready.

Downstream

Vamos a la salida, acabamos la demo de nuestro incremento. La definition of done incluye que esto debería desplegarse, pero la definition of done es flexible y evoluciona con el tiempo. Muchos equipos dejarian las cosas como done estando testeadas, pero ¿desplegadas?

Scrum no habla del despliegue, de la misma forma que no habla de la explotación posterior. Se deja en blanco para que otros lo complementen, aquí entra en juego devops, (y quizás itil para explotación).

Pero no hay una revisión posterior del valor entregado, de su uso, al menos en la guía oficial.