Метрики в Scrum и Kanban

Kanban имеет одну фатальную проблему — он не даёт точки отсечения сотрудника. scrum даёт. Если человек не выполняет спринты из раза в раз — плохой программист (каким бы хорошим он ни был — не делает спринты, какая от него польза?). А в kanban этой простой и ясной метрики нет.

Как же? Все как раз проще. Берете определенный класс задач по оценкам команды и смотрите на cycle time при их выполнении у каждого члена команды. Если отличается сильно у одного, то это повод разобраться. Возможно он всем помогает и благодаря ему вообще движется разработка. Что такое «человек не выполняет спринты» я вообще понять не могу. В Scrum как раз вся командная активность прячется за спринтом и разобраться кто хороший кто плохой потом не так просто.

Только основываясь на опыте Скрама, Канбан судить не берусь.
Лично в нашей команде главная метрика — успешность спринта, которая основывается на достижении поставленной в начале спринта цели.
К примеру, 8 из 10 задач в спринте крутятся вокруг внедрения нового модуля А. Цель — end-2-end реализация модуля А. Если цель достигнута (все 8 задач выполнены), значит спринт успешен. Даже несмотря на что возможно остальные 2 задачи не были стартованы.
Ориентироваться на Velocity я бы не стал. Если эта метрика растет, это не значит, что вы стали выпускать больший объем задач. Зачастую, если метрика и растет постоянно, то это показатель, что команда начинает давать более реалистичные оценки, не более того. Особенно это характерно для слаженных команд. Для команды из всех новых членов, характеристика должна постепенно улучшаться за счет повышения уровня коммуникации, более глубокие знания предметной области и т.д.