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.

También te puede interesar

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

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.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

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