¿Si Kanban es para incremento continuo, quiere esto decir que no debe usarse Kanban cuando se aplica Scrum con incremento por sprints?

En ambos marcos ágiles, Scrum y Kanban, se utilizan tableros. Aunque existe el término de tablero Scrum o scrumboard, usualmente se habla en ambos casos de tableros Kanban, lo que puede llevar a confusión. Lo importante es que en ambos casos se usan tableros como gestión visual para irradiar la información sobre lo que haya en marcha, así como para visualizar el flujo o la evolución del sprint.

En el caso de Scrum, caso iterativo, el tablero contiene todas las tareas del sprint, y durante el mismo progresan de columna de la pila de sprint a la columna de terminado. Con un vistazo al tablero se ve la situación global del sprint, tablero que suele incluir el gráfico burndown, que es propio de Scrum.

El caso de Kanban es distinto, se trata de incremento continuo. Continuamente entran elementos en la columna de tareas pendientes. En este caso la función principal del tablero es la de regular el flujo de trabajo. Eso se traduce en hacer que los elementos, tal como entren, se ejecuten lo antes posible, y progresen a la columna de terminado de la forma más optima posible, evitando cuellos de botella y tiempos de espera. Esta regulación se consigue ajustando el WIP (Work in Progress) de alguna o todas las columna del tablero. El WIP indica cuantos elementos pueden estar en una columna determinada a la vez. El ajuste del WIP dependerá de las formas de hacer cada empresa y puede requerir algunos meses de rodaje.

Ejemplo de tablero Kanban para desarrollo continuo con TDD - cortesía de Scrum Manager

La gran diferencia es la regulación, Kanban regula para que los elementos fluyan como en una balsa de aceite, mientras que en Scrum, representa la situación actual del sprint.

Para profundizar más en el tema recomiendo la lectura de "Kanban y Scrum - obteniendo lo mejor de ambos" de Henrik Kniberg & Mattias Skarin.