こんにちはOptimal Biz Teleworkチームの伊藤です。
直近のスクラム開発の振り返りで、チームごとにバーンダウンチャートのグラフに差があることに気づきました。
理想的には毎日のデイリースクラムでバーンダウンチャートによる進捗を確認したいところですが、現実にはうまくいくチームとうまくいかないチームがありました。
※スプリントにおけるDoneの定義はどちらのチームも同じで、「QAによるテストが完了していること」です
こんな感じです。
うまくいかないチーム(チームA)のバーンダウンチャート
うまくいったチーム(チームB)のバーンダウンチャート
今回はそれぞれのチームの振り返りを聞いて、なぜ崖のようなバーンダウンチャートになってしまうのか考えてみたので紹介させていただきます！
原因1: バックログの粒度が大きい
チームAはQAがバックログをテスト可能になる日が2週間スプリントの中頃以降になっており、かつ1つのバックログのテストが大きくなるためテストにも時間がかかっていました。 結果、テストが完了しバックログがcloseされるタイミングはスプリント後半に寄ってしまうようでした。
チームBはバックログの粒度が小さく、1日で終わるバックログが存在するためQAのテストがスプリント開始の翌日には開始できるようにしていました。 そのためテストが完了しバックログがcloseされるタイミングが早くなり、結果的にバーンダウンチャートがスプリント開始直後から減り始めています。
今後やっていきたい対策
- バックログの粒度は可能な限り1日で実装が完了する大きさにする
原因2: 機能が完成してからテスト開始している
チームAのバックログは単独でテスト可能な粒度になっているため、実装が完了したものがデプロイされるとテスト開始となります。 しかし粒度が機能の単位として大きいため、「完成してからテスト」のような印象を受けました
チームBははバックログの粒度に合わせてテスト設計をしたり、小さいバックログも簡単なテストが可能なように工夫したりしていました。 また、テスト環境にデプロイされたものから優先的にテストする(Doneにすることを優先する)よう意識しているとのことでした。
今後やっていきたい対策
- バックログはテスト可能になるように意識して分解する
- チーム内でテスト設計を行っているメンバーとよく相談し、着手するバックログを選ぶ
結論
- コミュニケーション大事。全員がバックログをdoneに持っていくことを意識して開発する。
- バックログの大きさ大事。可能な限り小さくする
最後に
オプティムでは楽しみながらスクラムに挑戦するエンジニア、大規模スクラムを果敢に改善していくスクラムマスター・プロダクトオーナーを募集しています！
