¿Como limpiar y priorizar un backlog?
Product Management en Español
Hola, soy Charly! en esta serie de artículos iré contando el día de día como Product Manager, con sus aciertos y errores, los aprendizajes y el hands-on. Suscríbete gratis para recibir los nuevos posts y apoyar esta iniciativa.
En proyectos de consultoría me ha tocado sentir esa ansiedad de heredar un backlog de cientos o miles de tickets. Estoy seguro que ustedes en algún momento han vivido o posiblemente están viviendo una situación similar. Vamos a resolverlo!!
Después de haber pasado algunas veces por esa experiencia, me documente, investigue e incluso platique con otros Product Managers como abordarían esta situación. Les comparto algunas sugerencias que me funcionan para depurar y limpiar ese backlog caótico que a veces heredamos.
a. Diferenciar entre un item del backlog y una idea
Esta bien documentar y tener una sección de ideas y requerimientos, “pero debe estar en alguna otra herramienta, el backlog solo debe listar los items que se pretenden trabajar de verdad, dentro de los siguientes 3 trimestres.
b. Definir un tiempo límite para cada ítem
Normalmente solo los primeros 20-30 tickets, tendrán la posibilidad de cerrarse como completados. Los planes cambian y esta bien, salen nuevas direcciones dentro de la empresa, oportunidades y tareas urgentes, que anulan la prioridad de las tareas que se encuentran más allá de las primeras 20-30. Debemos limpiar los items que nunca se van a trabajar, o por lo menos moverlos a la sección/herramienta donde se documentan las ideas.
c. El backlog no es un BUGlog
Los bugs o errores, son tareas como cualquier otra, necesitan evaluarse, estimar su esfuerzo y priorizarlas contra otra oportunidad de producto. Si después de esta evaluación no lo logran, sorry! No hay necesidad de juntar bugs.
d. Los items deben ser de alta calidad
Los tickets deben relucir en el backlog, para esto nos debemos asegurar que tengan una historia de usuario, hipótesis de impacto, requerimientos, links al diseño y criterios de aceptación. Los tickets deben ser auto-explicativos para cuando tu no estes.
e. Tener 3 meses de tickets refinados, listos para trabajarlos
Puede ser difícil pero vale la pena. Tener los tickets para 3 meses y que el equipo pueda escoger entre ellos, te brindará el tiempo suficiente para hacer una planificación y evaluación a largo plazo adecuada. Definitivamente vale la pena hacer este esfuerzo.
f. Incluir ayudas visuales
Es más fácil mirar y entender el backlog si podemos diferenciar entre una nueva característica, iniciativas de mejora, bug/errores e incluso una investigación. Así mismo si agregas colores para representar el status de cada item, será más fácil hacer un scan visual y entenderlo de manera rápida.
g. Incluir los stakeholders principales a los tickets
Un email de actualización funciona, sin embargo automatizar los status de los tickets funciona mejor y mantiene informada a las personas relevantes, sin necesidad de que tengamos que estar invirtiendo tiempo.
h. Crear un documento de tareas asociado a cada item del backlog
Básicamente es una version extendida del ticket, donde se incluye toda la investigación pre-desarrollo, los resultados post-desarrollo y las observaciones. Reunir esta información en un solo lugar, te ahorra horas cuando debas escribir los updates de avance y presentaciones, al mismo tiempo, mantienes los tickets limpios solo con la información relevante.
Y con eso…. lo logramos!! backlog limpio y priorizado!! ;)
Tienes algún otro tip, que podamos agregar? Los leo en los comentarios :)
Para cualquier comentario o sugerencia, puedes contactarme en mis redes sociales: