ユーザーストーリーの分割例：購入手続きを小さく届ける

「購入手続きを作る」だけでは、実装範囲を話し合うには大きすぎます。「データベースを作る」「画面を作る」「テストする」に分ければ作業は小さくなりますが、そのどれか一つだけでは顧客は購入できません。

よりよい分け方は、最初から最後まで動く、範囲を絞った購入経路にすることです。共有のスクラム計画ボードで、その小さな単位、受け入れ例、後に回す作業を比較します。開発者が必要な実装を話し合う間も、顧客が得る結果を見える場所に置きます。

小さなストーリーか、技術作業だけか

Agile Allianceによるストーリー分割の定義では、分割した各ストーリーにもビジネス上の価値を残します。各単位で商用サービス全体を公開できなければならないという意味ではありません。一つの技術層を完成させただけでなく、役立つ行動の変化を示せることが大切です。

利用者は購入を完了したり、保存された注文を確認したり、適用可能な割引を使ったりできます。しかし、周囲の動作がない「データベースのテーブル」だけを意味のある形で使うことはできません。データベース変更、画面作成、テストは必要なままです。独立した顧客価値と呼び替えず、ストーリーを支える実装作業として置きます。

垂直分割とは、システムの必要な部分を通る細い経路を作ることです。すべてのストーリーを図で縦の列に描くという意味ではありません。Humanizing Workのストーリー分割ガイドでは、この違いと、役立つ動作を保ちながら範囲を縮めるパターンを説明しています。

購入手続きの例で対象範囲を決める

在庫のある商品を閲覧し、カートへ追加できる店を想定します。次に必要なのが購入手続きです。最初の要望には複数の支払方法、複数の配送地域、割引コード、保存済み住所、ゲスト購入が含まれます。最初の購入経路が機能するかを確かめるために、すべてが必要とは限りません。

この架空のリリースでは、既存の登録顧客が在庫のある商品を、対応する一つの地域で購入する範囲を選びます。支払方法は一つ、配送は既存の標準配送だけです。クーポン、新しい住所の保存、海外配送はまだ提供しません。

最初のストーリーは、「登録顧客が、対応する支払方法でカート内の在庫商品を購入し、注文確認を受け取れる」です。範囲は狭くても、顧客は購入を完了できます。

二つの分け方を比べる

右側の四項目は、四回の独立したリリースを約束するものではありません。チームが話し合い、順序を考える候補です。購入の成功には支払処理が含まれるため、最初の二行は同じ初回ストーリーに属することもあります。カードの数を増やすためだけに分けないようにします。

最初の単位をテストできる形にする

「十分小さい」と判断する前に具体例を書きます。成功する流れを一文にしただけでは、使える動作に必要な作業が隠れている場合があります。

これは求める動作の例であり、決済の実装仕様ではありません。既存のセキュリティ、アクセシビリティ、プライバシー、リリースの要件は引き続き適用されます。必要な保護やエラー処理を省くことと、業務上の範囲を狭めることは別です。

解消する不確実性から次の単位を選ぶ

標準的な購入が動くようになれば、次の選択肢があります。別の支払方法は支払える人を増やします。割引ルールは金額計算と顧客向けの説明を変えます。保存済み住所はリピーターの再入力を減らします。それぞれ別のニーズに応えるため、必ず次に来るものはありません。

どの顧客層が行き詰まり、その根拠は何かを尋ねます。対応地域に試験利用の対象者が含まれるなら、海外配送より分かりにくい注文確認の修正が急務かもしれません。支払方法がその対象者を除外しているなら、最初の単位の選び方に問題があった可能性があります。

探索と実装も区別します。未経験の決済サービスを短期間調べれば技術上の不確実性は減らせますが、それ自体は完成した購入ストーリーではありません。問いと求める根拠を明確にし、「利用者として」で始めただけで顧客価値に見せかけないようにします。

Boardmixで分割の議論を整理する

Boardmixのボード上部に、大きな購入手続きの要望を置きます。その下に、最初に使える単位、後の選択肢、未解決の質問の場所を作ります。技術作業は、別のユーザーストーリーの一覧にせず、実現する単位の下に置きます。

最初の単位の隣に受け入れ例を加えます。「重複送信時の動作」は、期待する結果に合意するまで質問の場所に置きます。対象ストーリーとつないでおくと、議論時に不確実性を見落としません。

購入手続きを買い物全体の流れの中に位置付けたいなら、ユーザーストーリーマップが役立ちます。分割用のボードは、より狭い問いに答えます。この部分で実現できる、最小限の役立つ変化は何でしょうか。

選んだストーリーをチームの開発管理システムへ移す前に、結果と具体例を一緒に読みます。示せるものが一つの技術層の完成だけなら、最初から最後まで通せる、より小さな動作を探し続けます。Boardmixを開き、候補を並べてチームで比べてみましょう。