La guía Kanban

para equipos Scrum

Septiembre de 2019

Desarrollado y sostenido por Scrum.org, Daniel Vacanti y Yuval Yeret

Tabla de contenido

Propósito................................................. .................................................. ......................................... 3

Relación con la guía Scrum ............................................. .................................................. ............ 3

Definición de Kanban ............................................... .................................................. ....................... 3

Kanban con teoría de Scrum .............................................. .................................................. ............. 3

Flujo y empirismo ............................................... .................................................. ................... 3

Las métricas básicas de flujo ............................................. .................................................. ............. 3

La ley de Little: la clave para gobernar el flujo .......................................... .......................................... 4

Prácticas Kanban ................................................ .................................................. ........................... 4

Visualización del flujo de trabajo: el tablero Kanban .......................................... .......................... 5

Limitación del trabajo en curso (WIP) ........................................... .................................................. ..... 5

Gestión activa de elementos de trabajo en curso ........................................... ............................... 6

Inspeccionar y adaptar la definición de "flujo de trabajo" ......................................... ............................... 6

Eventos basados en flujo .............................................. .................................................. ........................... 7

El Sprint ................................................ .................................................. .................................. 7

Planificación de Sprint ................................................ .................................................. .......................... 7

Scrum diario ................................................ .................................................. ................................ 7

Revisión de Sprint ................................................ .................................................. ............................. 8

Retrospectiva del Sprint ................................................ .................................................. .................. 8

Incremento ................................................. .................................................. ..................................... 8

Nota al final ................................................. .................................................. ........................................ 8

Historia y reconocimientos ............................................... .................................................. ....... 9

© 2019 Scrum.org. Ofrecido para licencia bajo la licencia Attribution Share-Alike de Creative Commons, accesible en
http://creativecommons.org/licenses/by-sa/4.0/legalcode y también descrito en forma resumida en
http://creativecommons.org/licenses/ by-sa / 4.0 /. Al utilizar este Guía Kanban para equipos Scrum,
usted reconoce y acepta que ha leído y acepta regirse por los términos de la licencia Attribution Share-Alike de Creative
Commons.

La guía Kanban para equipos Scrum | Página 2

Propósito

La perspectiva basada en el flujo de Kanban puede mejorar y complementar el marco de Scrum y su implementación. Los equipos
pueden agregar prácticas Kanban complementarias ya sea que estén comenzando a usar Scrum o lo hayan estado usando todo el
tiempo.

La guía Kanban para equipos Scrum es el resultado de una colaboración entre miembros de la comunidad Scrum.org
y líderes de la comunidad Kanban. Juntos, están detrás La guía Kanban para equipos Scrum. Comparten la creencia
de que los profesionales del desarrollo de productos pueden beneficiarse de la aplicación de Kanban junto con
Scrum.

Relación con la guía Scrum

Esta guía no reemplaza ni descuenta ninguna parte de La guía de Scrum. Está diseñado para mejorar y expandir las prácticas
de Scrum. Esta guía asume que el lector está operando un proceso usando el marco Scrum. Por lo tanto, La guía de Scrum se
aplica en su totalidad.

Definición de Kanban
Kanban (n): una estrategia para optimizar el flujo de valor a través de un proceso que utiliza un sistema de extracción limitado visual de trabajo en

progreso.

Kanban con teoría de Scrum

Flujo y empirismo
El concepto de flujo es fundamental para la definición de Kanban. El flujo es el movimiento de valor en todo el sistema de
desarrollo de productos. Kanban optimiza el flujo al mejorar la eficiencia, la eficacia y la previsibilidad generales de un
proceso.

Optimizar el flujo en un contexto de Scrum requiere definir qué significa flujo en Scrum. Scrum se basa en la teoría del control de
procesos empíricos o empirismo. La clave para el control de procesos empíricos es la frecuencia del ciclo de transparencia, inspección y
adaptación, que también podemos describir como el tiempo de ciclo a través del circuito de retroalimentación.

Cuando las prácticas Kanban se aplican a Scrum, proporcionan un enfoque en mejorar el flujo a través del ciclo de
retroalimentación; optimizando la transparencia y la frecuencia de inspección y adecuación tanto del producto como del proceso.

Las métricas básicas del flujo

Las cuatro métricas básicas de flujo que los equipos Scrum que usan Kanban deben rastrear son las siguientes:

© 2019 Scrum.org. Ofrecido para licencia bajo la licencia Attribution Share-Alike de Creative Commons, accesible en
http://creativecommons.org/licenses/by-sa/4.0/legalcode y también descrito en forma resumida en
http://creativecommons.org/licenses/ by-sa / 4.0 /. Al utilizar este Guía Kanban para equipos Scrum,
usted reconoce y acepta que ha leído y acepta regirse por los términos de la licencia Attribution Share-Alike de Creative
Commons.

La guía Kanban para equipos Scrum | Página 3

 • Trabajo en progreso (WIP): La cantidad de elementos de trabajo iniciados pero no terminados. Tenga en cuenta la
diferencia entre la métrica WIP y las políticas que utiliza un equipo Scrum para limitar WIP. El equipo puede usar la métrica
WIP para brindar transparencia sobre su progreso hacia la reducción de su WIP y la mejora de su flujo.

• Tiempo del ciclo: La cantidad de tiempo transcurrido entre el inicio de un elemento de trabajo y su finalización.

• Edad del artículo de trabajo: La cantidad de tiempo entre el inicio de un elemento de trabajo y la hora actual. Esto se aplica solo a

los elementos que aún están en progreso.

• Rendimiento: El número de elementos de trabajo terminados por unidad de tiempo.

La ley de Little: la clave para gobernar el flujo

Un principio clave que rige la teoría del flujo es la Ley de Little, que es una directriz que establece la siguiente relación:

La Ley de Little revela que, en general, para un proceso dado con un rendimiento dado, cuantas más cosas trabaje en
un momento dado (en promedio), más tiempo llevará terminar esas cosas (en promedio).

Si los tiempos de ciclo son demasiado largos, la primera acción que los equipos Scrum deben considerar es reducir el WIP. La mayoría de los

demás elementos de Kanban se basan en la relación entre WIP y el tiempo de ciclo.

La Ley de Little también nos muestra cómo la teoría del flujo se basa en el empirismo al usar la métrica de flujo y los datos para ganar

transparencia en el flujo histórico y luego usar esos datos para informar los experimentos de adaptación e inspección de flujo.

Prácticas Kanban
Los equipos Scrum pueden lograr la optimización del flujo mediante el uso de las siguientes cuatro prácticas:

• Visualización del flujo de trabajo

• Limitación del trabajo en curso (WIP)

• Gestión activa de elementos de trabajo en curso

• Inspeccionar y adaptar la definición del equipo de "flujo de trabajo"

Definición de "flujo de trabajo"

Las cuatro prácticas Kanban están habilitadas por la definición de "Flujo de trabajo" del Equipo Scrum. Esta definición representa la
comprensión explícita de los miembros del equipo Scrum de cuáles son sus políticas para seguir las prácticas Kanban. Esta
comprensión compartida mejora la transparencia y permite la autoorganización.

© 2019 Scrum.org. Ofrecido para licencia bajo la licencia Attribution Share-Alike de Creative Commons, accesible en
http://creativecommons.org/licenses/by-sa/4.0/legalcode y también descrito en forma resumida en
http://creativecommons.org/licenses/ by-sa / 4.0 /. Al utilizar este Guía Kanban para equipos Scrum,
usted reconoce y acepta que ha leído y acepta regirse por los términos de la licencia Attribution Share-Alike de Creative
Commons.

La guía Kanban para equipos Scrum | Página 4

Tenga en cuenta que el alcance de la definición de "Flujo de trabajo" puede extenderse más allá del Sprint y el Sprint Backlog.
Por ejemplo, la definición de "Workflow" de un equipo Scrum puede abarcar el flujo dentro y / o fuera del Sprint.

Crear y adaptar la definición de "flujo de trabajo" es la responsabilidad de los roles relevantes en el equipo Scrum como se
describe en la Guía de Scrum. Nadie fuera del Scrum Team debería decirle al Scrum Team cómo definir su “Workflow”. De
manera similar, nadie fuera del equipo de desarrollo, incluido el propietario del producto o el Scrum Master, debe decirle al
equipo cómo definir los aspectos del flujo de trabajo que son internos al trabajo del equipo de desarrollo.

Visualización del flujo de trabajo: el tablero Kanban

La visualización usando el tablero Kanban es la forma en que Scrum Team hace que su flujo de trabajo sea transparente. La configuración de la

placa debe generar las conversaciones adecuadas en el momento adecuado y sugerir de manera proactiva oportunidades de mejora.

La visualización debe incluir lo siguiente:

• Puntos definidos en los que el Equipo Scrum considera que el trabajo ha comenzado y terminado.

• Una definición de los elementos de trabajo: las unidades individuales de valor (valor de las partes interesadas, valor del conocimiento,

valor de mejora del proceso) que fluyen a través del sistema de ScrumTeam (lo más probable es que los elementos de la cartera de

productos (PBI)).

• Una definición del flujo de trabajo establece que los elementos de trabajo fluyen de principio a fin (de los cuales debe
haber al menos un estado activo).
• Políticas explícitas sobre cómo fluye el trabajo a través de cada estado (que pueden incluir elementos de la definición de "Listo" de

un Equipo Scrum y políticas de extracción entre etapas).

• Políticas para limitar el trabajo en curso (WIP).

Limitación del trabajo en curso (WIP)

Work in Progress (WIP) se refiere a los elementos de trabajo que el Equipo Scrum ha comenzado pero que aún no ha terminado.

Los equipos Scrum que usan Kanban deben limitar explícitamente el número de estos elementos de trabajo en curso. Un equipo Scrum puede

limitar explícitamente el WIP como mejor le parezca, pero debe ceñirse a ese límite una vez establecido.

El efecto principal de limitar WIP es que crea un sistema de extracción. Se llama sistema de extracción porque el equipo comienza a trabajar (es

decir, tira) en un elemento cuando está claro que tiene la capacidad para hacerlo. Cuando el WIP cae por debajo del límite definido, esa es la

señal para comenzar un nuevo trabajo. Tenga en cuenta que esto es diferente de un sistema push, que exige que el trabajo comience en un

artículo siempre que se solicite.

Limitar WIP ayuda a fluir y mejora la autoorganización, el enfoque, el compromiso y la colaboración del equipo Scrum.

© 2019 Scrum.org. Ofrecido para licencia bajo la licencia Attribution Share-Alike de Creative Commons, accesible en
http://creativecommons.org/licenses/by-sa/4.0/legalcode y también descrito en forma resumida en
http://creativecommons.org/licenses/ by-sa / 4.0 /. Al utilizar este Guía Kanban para equipos Scrum,
usted reconoce y acepta que ha leído y acepta regirse por los términos de la licencia Attribution Share-Alike de Creative
Commons.

La guía Kanban para equipos Scrum | Página 5

Gestión activa de elementos de trabajo en curso

Limitar WIP es necesario para lograr el flujo, pero por sí solo no es suficiente. La tercera práctica para establecer el flujo es la
gestión activa de los elementos de trabajo en curso. Dentro del Sprint, esta gestión por parte del equipo de desarrollo puede
tomar varias formas, que incluyen, entre otras, las siguientes:

• Asegurarse de que los elementos de trabajo solo se incorporen al flujo de trabajo aproximadamente al mismo ritmo que abandonan el

flujo de trabajo.

• Asegurarse de que los elementos de trabajo no envejezcan innecesariamente.

• Responder rápidamente a elementos de trabajo bloqueados o en cola, así como a aquellos que exceden el nivel de tiempo de ciclo

esperado del equipo (consulte Expectativa de nivel de servicio - SLE).

Expectativa de nivel de servicio (SLE)

Una expectativa de nivel de servicio (SLE) pronostica cuánto tiempo debería tardar un elemento determinado en fluir de principio a fin dentro del

flujo de trabajo del ScrumTeam. El ScrumTeam utiliza su SLE para encontrar problemas de flujo activo e inspeccionar y adaptarse en casos de caer

por debajo de esas expectativas.

El SLE en sí tiene dos partes: un período de días transcurridos y una probabilidad asociada con ese período (por ejemplo, el 85% de los

elementos de trabajo deben estar terminados en ocho días o menos). El SLE debe basarse en el tiempo de ciclo histórico del Scrum Team y,

una vez calculado, el Scrum Team debe hacerlo transparente. Si no existen datos históricos de tiempo de ciclo, el ScrumTeam debe hacer su

mejor conjetura y luego inspeccionar y adaptarse una vez que haya suficientes datos históricos para hacer un cálculo adecuado de SLE.

Inspeccionar y adaptar la definición de "flujo de trabajo"

El equipo Scrum utiliza los eventos Scrum existentes para inspeccionar y adaptar su definición de "flujo de trabajo", lo que ayuda
a mejorar el empirismo y optimiza el valor que ofrece el equipo Scrum.

Los siguientes son aspectos de la definición de "flujo de trabajo" que el equipo Scrum podría adoptar:

• Políticas de visualización, por ejemplo, estados de flujo de trabajo, ya sea cambiando el flujo de trabajo real o
aportando más transparencia a un área en la que el equipo quiere inspeccionar y adaptarse.

• Políticas de cómo trabajamos: pueden abordar directamente un impedimento. Por ejemplo, ajustar los límites de WIP y SLE,
cambiar el tamaño del lote o la frecuencia con la que se retiran los artículos entre los estados puede tener un impacto
dramático.

© 2019 Scrum.org. Ofrecido para licencia bajo la licencia Attribution Share-Alike de Creative Commons, accesible en
http://creativecommons.org/licenses/by-sa/4.0/legalcode y también descrito en forma resumida en
http://creativecommons.org/licenses/ by-sa / 4.0 /. Al utilizar este Guía Kanban para equipos Scrum,
usted reconoce y acepta que ha leído y acepta regirse por los términos de la licencia Attribution Share-Alike de Creative
Commons.

La guía Kanban para equipos Scrum | Página 6

Eventos basados en flujo

Kanban en un contexto Scrum no requiere ningún evento adicional a los descritos en La guía de Scrum. Sin embargo, el uso de una
perspectiva basada en el flujo y el uso de métricas de flujo en los eventos de Scrum fortalece el enfoque empírico de Scrum.

El Sprint
Las prácticas complementarias Kanban no reemplazan al Sprint de Scrum. Incluso en entornos donde se desea / logra un flujo continuo,
el Sprint sigue siendo una cadencia o un latido regular para la inspección y adaptación tanto del producto como del proceso. Los equipos
que usan Scrum con Kanban usan los eventos de Sprint como un circuito de mejora de la retroalimentación al inspeccionar y adaptar de
manera colaborativa su definición de "flujo de trabajo" y la métrica de flujo.

Las prácticas de Kanban pueden ayudar a los equipos de desarrollo a mejorar el flujo y crear un entorno en el que las decisiones se toman en

el momento oportuno a lo largo del Sprint en función de la inspección y la adaptación. En este entorno, los equipos de desarrollo confían en el

objetivo de Sprint y en una estrecha colaboración con el propietario del producto para optimizar el valor entregado en el Sprint.

Planificación de Sprint

Una reunión de Sprint Planning basada en el flujo utiliza métricas de flujo como ayuda para desarrollar el Sprint Backlog. Por ejemplo,
usar el rendimiento histórico para comprender la capacidad del equipo Scrum para el próximo Sprint.

Scrum diario

Un Scrum diario basado en el flujo se centra en garantizar que el equipo Scrum esté haciendo todo lo posible para mantener un flujo
constante. Si bien el objetivo del Scrum diario sigue siendo el mismo que se describe en La guía de Scrum, la reunión en sí tiene lugar
alrededor del tablero Kanban y se centra en dónde falta el flujo y en qué acciones puede tomar el Equipo Scrum para recuperarlo.

Las cosas adicionales a considerar durante un Scrum diario basado en flujo incluyen lo siguiente:

• ¿Qué elementos de trabajo están bloqueados y qué puede hacer el equipo de desarrollo para desbloquearlos?

• ¿Qué trabajo fluye más lento de lo esperado? ¿Cuál es la antigüedad del elemento de trabajo de cada elemento en curso?

¿Qué elementos de trabajo han violado o están a punto de violar su SLE y qué puede hacer el Equipo Scrum para completar

ese trabajo?

• ¿Existe algún factor que pueda afectar la capacidad del equipo Scrum para completar el trabajo hoy que no esté
representado en el tablero?
• ¿Hemos aprendido algo nuevo que pueda cambiar lo que el Equipo Scrum ha planeado trabajar a continuación?

© 2019 Scrum.org. Ofrecido para licencia bajo la licencia Attribution Share-Alike de Creative Commons, accesible en
http://creativecommons.org/licenses/by-sa/4.0/legalcode y también descrito en forma resumida en
http://creativecommons.org/licenses/ by-sa / 4.0 /. Al utilizar este Guía Kanban para equipos Scrum,
usted reconoce y acepta que ha leído y acepta regirse por los términos de la licencia Attribution Share-Alike de Creative
Commons.

La guía Kanban para equipos Scrum | Página 7

 • ¿Hemos roto nuestro límite de trabajo en curso? ¿Y qué podemos hacer para asegurarnos de poder completar el trabajo en curso?

Revisión de Sprint

La ScrumGuide proporciona un esquema detallado de Sprint Review. La inspección de la métrica de flujo de Kanban como parte de la revisión

puede crear oportunidades para nuevas conversaciones sobre el seguimiento del progreso hacia un objetivo. La revisión del rendimiento puede

proporcionar información adicional cuando el propietario del producto analiza las posibles fechas de entrega.

Retrospectiva del Sprint

Una Retrospectiva de Sprint basada en el flujo agrega la inspección de métricas y análisis de flujo para ayudar a determinar qué
mejoras puede hacer ScrumTeam en sus procesos. El equipo Scrum que usa Kanban también inspecciona y adapta la definición de
"flujo de trabajo" para optimizar el flujo en el próximo Sprint. El uso de un diagrama de flujo acumulativo para visualizar el WIP de un
equipo Scrum, el tiempo de ciclo aproximado promedio y el rendimiento promedio puede ser valioso.

Además de la Retrospectiva del Sprint, el Equipo Scrum debe considerar aprovechar las oportunidades de inspección y
adaptación de procesos a medida que surgen a lo largo del Sprint.

De manera similar, los cambios en la definición de "flujo de trabajo" de un equipo Scrum pueden ocurrir en cualquier momento. Debido a que

estos cambios tendrán un impacto material en el desempeño del equipo Scrum, los cambios realizados durante la cadencia regular proporcionada

por el evento Sprint Retrospective reducirán la complejidad y mejorarán el enfoque, el compromiso y la transparencia.

Incremento

Scrum requiere que el equipo cree (como mínimo) un Incremento de producto "Listo" potencialmente liberable en cada Sprint. El
empirismo de Scrum fomenta la creación de múltiples incrementos liberables durante el Sprint para permitir una inspección rápida y
adaptar los bucles de retroalimentación. Kanban ayuda a administrar el flujo de estos ciclos de retroalimentación de manera más explícita
y permite al Equipo Scrum identificar los cuellos de botella, las limitaciones y los impedimentos para una entrega de valor más rápida y
continua.

Nota final

Scrum no es un proceso ni una técnica. Es un marco dentro del cual las personas pueden abordar problemas complejos de
adaptación al tiempo que entregan productos del mayor valor posible de manera productiva y creativa. Como La guía de Scrum señala
que funciona bien como contenedor de otras técnicas, metodologías y prácticas.

© 2019 Scrum.org. Ofrecido para licencia bajo la licencia Attribution Share-Alike de Creative Commons, accesible en
http://creativecommons.org/licenses/by-sa/4.0/legalcode y también descrito en forma resumida en
http://creativecommons.org/licenses/ by-sa / 4.0 /. Al utilizar este Guía Kanban para equipos Scrum,
usted reconoce y acepta que ha leído y acepta regirse por los términos de la licencia Attribution Share-Alike de Creative
Commons.

La guía Kanban para equipos Scrum | Página 8

Las prácticas de optimización de flujo de Kanban brindan a los equipos Scrum oportunidades adicionales para inspeccionar lo correcto, en el

momento adecuado y, luego, según esa inspección, adaptarse según sea necesario. El hiperconcentrado de Kanban en la transparencia, la

visualización y el flujo maximiza la retroalimentación, el empirismo y, en última instancia, la entrega de valor.

Historia y reconocimientos
El conjunto de prácticas comúnmente conocidas como Kanban se originó principalmente en 2006 en un equipo de Corbis, una empresa
de licencias de medios propiedad de Bill Gates. Esas prácticas se extendieron rápidamente para abarcar una comunidad internacional
amplia y diversa que a lo largo de los años siguió mejorando y evolucionando el enfoque.

Esta guía fue desarrollada en colaboración por Scrum.org, su comunidad de entrenadores profesionales de Scrum, Steve
Porter, Yuval Yeret y Daniel Vacanti.

Un agradecimiento especial a Louis-Philippe Carignan, Charles Bradley, Jose Casal, Andy Hiles y Jesse Houwing por sus
contribuciones. También tenemos una deuda de gratitud con todos aquellos profesionales que en el pasado han contribuido a hacer
de Kanban una estrategia viable y exitosa de Lean Agile.

© 2019 Scrum.org. Ofrecido para licencia bajo la licencia Attribution Share-Alike de Creative Commons, accesible en
http://creativecommons.org/licenses/by-sa/4.0/legalcode y también descrito en forma resumida en
http://creativecommons.org/licenses/ by-sa / 4.0 /. Al utilizar este Guía Kanban para equipos Scrum,
usted reconoce y acepta que ha leído y acepta regirse por los términos de la licencia Attribution Share-Alike de Creative
Commons.

La guía Kanban para equipos Scrum | Página 9