解決したい課題
落ちないバーンダウンチャート
例えば、スクラムを採用しているケースで、チケット量は消化しているにも関わらず、想定通りにバーンダウンしないことがある。結果として、仕事量をこなしたと思った割には、スプリント終了後にリリースできる機能がほとんどないということが生じることがある。何が起きたのか、コレガワカラナイ。
解決方法
チケット消化率ではなく、Feature/Storyの完了率に着目する。
例えば、Atlassian社のJIRAを使っている場合、StoryをSub-taskに分解して、具体的な作業内容に応じたチケットを作ることができる。一方で、バーンダウンするか否かの判定は、Sub-taskではなく、その親であるStoryが完了したか否かでカウントされる。従って、Storyを完了できなければ、本当の意味での「完了」とは言えない。
ちなみに、「Feature」の本来の意味は、それ単体でもリリース可能なプロダクトの機能のことを指す(『BDD in Action』第4章)。
結論としては、スプリントの本来の目的である「リリース可能なプロダクトの機能の完成」に意識を向けさせる数値を使った方が良い、ということである。
利点
- チームメンバーおよび関係者の意識を、細分化した個別タスクの完了よりも、リリース可能なプロダクトの機能の完成に向けさせやすくなる。
- スプリント終了後にリリースできる機能を増やせる可能性を高められる。
- →Velocityの向上
注意点
指示されたことを黙々とやる「労働集約型」の開発に慣れている場合、この発想が出てこない可能性がある。初めのうちは、経験のあるアジャイルコーチの助力を仰いだ方が良いかもしれない。
補足
特になし。
関連するメトリクス
参考文献・資料
現場実践主義としてのリーン開発とアジャイル from Rakuten, Inc(26ページ以降)
CHANGELOG
- 2015/07/31 第1版公開
- 2015/08/01 「関連するメトリクス」に「Cumulative Flow Diagram (CFD)」を追加