Stories act as a ‘pidgin language,’ where both sides (users and developers) can agree enough to work together effectively.

—Bill Wake, co-inventor of Extreme Programming

ストーリー

ストーリーは、求められる機能の一部分を、ユーザーの視点から簡潔に説明したものです。

アジャイルチームが実装するストーリーは、システム機能を細かく縦分割したもので、数日以内に完了できるものです。

ストーリーは、アジャイルにおけるシステム動作の定義に使用する主要なアーティファクトです。ユーザーの視点から見た機能を簡潔で分かりやすく説明したもので、ユーザーの言葉で記述します。各ストーリーが細かく縦分割したシステム動作の1つを実装します。

ストーリーに含まれるのは、事業部門と技術部門両方の担当者が意図を理解するのに十分な情報のみです。詳細は、ストーリーが実装できる状態になってから決定します。受け入れ基準と受け入れテストを通じて、ストーリーをより具体的にすることで、システム品質を確保できます。

ユーザーストーリーによって、エンドユーザーに直接機能を提供します。イネーブラーストーリーによって、探索、アーキテクチャ、インフラストラクチャ、コンプライアンスをサポートするために必要な作業項目を可視化します。

詳細

SAFeでは、機能的なシステム動作を説明するものとして、エピック、ケイパビリティ、フィーチャー、ストーリーの4つのアーティファクト階層を設けています。これらのアーティファクトをまとめて使用することで、実現しようとするソリューションの動作を説明します。実装に関わる仕事を詳細に述べたものがストーリーであり、ストーリーが集まってチームバックログを構成します。ARTバックログのビジネスフィーチャーやイネーブラーフィーチャーから生まれるストーリーもあれば、チームのローカルコンテキストから生じるものもあります。

各ストーリーは、インクリメンタルに実装できる小規模で独立した動作であり、ユーザーまたはソリューションに一定のバリューを提供します。すべてのイテレーションで新たなバリューを提供できるよう、機能を縦分割したものです。ストーリーは小規模で、1回のイテレーションで完了する必要があります (ストーリー分割のセクションを参照)。

通常、ストーリーをまずインデックスカードや付箋に書き出します。カードという物理的な媒体を使うことで、チーム、ストーリー、ユーザーの間の関係が明確になります。これはチーム全員にストーリーの記述に積極的に参加してもらう上で有効です。付箋を使用するベネフィットは他にもあります。仕事が可視化されるため、壁やテーブルに配置したり、順番に並べ替えたり、必要に応じて除外したりするのも簡単です。ストーリーによって、スコープと進捗状況に関する理解が深まります。

「これだけのストーリーにこれから取り組もうとしている」 (スコープ)
「今回のイテレーションでこれだけのストーリーを実現できた」 (進捗状況)

ストーリーの記述は誰でもできますが、それを承認してチームバックログに加え、システムベースラインに取り入れる責任を担うのは、プロダクトオーナーです。もちろん、スケールがエンタープライズ規模になると付箋では対応できないため、多くの場合、ストーリーの管理はすぐにアジャイルライフサイクル管理 (ALM) ツールへと移行されます。

SAFeには、ユーザーストーリーとイネーブラーストーリーの2種類のストーリーがあります。以下で説明します。

ストーリーはどこから来るのか

図1に示すように、ストーリーは通常、ビジネスフィーチャーとイネーブラーフィーチャーを分割することで作られます。

図1 ビジネスフィーチャーをストーリーに分割する例

ユーザーストーリー

ユーザーストーリーは、必要な機能を記述するための主な手段です。要するに、従来の要件仕様に代わるものです。ただし、場合によっては、コンプライアンス、サプライヤー、トレーサビリティ、その他のニーズをサポートすべく後から仕様に記録されるシステム動作を説明し、開発する手段としての役割も果たします。

ユーザーストーリーが関心の対象として重視するのは、システムではなくユーザーであるため、これらのストーリーはバリューであり顧客中心です。これをサポートするために推奨される表現形式が、次のような「ユーザーボイス形式」です。

(ユーザーの役割) として、(アクティビティ) を行いたい、それによって (ビジネスバリュー) を実現したい

この形式を使用することで、どのようなユーザーがシステムを使用しているのか、システムを使って何をしているのか、どんな目的でそれをしているのかをチームが理解するための指針となります。常に「ユーザーボイス」形式を適用することが、その分野におけるチームの強みの向上に役立ちます。ユーザーの実際のビジネスニーズに関するチームの理解が深まるからです。図2に例を挙げます。

図2 ユーザーボイス形式で書かれたユーザーストーリーの例

「デザイン思考」で説明するように、ペルソナは代表的なユーザーの具体的な特徴を表し、チームがエンドユーザーに関する理解を深めるのに役立ちます。図2のライダーのペルソナとして、スリルを求めるライダー「ジェーン」と臆病なライダー「ボブ」などの例が考えられます。ペルソナは、ストーリーの説明にも使用できます (例: ジェーンとして、私は…)。

このユーザーストーリーの声は一般的なものですが、すべてのシステムがエンドユーザーとやり取りするわけではありません。中には、「ユーザー」がデバイス (プリンターなど) やシステム (トランザクションサーバーなど) の場合もあります。こうしたケースでは、ストーリーは図3に示す形式で記述できます。

図3 「システム」をユーザーとするユーザーストーリーの例

イネーブラーストーリー

また、チームは、新たなユーザーストーリーの実装に必要な新しいアーキテクチャやインフラストラクチャの開発も行います。この場合、ストーリーにエンドユーザーとの直接の接点があるとは限りません。そこで、探索、アーキテクチャ、インフラストラクチャをサポートするためにチームが使用するのが「イネーブラーストーリー」です。イネーブラーストーリーは、図4に示すように、ユーザー中心ではなく技術的な言葉で表現できます。

図4 イネーブラーストーリーの例

この他にも、次のようなさまざまなイネーブラーストーリーがあります。

リファクタリングとスパイク (従来、エクストリームプログラミングで定義されるものと同様)
開発 / デプロイメントインフラストラクチャを構築または改善する
ユーザーによる操作が必要な仕事を実行する (100万のウェブページのインデックスなど)
目的別に必要なプロダクトやコンポーネントの構成を作成する
システム品質の検証 (パフォーマンスおよび脆弱性テストなど)

イネーブラーストーリーのデモは、ユーザーストーリーと同様に行われます。デモでは通常、得られた知識や制作したアーティファクト、ユーザーインターフェース、スタブ、モックアップを披露します。

効果的なストーリーを書く

効果的なストーリーを書くには、複数の視点が必要です。アジャイルでは、何を構築すれば手直しを減らし、スループットを向上させられるかについて、チーム全員が共通認識を持ちます。チームは、ビヘイビア駆動開発 (BDD) によって協力し合い、各ストーリーを明確に説明する受け入れテストを詳しく定義します。

協力し合ってストーリーを記述することで、あらゆる視点が考慮され、全員が納得した上でストーリーの動作が決定され、その結果がストーリーの説明、受け入れ基準、そして受け入れテストに反映されるようになります。受け入れテストは、BDDを使って、システムのドメイン言語で記述されます。続いて、BDDテストが自動化され、それを継続的に実行することで作り込み品質を維持します。BDDテストはシステム要件 (ストーリー) を評価基準として記述されるため、ドキュメントベースの仕様に代わるシステム動作に関するステートメントとして使用できます。

3つのC: Card (カード)、Conversation (会話)、Confirmation (確認)

XPの考案者の1人であるロンジェフリーズは、ストーリーの3つのCを提起したことで知られています。

Card (カード) – インデックスカード、付箋、またはツールを使用してユーザーストーリーのインテントを記述します。インデックスカードによって、チームとストーリーの間に物理的な関係が生まれます。カードの大きさは限られているため、ストーリーの長さが物理的に制限され、具体的なシステム動作に関する時期尚早な提案を抑制します。また、カードを使うことは、チームが今後のスコープを「肌で感じる」のにも役立ちます。10枚のカードを手にするのと、スプレッドシートの10の行を眺めるのとでは、大きな違いがあるからです。
Conversation (会話) – チーム、顧客 (または顧客の代理人)、PO (顧客の代表者である場合もあります)、その他のステークホルダーとの間でストーリーに関する「会話が約束される」ことを意味します。インテントの実装に必要なより詳細な動作を決定するためには、ディスカッションが必要です。会話によって、受け入れ基準 (次のConfirmation (確認)) やユーザーストーリーの付属資料という形でさらに具体性が増すこともあります。会話は、次に挙げるストーリーのライフサイクルのすべてのステップで行われます。
- バックログリファインメント
- プランニング
- 実装
- デモ

こうしたジャストインタイムのディスカッションによって、正式な文書では捉えきれない、スコープに関する共通認識が生まれます。詳細なドキュメントに代わって、実例型仕様を用います。さらに、ユーザーシナリオや非機能要件 (NFR) のギャップを明らかにする上でも、会話は有効です。

Confirmation (確認) – 受け入れ基準は、ストーリーが適切に実装され、関連する機能やNFRをカバーしていることを確認するために必要な情報を規定します。図5に例を示します。ストーリーカードの確認セクションを使って、デモの内容を書き込むチームもあります。

図5 ストーリーの受け入れ基準とBDD

アジャイルチームは、多くの場合、ビジネスが判読可能なドメイン固有言語を使って、可能な限り受け入れテストを自動化します。自動化することで、リューションを検証し、確認するための実行可能な仕様が生まれます。また、自動化によってシステムの迅速な回帰テストが可能となるため、継続的な統合、リファクタリング、メンテナンスが向上します。

効果的なストーリーに投資する

アジャイルチームは、ユーザーストーリーを見つけ出し、詳しく説明し、理解すること、そして受け入れテストを記述することに多くの時間を割きます。これこそがアジャイルチームのあるべき姿です。なぜなら、それが次の事実を象徴しているからです。

すでに理解されているオブジェクティブのコードの記述は、必ずしもソフトウェア開発における最大の難関ではない。

むしろ一番難しいのは、コードの真のオブジェクティブを理解することです。ですから、効果的なユーザーストーリーへの投資は、最終責任時点であっても、チームにとって取り組む価値があります。ビルウェイクが作ったINVEST [1] という言葉は、効果的なユーザーストーリーの特性の頭文字を取ったものです。

I – Independent (独立している) 他のストーリーとは独立している
N – Negotiable (交渉できる) 契約ではなく、柔軟なインテントの表明である
V – Valuable (価値がある) 顧客に価値のある縦分割したものを提供する
E – Estimable (見積り可能) 小規模で交渉可能である
S – Small (小さい) 1回のイテレーションに収まる
T – Testable (テスト可能) テスト方法が分かるくらい十分に理解できている

効果的なストーリーを分割する

ストーリーの規模を小さくすることで、実装の速度と信頼性を向上できます。項目の規模が小さければ、どのシステムでもフローの進みは速くなり、バラツキとリスクが減少するからです。このため、規模の大きなストーリーを小さく分割するスキルは、すべてのアジャイルチームで必須です。これは、インクリメンタルな開発の理論でもあり、実践でもあります。『Agile Software Requirements』では、ストーリーを分割する10の方法を取り上げています [1]。これらのテクニックをまとめると、次のようになります。

ワークフローステップ
ビジネスルールのバリエーション
主な取り組み
シンプル/複雑
データのバリエーション
データ入力手法
先送りにしたシステム品質
操作 (CRUD: Create (作成)、Read (読み取り)、Update (更新)、Delete (削除) など)
ユースケースシナリオ
ブレイクアウトスパイク

図6は、ストーリーをユースケースシナリオで分割した例です。

図6 大きなストーリーから小さなストーリーへの分割の例

ストーリーを見積る

アジャイルチームはストーリーポイントや「見積りポーカー」を使って、自分たちの仕事のバリューを評価します [1、2]。ストーリーポイントは、以下の特性を総合し、1つの数字で表したものです。

ボリューム – どれくらいの量があるか
複雑さ – どのくらい難しいか
知識 – 分かっていることは何か
不確実性 – 分かっていないのは何か

ストーリーポイントは相対的であり、特定の測定単位とは結びついていません。各ストーリーのサイズ (必要な労力) は、一番小さいストーリーを基準として見積ります。このとき、最小ストーリーのサイズが「1」となります。改変フィボナッチ数列 (1、2、3、5、8、13、20、40、100) [2] を使用することで、特に大きな数 (20、40、100など) の見積りに特有の不確実性が反映されるようにします。

見積りポーカー

アジャイルチームは通常、「見積りポーカー」を活用して、エキスパートの意見、類推、分類を取り入れた迅速かつ信頼性の高い見積りを作成します。分類とは、ストーリーやフィーチャーをより小さく、見積りがしやすい大きさに分割することを指します。

(見積りには、他にもいくつかの方法が使用されます。) 見積りポーカーのルールは、次のとおりです。

チームメンバー全員が参加する
各参加者に、改変フィボナッチ数列を含むカードの束を配る
POはその場に立ち会うが、見積りはしない
スクラムマスター / チームコーチもその場に立ち会うが、開発の仕事に直接携わっている場合を除いて、見積りはしない
各バックログ項目を見積るため、POがストーリーの説明を読み上げる
質疑応答を行う
参加者がそれぞれ、自分の見積りに相当する見積りカードを1枚選ぶ
先入観を避けるため、全員が同時にカードを裏返して、見積りが見えるようにする
高く見積った参加者と低く見積った参加者に、それぞれ理由を説明してもらう
ディスカッションの後、各参加者は再びカードを1枚選んで再度見積りを行う
これで見積りは収束すると考えられる (意見がまとまらない場合は、ここまでのプロセスを繰り返す)

デザインについて、あらかじめある程度ディスカッションしておくことは問題ありません。しかし、デザインに関するディスカッションに時間をかけすぎてしまい、それが徒労に終わることも珍しくありません。見積りポーカーの真の重要性は、全員が納得してストーリーのスコープを決められることにあります。その上、楽しく取り組めます。

ベロシティ

1回のイテレーションにおけるチームのベロシティは、完了の定義 (DoD) を満たしたすべての完了済みストーリーのポイントの合計に相当します。チームで長期にわたって一緒に仕事をするにつれて、チームの平均ベロシティ (イテレーション1回あたりの完了済みストーリーポイント) の信頼性と予測可能性が向上します。ベロシティが予測可能になると、プランニングにも仕掛かり中の仕事 (WIP) を制限する上でも役立ちます。チームが過去のベロシティで対応できる範囲を超えるストーリーを引き受けなくなるからです。この指標は同時に、エピック、フィーチャー、ケイパビリティ、イネーブラーを提供するのにかかる時間を見積るものでもあり、予測には同じくストーリーポイントを使用します。

キャパシティ

キャパシティは、任意のイテレーションに利用できるチームのベロシティの一部です。あるイテレーション期間中、休暇、トレーニング、その他のイベントによって、チームメンバーがそのイテレーションの目標に貢献できない期間が発生することがあります。すると、このイテレーションにおいては、そのチームが達成できると考えられる最大ベロシティは低下します。例えば、イテレーション1回あたりに提供できるポイントの平均が40ポイントのチームでは、チームメンバーの1人が1週間休暇を取る場合には、最大ベロシティを36に調整します。このことを事前に把握しているため、チームはイテレーションプランニング中にコミットするストーリーポイントを最大36に制限します。またこの情報は、PIプランニングにおいて、PIの各イテレーションで実際に利用できるキャパシティを予測する上でも役立ちます。チームがPIオブジェクティブを構築する際に、過剰なコミットを防げるからです。

出発点となる見積りのベースライン

標準的なスクラムでは、各チームのストーリーポイントの見積りとそこから求められるベロシティは、局所的で独立した関心事です。規模が大きくなると、チームのベロシティ変動が大きい場合には、より大規模なエピックやフィーチャーのストーリーポイントの規模を予測することが難しくなります。これを克服するため、SAFeチームは出発点として、最初にストーリーポイントのベースラインを決めて校正を行い、1ストーリーポイントの定義がすべてのチームでほぼ同じになるようにします。チームの見積りやベロシティの再校正は必要ありません。校正は、新しいアジャイルリリーストレインをローンチする際に一度だけ行います。

ストーリーポイントを「正規化」することで、次に示す方法で、出発点となるストーリーとベロシティのベースラインをチーム間で一致して設定できるようになります。

チームのすべての開発者・テスターに、2週間のイテレーション1回あたり8ポイントを付与する (理想的な就業日1日につき1ポイントとし、一般的なオーバーヘッドとして2日を差し引く)。
チームメンバーの休暇や祝祭日については、1日につき1ポイントを引く
開発に半日、テストと検証に半日かかる小規模なストーリーを見つけ、これを「1」とする
この「1」を基準として他のすべてのストーリーを見積る

例: 6人からなるチーム (開発者3人、テスター2人、PO 1人) で、休暇や祝祭日がない場合、当初のベロシティはイテレーション1回あたり5 × 8ポイント = 40ポイントと推定されます。(注: 開発者やテスターの中にスクラムマスター / チームコーチがいる場合には、見積りを少し引き下げる調整が必要になる可能性があります。)

この方法なら、チーム間である程度ストーリーポイントの比較が可能です。マネジメントによるストーリーポイントのコストに関する理解が深まり、今後のフィーチャーやエピックのコストをより正確に判断できるようになります。

チームのベロシティは時間が経つにつれて上昇する傾向にあり、それは良いことですが、実際には、どちらかと言えば安定した数値が続きます。生産性の変動よりも、チームの規模や技術的なコンテキストの変更の方が、チームのベロシティにはるかに大きな影響を与えます。

注: SAFeチームカンバンチームは通常、スクラムチームよりもストーリーの見積りに割く時間は少なくなります。カンバンによるフローベースのモデルでは、通常、作業項目やストーリーを分割して、チームが1つのストーリーを一般的には数日以内で提供できるサイズに調整します。SAFeのコンテキストでは、チームがイテレーションプランニングに参加し、以降のイテレーションにストーリーを割り当てる必要があるため、ある程度のサイズ調整の概念が必要です。

SAFeカンバンチームも、最初に見積りポーカーか同様のメカニズムを使用してストーリーのサイズを決定することがあります。しかしそれよりも、こうしたチームは、仕事を同じくらいのサイズのストーリーに分割する感覚を身につける傾向があります。そうすることで、フロー全般を促進し、カンバンシステムにおいて、大規模なストーリーが同じく進める必要がある他のストーリーの進行を妨げないようにすることができるからです。チームが自分たちのベロシティを把握することで、一定期間内に提供できるストーリーの数を把握できるため、PIプランニングでイテレーションにストーリーを配置し、他のチームに対して特定のストーリーが利用可能になるタイミングをコミットできます。

定期的なメンテナンスやサポート業務を行っているチームの場合、通常のバックログ項目の見積りの重要性は低くなります。多くの場合、こうしたチームでは、この種の事後対応型の仕事の見積りをしません。ただし、どのチームにもレトロスペクティブ項目やCDパイプラインの改善につながる取り組みをはじめとする、対応、スケジューリング、見積りが必要な重要なタスクがあります。

詳しく学ぶ

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.

最終更新: 2022年12月7日