¿Qué es downstream (aguas abajo) en Kanban?

En las filosofías Agile y Lean, el downstream (aguas abajo) abarca todas las actividades desde que una solicitud entra al flujo de trabajo comprometido hasta que el servicio o producto se entrega al cliente. Es la parte del proceso donde el equipo "construye": diseño técnico, desarrollo, pruebas, revisión y despliegue.

La metáfora viene de un río. El trabajo fluye corriente abajo (downstream) desde el punto en que se decide hacerlo hasta que llega a manos del cliente. Todo lo que pasa antes de esa decisión es corriente arriba (upstream).

La distinción entre ambos términos es clave para entender dónde se generan los retrasos y los costes de un proceso.

El upstream es donde se descartan ideas y se selecciona el trabajo que merece la pena construir. El downstream es donde ese trabajo ya comprometido se transforma en valor entregado. Cuanto mejor filtre el upstream, menos desperdicio arrastra el downstream.

Kanban visualiza el flujo downstream como las columnas del tablero que van desde "comprometido" hasta "entregado". El objetivo es que el trabajo fluya sin detenerse, evitando acumulaciones que generan cuellos de botella.

Para gestionar el downstream, Kanban aplica:

• Límites de WIP: restringir cuántos elementos hay en curso simultáneamente para acelerar la finalización.
• Sistema pull: iniciar trabajo nuevo solo cuando hay capacidad disponible aguas abajo.
• Gestión activa del flujo: detectar y desbloquear elementos estancados antes de empezar otros.

Las métricas que miden la eficiencia del downstream se centran en el tiempo y el ritmo de entrega:

• Lead Time: tiempo total desde que la solicitud entra al sistema hasta que se entrega. Es la métrica que percibe el cliente.
• Cycle Time: tiempo que un elemento pasa en proceso activo dentro del downstream, desde que se empieza a trabajar en él hasta que se completa.
• Throughput: cantidad de elementos entregados por unidad de tiempo (por ejemplo, tickets por semana).

Reducir el Lead Time y estabilizar el Cycle Time son los objetivos habituales al optimizar el downstream, ya que reflejan directamente la velocidad con la que el equipo convierte solicitudes en valor.

Scrum no usa el término de forma explícita, pero el trabajo downstream ocurre dentro del Sprint: una vez que un elemento entra al Sprint Backlog, el equipo lo desarrolla, prueba e integra hasta dejarlo terminado según la Definition of Done. La gestión del Product Backlog por parte del Product Owner sería la parte upstream del proceso.

¿Por qué importa separar upstream y downstream?

Porque los problemas se diagnostican distinto. Si entregas tarde por culpa del upstream (priorizas mal, el trabajo llega mal definido), optimizar el downstream no sirve de nada. Separarlos ayuda a saber dónde está el verdadero cuello de botella.

¿Downstream es lo mismo que "fase de desarrollo"?

No exactamente. El desarrollo es parte del downstream, pero el downstream incluye también testing, revisión, despliegue y cualquier actividad necesaria hasta la entrega final al cliente.

¿Cómo se acelera el downstream?

Limitando el WIP, eliminando bloqueos rápido, reduciendo el tamaño de los elementos de trabajo y mejorando la calidad del trabajo que entra desde el upstream para evitar retrabajo.