Saltar al contenido
Be Agile My Friend

Entrega de valor en un Product Owner – Errores comunes

¿Los Product Owners deberían prevenir la entrega de valor? Por supuesto que no, pero es muy normal que esto se haga todos los días, en muchos casos sin saber que se está haciendo.

En este post se van a revisar algunos aspectos en los que el Product Owner no entrega valor, con sugerencias de mejora.

El Sprint Backlog es el “Plan del Equipo de Desarrollo”

Uno de los principales errores que se pueden cometer como Product Owner es enfocarse demasiado en lo que hay en el Sprint Backlog.

Por poner un ejemplo realista, imagina que has contratado un chofer con años de experiencia. Le dices que quieres ir de Madrid a Barcelona. ¿Vas a darle detalles concretos y monitorizar todo lo que hace? ¿No creés que es mejor sentarse, relajarse y disfrutar de todo el viaje?

Como Product Owner, es muy probable que estés muy preocupado en cómo avanza el Sprint, en vez de estar preocupado en cuál es el objetivo del mismo. Quieres que el Equipo de Desarrollo aporte valor. Realmente no importa cómo tu chofer vaya a Barcelona, lo que tu quieres es llegar a Barcelona, y ese debería ser la mentalidad que debes tener.

Confía en que tu equipo hará bien su trabajo, y céntrate en definir bien un objetivo de Sprint, y que tu equipo vaya en esa dirección.

Muchas features no marcan un objetivo de un Sprint

Tener un único objetivo de Sprint en el que centrarse mejorará la entrega de valor y garantizará el enfoque para el Equipo de Desarrollo.

Imagina que quieres viajar de Madrid a Barcelona, Valencia, Zaragoza y Sevilla a la vez. No estarías llegando a ninguna parte. El sentido común te va a llevar primero a una ciudad, y luego a la otra, y así sucesivamente.

Sin embargo, muchos Product Owners no piensan de esa manera a la hora de pensar los objetivos del Sprint, ya que creén que están ofreciendo más valor si el Equipo de Desarrollo está haciendo muchas cosas a la vez (al menos los vas a ver liados, 100% seguro). Lo que vas a obtener, también 100% seguro, son trozos de features terminados, y nada concretado.

Ciclos cortos y más enfocados aportan más valor que ciclos largos y poco enfocados.

Hacer que el trabajo importante sea poco importante

Los típicos problemas de “esto es urgente”, “esto no puede esperar”, “dejemos todo lo que estamos haciendo por esto”. Realmente estas cosas no son urgentes en un porcentaje muy alto.

Mantente crítico para los problemas importantes y pregunta rigurosamente si vale la pena interrumpir al equipo. Cualquier interrupción de este tipo podría costar fácilmente al menos a un miembro del equipo un día completo, probablemente más. Piensa estratégicamente, en ocasiones vas a decidir que algunas cosas simplemente no se van a arreglar.

Meter prisa no acelera nada

Si el equipo no avanza al ritmo esperado, meter más prisa nunca va a acelerar las cosas. Hay que asegurarse de estar siempre disponible y listo para ayudar cuando sea necesario. No intentes apresurar o forzar las cosas, porque incluso si funciona una vez, a largo plazo los resultados serán desastrosos.

Si estás preocupado por tu equipo, habla con ellos en la Retrospectiva, o habla directamente con el Scrum Master.