Voici une analogie intéressante qui m'a été exposée il y a peu :

Si on considère une équipe projet comme une usine de transformation des besoins d'un client en un produit final, on peut lui appliquer la théorie des contraintes comme dans une usine traditionnelle.
Dans ce cas, on tente de réduire le volume des encours, c'est à dire les produits intermédiaires déjà réalisés mais qui n'ont pas encore été intégré dans le produit final : spécifications écrites, modèle de conception, et même morceaux de code... Ils représentent de l'argent investi stocké dans l'entrepôt du logiciel. Qui plus est ce stock est une denrée périssable, car les besoins évoluent souvent très vite.
Les méthodes agiles essaient donc de minimiser ce stock et permettre au client de changer d'idée facilement sans impacter la réussite du projet.

A quand la mise en oeuvre d'un kanban de Use Cases ?