こんにちは、角田です。 今回はスクラムでの失敗談です。
PBIへ取り掛かるタイミング
みなさんは、プロダクトバックログアイテム（PBI）へ取り掛かるタイミングはいつでしょうか？DROBEでは以前は、 スプリントバックログへ移し、スプリントが始まったら でした。一見正しそうなのですが、肝心なことを見落としていたため、効率的にデリバリーできない状態になっていました。
遅かった影響範囲調査
というのも、スプリントバックログへ移しスプリントが始まった後で、影響範囲の調査や該当箇所の洗い出しをしていました。この影響範囲調査や該当箇所の洗い出しにより、スプリント内での作業時間が圧迫された結果、非効率になっていました。
ディスカバリー不足だった
この時のPBIは、ほぼ『やることリスト』化していたのが大きな原因ではないかと思っています。PBIを作る際に、開発チームとPBI作成者とのコミュニケーションが不足し、本来であればディスカバリーを行う必要があったところを、行わずにプロダクトバックログ・スプリントバックログに積んでいました。
改善したこと
これを受け、現在のDROBEでは以下のことを考えながら行動しています。
ディスカバリーを行う
影響範囲や該当箇所洗い出しなどの調査や、技術的な確認については『ディスカバリー』というで最小コストで学びを得るステップでやろうとチームに共有し、実践しています。PBI作成者にも作成時に悩むことがあれば、いつでも開発チームへ相談するよう連絡し、早い段階からコミュニケーションをとって、PBIの精査を行うようにしはじめました。
ディスカバリーとデリバリーの関係
ディスカバリーはデリバリーしようと思うアイデアやストーリーの『リスク』を軽減して学びを得る作業をスプリントに固執せず自由なタイミングで行っていきます。アイデアにユーザやビジネス的に価値があるか検証したり、技術的に実現が可能か調べたりして、リスクを軽減していきます。リスクが軽減していけば、あとはスプリントで開発を行う作業を行えばデリバリーするだけです。
前述のスプリント開始後に影響範囲の調査を行っていたのは、まだPBI的にリスクがある状態であり、スプリント開始よりも前にディスカバリーを行っていれば、開発作業だけに集中することができていました。
定期的な『次スプリントのPBI作成・精査』の促進
スプリントが始まって2,3日経ったあたりから、次のスプリントのPBIについて確認をとるようにしています。これにより、作成途中のPBIを早めに認識して、コミュニケーションをとりやすくしています。
まだまだこれから
上記の改善を行い、以前よりは効率的なデリバリーができるようになりました。とはいえ、まだまだな感じは拭えないですし、また別の課題が出てき始めています。課題が山積みだとは思いますが、以前参加したLeSSの夜明けで参加者の方とお話ししていた際、「常に課題にぶち当たる」とおっしゃってたので、こんなものだと思って、日々改善していこうと思います。
