以前、イシュー管理とタスク管理の違いについてブログを書きましたが、社内で似たような質問で「エピックやストーリーって何？」という質問をいただいたので、その違いについても説明したいと思います。
前回は管理対象の総称をタスクという言葉で表現しましたが、今回はタスクが最小単位の意味を持つので、総称を「ワークアイテム」という言葉で表現します。
まず、大前提としてワークアイテムの階層については色んな流派があり、これが正解というものはありません。そのため、今回は最大公約数的に「エピック」、「ストーリー」、「タスク」について説明したいと思います。流派によっては「イニシアティブ」や「フィーチャー」といった階層もありますが、そちらは最大公約数の３つを理解してから、調べてみると分かりやすいかと思います。
また、それぞれの粒度感に関しては常に議論の対象となる部分ですので、ここではその説明は深くはしません。粒度感よりも各階層がどのような意味を持つのかを理解していただければと思います。
ワークアイテムの階層
先ほど紹介した「エピック」、「ストーリー」、「タスク」はそれぞれ集約関係にあります。エピックは複数のストーリーを集約し、ストーリーは複数のタスクを集約しています。大きく分類すると、エピックとストーリーはユーザー視点、タスクがエンジニア視点でのワークアイテムとなります。
それではそれぞれについて説明していきたいと思います。
エピック
エピックは類似したストーリーをグルーピングするワークアイテムです。
この階層では具体的なアプリやシステムそのものがどのような価値を提供するかよりも、エンドユーザー視点でビジネスとしてどのような価値を実現したいかを定義します。
ざっくりでいうと、現場の担当者レベルではなく、マネージメントレベルで解決したい課題と言えます。当然、スクラムでの1スプリントで解決するような短期的課題であることはほとんどなく、幾つものスプリントを回して中長期的に解決する課題を表すワークアイテムです。
ストーリー
ストーリーはアプリやシステムがどのような価値を提供するかを表すワークアイテムです。
この階層では上位のエピックを実現するために必要なストーリーを洗い出し、アプリやシステムが具体的にどのような機能を提供すべきかをテンドユーザー視点で定義します。
一般的には「〇〇(ステイクホルダー)として、〇〇(機能要件)したい。」といったような表現でストーリーのタイトルがつけられます。見積もりもストーリーポイントを使ってストーリー単位に行われることが一般的です。また、ストーリーには何をもって実現できたかの完了基準が定義されます。これはエンドユーザーにとっての受け入れ基準となります。
ストーリーはビジネスと開発を結びつけるハブ的位置付けのワークアイテムです。
タスク
タスクはストーリーを実現するためにエンジニアがどのような作業を行うかをエンジニア視点で定義するワークアイテムです。
そのため、ストーリーを実現するために複数のタスクを設定することも少なくありません。担当者が異なるタスクや、バックエンドとフロントエンドなど開発対象が異なるタスクはタスクとしては一緒にしないのが一般的です。
バックログとエピックの違い
実はストーリーをまとめる概念としてはエピックの他にバックログがあります。エピックはビジネスの価値としてストーリーをグルーピングしていたのに対して、バックログは開発視点で優先度や時系列の観点でストーリーをまとめたものです。この点からもストーリーがビジネスと開発を結びつけるハブ的位置付けというのがわかるかと思います。
