Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas ¿Cómo divido el Product Backlog? ¿Tengo que usar historias de usuario? ¿Qué hago con mi conocimiento técnico?

Estas son algunas de nuestras recomendaciones, basadas en la experiencia de Product Owners que han vivido el cambio de rol en nuestros clientes.

Dividir el Product Backlog

Enfrentarse por primera vez a un Product Backlog que tenemos que dividir en elementos que se puedan construir en un sprint y que aporten valor, es una de las experiencias más estresantes para un Product Owner. Durante la formación de Agile y Scrum, o si tienes a alguien acompañándote en el proceso (espero que tengas al menos una de las dos), te habrán dicho que el Product Backlog está escrito en un lenguaje de negocio expresando el problema y no la solución. Que cada elemento (PBI) debe aportar valor al cliente o al negocio tras finalizar el sprint, y que se inicia y termina en el mismo sprint.

Llevas años aplicando de manera consciente o inconsciente el divide y vencerás para construir software, la recogida de información, la conceptualización, planteando diseños que permiten hacer lo que pide el usuario. Sigue usándolas, no dejes de hacerlo. Son herramientas muy útiles para un Product Owner. Hay dos adaptaciones principales que te recomiendo realizar:

\

El Lenguaje

Deja de lado el lenguaje técnico, y adopta un lenguaje de negocio. Esto quiere decir que tu backlog no debe hablar de programas, clases, APIs, interfaces, campos de ficheros, base datos, etc…
Para conseguirlo te propongo hacer una “desintoxicación”, y que estés de 4 a 6 sprints sin participar en las conversaciones tecnológicas, sólo escuchando. Deja que el equipo de desarrollo busque la mejor solución técnica con su conocimiento e información.
Pensarás «Entonces les dejo hacer. aunque no estén acertando o no estén cerca de la solución». Siguiendo la misma línea, deja que debatan. Sólo si ves que realmente se están alejando mucho o van a crear un problema mayor, intervén y aporta tu conocimiento técnico. Es la única excepción al periodo de desintoxicación, y que sea muy muy muy muy excepcional. Confía en ellos.

\

Dividir Horizontalmente

En general, los desarrolladores dividen el producto en pasos o funcionalidades de forma vertical. Diseñan y construyen cada paso, y hasta que no están todos los pasos no tenemos el proceso de negocio completo. Adapta tu forma de dividir para que sea horizontal, y que cuanto antes se pueda realizar el proceso más básico y representativo del negocio.
Te dejo aquí dos infografías que te ayudarán a hacerte las preguntas adecuadas, a la hora de dividir:

Además de esto, recuerda que el Product Owner es responsable de mantener el Product Backlog, lo que no quiere decir que tengas que hacerlo solo. Pide ayuda, al final el Equipo Scrum sois todos los miembros.

Escribir Historias de Usuario

Es muy probable que para escribir tu Product Backlog te recomienden, o impongan, el uso del formato de Historia de Usuario. Como os explicamos en nuestra entrada Es importante usar Historias de Usuario, para un Product Owner novel tiene ciertas ventajas.

Pero más allá de eso, ¿estoy obligado a usarlas? La respuesta es un rotundo NO. Scrum no te dice cómo tienes que escribir el backlog, te da unas características básicas que debe cumplir, eso es todo. Lo relevante es que cada elemento del Product Backlog exprese qué necesidad está cubriendo, ya sea del cliente o de la empresa, y por qué tenemos que cubrir esa necesidad. Mientras esto se cumpla, no importa cómo lo escribas. Te dejo algunas opciones para escribir elementos del backlog:

\

Un título y una descripción de lo que quiere hacer el usuario.

Comprar una botella de vino
Nuestro cliente quiere comprar vino desde casa, y que se lo entreguen dentro del horario que él se encuentra en su domicilio.

\

Un título y describir qué está pasando ahora y qué debe cambiar.

Comprar una botella de vino
El cliente tiene movilidad limitada e ir comprar físicamente a las tiendas, le supone un gran esfuerzo y riesgo para su salud. El médico le ha aconsejado tomar un vaso de vino en las comidas.
El cliente quiere que le lleven el vino a su domicilio.

El tamaño del Product Backlog

Te preguntarás, ¿cuál es el tamaño óptimo de un Product Backlog saludable? ¿Cuántos elementos? Antes de responder a estas preguntas, empecemos aclarando algunas cosas sobre el Product Backlog:

W

No hay un tamaño estándar de Product Backlog.

W

Es un artefacto vivo, en constante evolución y adaptación. Mantenerlo ordenado y actualizado es esencial para el Product Owner.

W

Debe tener profundidad, o elementos suficientes, para garantizar que tenemos elementos listos para construir a uno o dos sprints vista.

W

Debe mantener al equipo de desarrollo en un nivel de tensión saludable. Sin llegar a ser tan estresante que los deje bloqueados.

Cada Product Owner tiene que encontrar el equilibrio entre esos tres términos: mantenimiento, profundidad y tensión. En unos equipos será de 20 elementos, en otros de 100. Experimentad juntos, como Equipo Scrum, y encontrad el encaje óptimo para vosotros.

 

Mi principal consejo es que explores, que te atrevas a probar y equivocarte. Estás adaptándote a un nuevo rol, para el que puedes apoyarte en muchas habilidades que llevas usando años. Sólo tienes que cambiar el contexto donde las aplicas. Y confía en el resto de tus compañeros de tu Equipo Scrum.

0 comentarios

Enviar un comentario

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

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies