Este documento describe el uso de un tablero kanban multi-proyecto para equipos ágiles que trabajan en múltiples proyectos simultáneamente. Explica que un contexto multi-proyecto es común cuando un equipo pequeño está a cargo de varios proyectos o productos al mismo tiempo debido a oportunidades de negocio o demanda continua. Propone usar un tablero kanban que permita administrar los backlogs, sprints y flujo de trabajo de cada proyecto de manera independiente pero integrada para el mismo equipo.

1. Agilismo at
work

2. Integrantes
 Doris
Quiroz
 Sonia Posligua
 Sergio Bravo
 Pedro Ostaiza

3.  Agilismo
at work (Agilismo en el trabajo)

4. Multi-kanban
 un
tablero kanban para contextos multiproyecto

5.  Antes
de empezar, es importante
puntualizar que con "multi-proyecto" se
refiere a la situación en la cual un equipo
ágil (pequeño) está encargado de varios
(muchos) proyectos

6.  Multi-kanban,
en este último caso ya hay
bastante información bajo la etiqueta
"Scrum de Scrums",

7.  Es
decir, dividir un proyecto de gran
tamaño (y con muchas personas
involucradas) en áreas y equipos, de
forma que cada equipo esté dedicado a
cada área del producto/servicio.

8.  Un
escenario multi-proyecto no es un
tema usualmente abordado en la
bibliografía ágil de referencia (escrita por
los gurús del agilismo).

9. 
Parece que se asume como normal que un
equipo en un contexto multi-proyecto, tenga
que por ejemplo, trabajar con varios tableros
kanban a la vez,

O que de manera artificial se tienda a incluir
en un Backlog o sprint ítems que
corresponden a diferentes
productos/servicios.

10. ¿Por qué un contexto multi-proyecto es una
realidad difícil de cambiar?

11.  Porque
existen oportunidades de negocio
y no se cuenta con suficiente personal
para abordarlas cada una de forma
exclusiva

12.  Porque
los productos/servicios resultantes
de un proyecto seguirán teniendo
demanda mientras estén en producción.

13.  Multi-kanban

14.  Un
agente (miembro) participa en
equipos.

15.  Un
equipo tiene agentes.

16. 
Un equipo está encargado de productos
o servicios.

17.  Un
producto o servicio tiene un Backlog
(que contiene el trabajo pendiente
priorizado y no incluido aun en sprints).

18.  Un
producto o servicio tiene definidos
sprints con trabajo que se ha movido
desde el Backlog.

19. 
En caso que un producto o servicio no trabaje
con sprints (por ejemplo, porque su demanda no
es planificable), todo el trabajo estará en el
Backlog y directamente allí se abordará.