続・doiluxの検証生活

メインはQiitaで、こちらはQiitaに掲載するのにそぐわない内容(技術的な要素が比較的薄いもの)のものを掲載。なお、本ブログの内容は個人の意見を反映したものであり、所属組織のスタンスを反映したものではありません。

バーンダウンしない理由

チームでバーンダウンしない理由を考えてみた。

割り込みタスクが入る

どこから入った割り込みかで話が変わってくる。

プロジェクト外

勤務管理の提出が明日までだった!!とか、前のプロジェクトでバグが見つかったからヘルプ!!とか、ペットが死んだから休みます!!とか。有効な対処法はない

プロジェクト内

対処法はやらないこと。バックログに積んで次スプリントで対応する。ただ、スプリント期間が2Wとかだと、取りかかるまで最大2W開くのでこの方針はとりづらいかも(個人的にはスプリント期間は3日くらいがいいとか思ってたりする)あと、「割り込みを許可するけど、その分優先度低い何かをバックログに戻します!!」ってやり方もあると思うけど、色々と調整とかのコストがかかる(こういう調整コストって結構馬鹿にならないと思っている)

見積もりがあまい

1ptのボリュームがずれる

チーム全体の成長と自信によって、1ptのボリュームが増えるパターン。時間ではなく作業量で見積もりを出すことと、基準となるタスクをこまめに確認すべし。

不確定部分を見積もっている(※1)

例えば「お客様が販売ページからXXXを申し込むことができる」ってストーリーがあったときに、この中には設計、製造、テスト全部含まれていると思うが、設計できてないのに製造のボリュームを見積もることはできないはず。ストーリーを作業量が確定している部分(ここでは設計)と確定していない部分(ここでは製造以降)に分けて、スプリント内ですることは作業量が確定しているストーリーのみにする。ただし、このやり方をする場合は2Wスプリントとかだと、設計から製造に取りかかるまで最大2W開くのでスプリント期間は短くすべし。

まとめ

バーンダウンしない理由は大きく2つ。割り込みタスクが発生することと見積もりがあまいこと。どちらの場合も不確定要素を減らすことが大事。そのためにはスプリント期間は短くした方が色々とやりやすいと思う。

追伸

チームで「正確な見積もりをあきらめて、ポイントがぶれるたびにプロダクトオーナーと都度タスクを調整する」というやり方を取ったことがあったが、おすすめしない。調整のコストが結構かかるのと、ベロシティがはかりづらい(作業がすすんでいないのか、作業量が増えたのかわかりづらい)のと、「バーンダウンしなくてもしかたない」みたいな空気になってしまうから。

※1:redmineのバーンダウンチャートが日数とともにタスク量が増えて、1日のベロシティが下がっていくような場合は多分これが理由。