これは、豆蔵デベロッパーサイトアドベントカレンダー2022第15日目の記事です。

アジャイルを実践していると、ここはどうしたらいいんだろう、という疑問が度々発生すると思います。
弊社のアジャイルチームには、そんなアジャイルに対する質問が日々社員から飛んできます。
広くアジャイルを実践している方々の役に立つのではないかと思い、そんなアジャイルに対する質疑応答をここに公開します。

ユーザーストーリーの見積もりとタイミング

質問

『Clean Agile 基本に立ち戻れ』のP43で終了日を予測していますが、全てのユーザーストーリーを、プランニングポーカーなどで見積もっているのでしょうか？
見積もるならば、イテレーションゼロでやるってことなのでしょうか？

Information

イテレーションゼロとは
イテレーションを始める前の準備期間です。イテレーションを始める前に検証しておいたほうが良いことや、環境準備などをここで行います。

回答

全てのユーザーストーリーを何かしらの手法で見積もっています。
何かしら、というのはプランニングポーカーに限らず、個人(専門家)の意見や特定のユーザーストーリーとの対比での見積もりも存在します。
上記の要素が複合的に含まれるプランニングポーカーが結局一番うまい見積もりなのではと『アジャイルな見積りと計画づくり』では示されています。
タイミングはイテレーションゼロか最初のイテレーションのプランニングで行います。

解説

『アジャイルな見積りと計画づくり』でも『Clean Agile 基本に立ち戻れ』の源流であるXPでも、実は全体見積りしています。

以下、ある程度でも作るものが決まっており、プロジェクト形式の場合を想定します（もっとR&D的な要素が高ければ別の話になります）。

アジャイル開発ではおそらく以下の3段階で見積りします。
それぞれ「何のための」見積りかが、重要だと思っています。

プロジェクトを立ち上げる時（社内で開発承認等を通すため）
イテレーション（スプリント）ゼロ
イテレーションごとのリファインメントやプランニング

1はアジャイルかどうかは無関係なのでいいとして。

2は、全体の見通しを立てたい時には、行います。
例えば、リリースバーンダウンチャートを書きたい時とか。
大事なのは、何のための見積りか、です。
a. 実際に開発をするチームで全体の見通しを立てる
b. チームで全体の要件をよりよく理解する
aが普通に言われることですが、bも私は重要なんじゃないかと思っています。

3は、ご存じですよね。
次のイテレーションでどこまでできそうか、の見通しを立てるための見積りです。

上記に対する質問者の返信

イテレーション毎：イテレーションに入れそうなストーリー群を再見積もりして、イテレーションに入りそうか見る
イテレーションゼロ：とりあえず、全部見積りして、バーンダウンチャートとか書けるようにする＆要件の理解
ということで合っていますか？

回答

はい、OKです。

タスクに見積りを入れる？

質問

アジャイルでは、タスク分割した時に、タスクに見積って入れないんですか？
CCPM（クリティカル・チェーン・プロジェクト・マネジメント）だと、タスクに見積を入れてたのですが、ざっくり一日や半日に収まるだろうタスクに分ければ十分なので、いちいち見積しない、との認識で良かったでしょうか？

回答

タスク見積りもしますよ。
プランニングで、ストーリーポイントからどこまでできそうかを考えて、それをタスク分解、タスクには時間見積りを入れることが多いです。
タスク見積り時間を足して、これはどう考えても今回のイテレーションには入らないよね、とかなったら、その時点でPOと再度相談、とか。このあたりの細かい運用はチームによって多少違うかもしれません。

バーンダウンチャートで間に合わなさそうな時でも残業はしない？

質問

アジャイルのバーンダウンチャートって、ベロシティを求めることや、そもそもチームが長続きすることを考えるので、イテレーションゴールに間に合わないそうならば、開発チーム内で良い方法を考えて対処はする。それでも無理な分は、残業しない（※特に「週40時間労働」のプラクティスを入れている場合）で、ＰＯとストーリーを減らす算段をする、ということで良かったでしょうか？

回答

残業はできる限りしないほうが良いです。
理由はベロシティ、チームのモチベーションの二点から、というのは同じ認識です。

ただ、絶対残業をしてはいけないわけではなく、リリースの直前など残業せざるをえないようなタイミングもあるかと思います。
残業が発生してしまったら、私はレトロスペクティブで原因を探って次スプリントで調整する…というイメージでいます。
もちろん、PO・ステークホルダーと調整して残業しない方向にもっていくのが一番良いと思います。

解説

ちょっと整理をすると、イテレーション（スプリント）ごとに書くバーンダウンチャートか、リリースやプロジェクト全体で書くかによって、対応はちょっと異なります。

イテレーションバーンダウンチャート

「落ち切らなかった」理由をレトロスペクティブで考え、次のTryにする。
今回はやむを得ない、と判断して、何もしない、ということもなくはないが、それが複数回続くなら、なんかおかしい。
（チームがオーバーコミットしている・させられている可能性もある）
リリース直前で、どうしても、という場合は残業の可能性もあり。

リリースバーンダウンチャート

プロジェクト全体で、これは間に合わなそうだ、と早めに気づくために書く。
気づいた時の対処は：

人やチームを増やす
既存メンバーがちょっとずつ残業する（燃え尽き症候群に注意）
POが仕様を削る
を、組み合わせて対処する。

特に、後者のリリースバーンダウンチャートは、創発的な開発にならない（途中で新たな要件を出しづらい）ので、アジャイルとしては望ましくないという人もいますが、ちゃんとそれをわかってやっているのならOKだと思います。

要件の変更は歓迎したいけど、バーン「ダウン」しないことで、チームのモチベーションが下がるなら、バーンアップチャートにする手もあります。

まとめ

今回は社員から寄せられたアジャイルの疑問の一部を紹介しました。
アジャイルをいざ実践してみると様々な疑問が尽きないことと思います。今回の記事が悩んだ時の一助になれば幸いです。