詳解 : JIRA の ユーザーストーリー を適切に分解する

JIRA のアジャイルプロジェクト数が (なんと Cloud 製品の顧客だけで) 50 万を超えました。アジャイルチームがどのように仕事をしているかがわかる膨大なデータを私たちは持っていることに気付きました。そして、匿名データマイニングによって、スプリントを繰り返してテンポ良くリリースしているチームを発見しました。

素早く頻繁にリリースできるチームが抱える 1 スプリントの課題数は通常 30 程度である

ツイート

調査中に際だったのは、素早く頻繁にリリースするチーム、ここでは「迅速にリリースするチーム」と呼びますが、このようなチームには通常、1 スプリントにおよそ 30 の課題があるということです。そして私たちは、5 〜 7 人で構成された効率的なアジャイルチームについて議論しています。課題の数が 30 というと多すぎるように聞こえるかもしれませんが、その数字が全てを語っているわけではありません。30 という数字は、迅速にリリースするチームが仕事を多くの小さな機能単位に分割していることを意味しています。各機能を細かく分割することによって、小さなチームが自らを守り、1 つのスプリントで自信を持って完了できるレベルまで仕事に取り組むことができるのです。

1 スプリントで発生する課題の数に対するチームのスイートスポットを見つけるために、あなたのチームに必要なことは、課題の範囲が大きくなりすぎる瞬間を見極めることです。その瞬間を見つけたら、それに対して何か行動を起こし、JIRA によって変化を起こす必要があります。ストーリーだったものをエピックに変更すべきでしょうか? それともより小さなストーリーやタスクに分割すべきでしょうか? サブタスクをどこに当てはめれば良いのでしょうか?

これらの質問に答えるために、課題を適切に分割して、それらの全てを JIRA でまとめる方法を一緒に見て行きましょう。

バージョン、エピック、ユーザーストーリー を理解する

最近投稿された JIRA Portfolio ブログにおいて、JIRA Portfolio で仕事を整理する方法を基礎から説明しています。同じように、JIRA には仕事の整理を行うために階層構造が存在します。「バージョン」は今後のリリースを表し、「エピック」は単一の機能またはイニシアチブを、「課題」 (ユーザーストーリー およびタスク) は各機能単位を表し、「サブタスク」は親ストーリーやタスクを含む仕事において、より小さな単位を表しています。

この階層構造があるため各要素の範囲がある程度わかるでしょう。しかし、チームのバックログにある ユーザーストーリー が機能全体を表している場合がありますし、あるいは、他の課題より 2 倍あるいは 3 倍大きいと思われるものもあるかもしれません。どちらのケースでも、課題の範囲は再評価する必要があります。

ある課題の説明が一つの機能の説明のように見えるか、もっと大きな作業になりそうであれば、その課題はエピックに変換しましょう。そして、その構成要素である ユーザーストーリー とタスクにすぐにリンクするべきです。このために JIRA では以下の作業が必要になります。

1. 課題を開き、上部のドロップダウンから More を選択します。
2. Move をクリックして、Select Project and Issue Type ページへ移動します。
3. Current Issue Type を Epic に変更します。
4. Next をクリックして、エピック名を入力し、その他のフィールドも入力します (必須フィールドはエピック名のみです)。
5. フィールドを更新したら Next をクリックします。確認ページが表示されます。
6. 新しい情報を確認して Move をクリックします。これでエピックが作成されました。

次に、ユーザーストーリー 用の課題を作成し、これとあなたが新しく作成したエピックを関連付けます。JIRA で課題を作成する方法はきちんと文書化されていますが、まだあなたがご存じでないと思われるテクニックがいくつかあります。

1. 画面上部の Create ボタンで新しい課題を作成すると、バックログに自動的に課題が追加されます。
2. Create ボタンをクリックしてバックログから課題を 1 つ選択すると、選択した課題の直下に新しい課題が表示されます。
3. 課題を作成する際それをスプリントに割り当てると、その課題はスプリントの下部に追加されます。
4. バックログにいる時にスプリントの下に表示されている + Create Issue をクリックすると、JIRA がボードや適用されている各フィルタリングに合わせて属性を追加します。例えば、現在あなたのボードが「モバイルクライアント」エピックと関連付けられた課題のみを表示している場合、この方法で作成された課題は自動的に「モバイルクライアント」エピックと関連づけられます。

エピックと関連する課題に関しては非常に簡単です。

1. バックログへ行き左側にあるエピックのリンクをクリックすると、あなたのエピックが全て表示されます。
2. バックログから課題を選択して、エピックのリストにドラッグします。
3. 関連付けたいエピック上に課題をドロップします。これであなたの課題にはエピック名と共に色付きの菱形が表示されます。

これが課題タイプをより大きい範囲に変更する方法です。逆に、ユーザーストーリー が機能全体になってはいないけれど、1 つのスプリント内で 1 人で完了できないほど作業が多い場合、複数の課題に分割する必要があります。そういった問題が起きる時、チームの見積もりを理解する必要性が出てくるでしょう。

例えば、JIRA マーケティングチームは、ストーリーポイントを見積もりに使用しています。ユーザーストーリー が 20 ポイントかそれ以上だと見積もられた場合、私たちはそれをレッドフラグとしています。それは、課題の見積もりが、2 週間のスプリントには大きすぎるということです。これがストーリーポイントを基準にするチームルールです。さまざまな基準があり得ます。しかし、試しにあなたの開発チームも同じ基準で 2 週間スプリントを実施するとしましょう。20 ストーリーポイントは、ユーザーストーリー に含まれる未知の物が多すぎるか、単に大きすぎることを意味するでしょう。小さい課題に分割する方法は、プロダクトオーナー、開発者、テスター、スクラムマスターなどから構成されるあなたのチーム次第です。

クローン、リンク、サブタスク

ユーザーストーリー を 2 つの課題に分割することにした場合、コピーをすること、すなわち JIRA の課題においてはクローニングが最高の選択肢になります。クローニングによって、新しい課題には概要、課題タイプ、スプリント、エピック、バージョン、予定日、担当者などのオリジナルと同じあらゆる情報が含まれます。説明文は、各課題の希望の範囲を反映するように、明らかに更新する必要があります (基本的には 2 つに分割)。クローンした課題の担当者とフィックスバージョンも、状況に応じて同様に変更する必要があるかもしれません。

これまでに課題のクローンをしたことがない方のために簡単な方法を以下に紹介します。

1. 課題を開き、アクションセクションで More ドロップダウンを選択します。
2. Clone をクリックするとダイアログボックスが開き、クローン課題の概要を入力するよう要求されます。
3. Edit をクリックして他の課題と同じように編集します。

クローニングのもう一つのメリットは、新しい課題がオリジナルの課題の課題リンクセクションに表示されることです。それには「クローン先」というリンクタイプと新しい課題への参照が付与されています。同様に、新しい課題の課題リンクセクションには、オリジナルの課題の参照があり、それには「クローン元」というリンクタイプが付与されています。

リンキングは各課題の関係を繋げる素晴らしいものです。JIRA には「クローン先 / クローン元 (is cloned as/is cloned from)」や「ブロック/ ブロック元 (blocks/is blocked by)」などの基本的なリンクタイプがいくつかありますが、JIRA 管理者と協力して、あなたの希望のあらゆるカスタムリンクタイプを追加することも可能です。限界はありません。例えば、ここアトラシアンでは「問題 / 原因 (causes/is caused by)」というカスタムリンクタイプを追加し、コード変更が新しいバグを生み出した状況を反映しています。

2 つの課題がリンクされれば、それらの関係は課題リンクセクションに表示されます。また、リンクされた課題の優先度やステータスを見ることもでき、それにより課題間を移動する必要がなくなり、待機中の課題が完了されたかどうかを確認するために検索する必要もなくなります。

課題を分割しようとしているかどうか、または課題をプロジェクトにまとめようとしているかどうかに関わらず、リンクはシンプルです。ここに課題のリンク方法を紹介します。

1. 課題を開き、アクションセクションで More ドロップダウンを選択します。
2. Link をクリックするかキー入力するとダイアログボックスが開き、関連の入力と関連付けたい課題の入力をするよう要求されます。
3. Link をクリックすると、Issue Links セクションにリンクが表示されます。

さらに、上述したオペレーションダイアログボックスを使うことで時間を節約することもできます。

そしてサブタスクがありました。それらを課題を解決するための個別ステップとして列挙するチームもあります。複数のメンバーに課題の完了が要求された場合、担当者を変えるのではなく 5 つのサブタスクを 5 人の異なるメンバーに割り当てることができるから、サブタスクを気に入っているというチームもあります。リンキングと同じように、管理者がサブタスクを有効にする必要がありますが、その後は、More メニューで Create Sub-Taskメニューを選択するだけでサブタスクを作成することができます。また、同じメニューから既存の課題をサブタスクに変換することもできます。

サブタスクは通常、バックロググルーミングあるいはスプリント計画中に追加されます。これは、ユーザーストーリー を分割する必要性を決定するのと同じ状況です。これにより課題を小さくするタイミングを見つけやすくなるため、必然的により簡単で正確に見積もりがしやすくなります。

JIRA の他のあらゆる機能と同様、サブタスクはカスタマイズが可能です。サブタスクが全て完了するまでユーザーストーリーを次のワークフローステータスに移したくない場合は、そうすることも可能です。これらは、より賢くチームの計画を立て、リリースリズムを見つける助けになるツールなのです。

迅速にリリースするチームの習慣

JIRA の 50 万以上に及ぶアジャイルプロジェクトにおいて、迅速にリリースするチームのおおよその平均値としては 1 スプリント当たり 30 の課題数ではありますが、本当に重要なことは、スプリントの間に完了できるように課題の大きさを決めることです。課題が大きすぎると判断して、エピックに変換したり小さな課題に分割したりすることができれば、より成功に近づき、スプリント後にはあなたのチームは「迅速にリリースするチーム」になっているでしょう。

私たちは、迅速にリリースするチームの他のパターンやよくある傾向も発見しています。迅速にリリースするチームの特徴をインフォグラフィックスでご覧ください。

サイトを見る