[Pregunta] ¿Cómo gestionar un backlog muy largo?

[Tana]

Hola,

Estoy ayudando a una empresa a gestionar su gestión de proyectos y he decidido ir a por Full Scrum con Trello (por necesidades de equipo remoto).

El problema es que en uno de los proyectos tenemos un backlog con 160 tarjetas y al equipo se le hace difícil gestionar las prioridades.

Creo que una de las posibilidades es hacer lo que dice este post: tener dos boards, una para el backlog más general, separando con más detalle las ideas, nice to haves, epics, planned, etc, y en otro mostrar más el day to day, el current sprint.

¿Qué opinan? ¿Alguna sugerencia?

Sé que el verdadero problema ahora mismo es tener un backlog con 160 tarjetas, pero quería saber si tienen alguna situación similar.

Gracias! Tana

[Juan Ignacio]

No creo que un backlog de 160 tarjetas sea necesariamente malo, pero si que se hace poco práctico para el día a día. La idea de usar dos trellos es buena. Yo añadiría un límite a la columna de backlog en el trello principal o de trababo, al estilo kanban, digamos 20 entradas. Solo está permitido trabajar con este backlog reducido. Y solo el PO puede meter o sacar cosas en el backlog, siempre respetando el limite máximo.

--

---
Has recibido este mensaje porque estás suscrito al grupo "AgileCanarias" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-canaria...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Juan Ignacio Rodríguez de León
Móvil: 605 890514
E-Mail: euri...@gmail.com
http://www.elornitorrincoenmascarado.com/
http://descon2.com/

[Francisco Mesa]

En mi caso, hay diferentes flujos de trabajo. 160 tarjetas no pueden ser tareas rápidas. Así que su organización tendrá que ser la típica que permite construir el proyecto a base de iteraciones. Separar las tareas por subproyectos y tener solo activo los que se pueden realizar en un plazo corto o que permitan avanzar hacia otros es mi opción para tener un conjunto mentalmente abordable.

--------------------------------------------------------------

LinkedIn: http://www.linkedin.com/in/franciscomesa

		Francisco Mesa about.me/franciscomesa

Twitter: @franciscomesa

Skype: francisco_mesa

Mobile: +34 686645701 (Yes... Spain)

[Fran Reyes Perdomo]

¿Estás hablando del product backlog o el sprint backlog? Si se trata del product backlog, sólo te deberías preocupar cada sprint.

¿Por otro lado esas tarjetas que representan? ¿historias de usuario? Si no lo son, quizás por eso te salen muchas tarjetas.

Por experiencia, es muy posible que ni siquiera se vayan a hacer.

Si te parecen muchas, ponlas en otra parte, mueve gran parte a otro lado por si las quieras tener por ahí apuntadas para no olvidarte.

Pero dales ese valor "cosas que ya veremos, las apunto para tener una visión" pero las trabajaré más tarde.

Saludos

[Yeray Darias Camacho]

Para mi, hay que tener en cuenta en que tipo de empresa/producto se está trabajando. Mi experiencia me dice que no se pueden gestionar igual las tareas de un proyecto cerrado de una empresa de servicios que las tareas de una startup que está fabricando su propio producto. Entiendo que este último es el caso de Tana.

En el primer caso tendrás, por supuesto, cerrado el presupuesto y el tiempo, pero el alcance además no puede ser tan variable. Normalmente no puedes quitar una funcionalidad, por lo que tienes que jugar con la calidad final de esas funcionalidades. 

En el caso de una startup o un producto propio, todo es más abierto. Aquí puedes jugar con el alcance de la funcionalidad, con qué funcionalidades se implementan (o no) y con el tiempo. 

Dicho esto, lo que hacemos nosotros es tener un backlog general, lo que para ti sería esa segunda pizarra. En él ponemos todas las ideas, épicos y similares que se nos ocurren. Generalmente el detalle de estas ideas es muy genérico y a veces ni hemos pensado en la viabilidad o valor de negocio de las mismas, simplemente son ideas y las queremos tener ahí para que no se nos olviden. Cada semana vamos mirando a ver si alguna gana peso y pasa a un status más prioritario. Bien, pero creo que hay que tener cuidado porque con Trello esto se desmadra muy rápido.

Luego tenemos nuestros tablero Kanban, pero que se podría extrapolar a Scrum, en el que tenemos una columna de backlog. En dicha columna ya se encuentran historias de usuario, o algunos épicos (porque somos Kanban y no necesariamente queremos llegar al nivel de detalle, generalmente trabajamos siempre la primera vez con la idea más básica posible de un épico y luego la mejoramos en iteraciones futuras) que están definidos y que consideramos aportan valor en el corto plazo. Y posteriormente el resto del panel es el Kanban clásico con sus límites por columna.

Por todo esto es muy posible que esté totalmente de acuerdo con la idea propuesta, pero creo que en ese backlog de 160 tareas definiría entre 3 y 5 niveles diferentes en función de la madurez y detalle de la idea (es  como dibujar el backlog en forma de iceberg típico, pero en horizontal). Eso es fácil de hacer en Trello y ayuda mucho a la gestión del backlog. Y en el tablero scrum de la iteración añadiría una primera columna que no son todas las historias de la iteración sino el corto-medio plazo en el que están las tareas correctamente definidas y que aportan valor al producto, para que la planificación del sprint sea más eficaz.

Espero que haya servido de ayuda :-)

Yeray Darias about.me/yeray_darias

[Tana]

Buenos días!

Muchas gracias por las respuestas.

+Fran: Estoy hablando del product backlog. En esta etapa no estoy reforzando el que todo se re-escriba como historias de usuario, pero lo haré pronto (no creo poder meter todo el cambio a la vez).

Estoy de acuerdo en que conceptualmente hay varios niveles de detalle en las tareas, cuanto más lejos están en el tiempo, más "borrosas" / indefinidas, están.

Me gusta el concepto de iceberg, no lo conocía.

En resumen, las acciones que tomaré serán dividir el backlog en dos boards diferentes de Trello, una para el más largo plazo y cosas por definir y otro para el corto-medio plazo y tareas más definidas. Espero contarles los resultados.

Me sigue chirriando el tema de la herramienta. Llevo tiempo pensando en la necesidad de tener una en la que se permitan tableros de tres dimensiones:

• el eje x representa estado de una tarea, muy ligado al tiempo, moviéndose de izquierda a derecha, como es tradicional.
  
• El eje y representa la prioridad. Cuanto más arriba esté una tarea más prioridad tiene. No en todas las columnas, pero sí en general.
• El eje z representa la granularidad, el detalle. Podemos pasar de una vista de pájaro, más interesante para un CEO, product manager, a una vista más detallada para un desarrollador.

Llevo mucho tiempo pensando esto y el principal problema que le veo es mantener una relación entre la vista de pájaro y la detallada, pero un MVP con epics y user stories, podría ser suficiente para empezar, hacer pruebas y ver si es útil.

Al final lo ideal ideal para mí es tener un sistema con API muy completo y que haya multitud de vistas posibles como clientes, ya que a cada stakeholder le interesan unos aspectos en concreto.

Saludos y gracias de nuevo,

   Tana

[Fran Reyes Perdomo]

User Story Map que nos contó Xavi no te cuadra?
No recuerdo la herramienta que usaban, pero la combinaban con Trello.

Recientemente Jeff Patton ha sacado un libro sobre el tema:

http://shop.oreilly.com/product/mobile/0636920033851.do

Yo quiero darle una repasada buena a esta técnica y explorarla un poco más ;)
Saludos

[Raul Herranz]

Si te acuerdas de la herramienta avisa! Yo los USMaps los hago siempre en físico (con tarjetas).

Gracias!

[Tana]

A mí gusta mucho lo del User Story Map y llevo tiempo con ganas de tener un proyecto en el que poder usarlo, pero me da la sensación de que meterlo en un producto ya en marcha puede no ir tan bien.

Le echaré una pensada de todas formas.

Y gracias por el apunte del libro! :-)

[Yeray Darias Camacho]

Ayyyy chiquines, que tengo los sketchnotes de la charla de Xavi en el Flickr https://www.flickr.com/photos/ydarias/sets/72157641547766505/

En la última página está la referencia a la aplicación, se llama FeatureMap :-)

Yo creo que si se puede aplicar a un producto ya empezado, pero sí es cierto que hay que llevarlo con cuidado y no tomárselo como empezar de cero. Es decir que se puede representar a grandes rasgos lo que hay actualmente y luego evolucionar, pero no quito la parte de razón a que es más útil cuando estás empezando y quieres construir el walking skeleton que es lo que explicó Xavi.