スクラム-ユーザーストーリー

ご理解のとおり、ユーザーストーリーは一般的に製品の機能を説明するために使用され、スクラムアーティファクトの一部を形成します– Product Backlog そして Sprint Backlog。

ユーザーストーリー

ソフトウェア開発では、製品の機能が重要な役割を果たします。これは、ユーザーが最終製品で最終的に使用したい機能です。これらは、一般的な用語では要件として知られています。ソフトウェア開発プロジェクトの成功は、ユーザーの要件を正確かつ適切に理解し、それらを最終製品に実装することにあります。したがって、要件または製品の機能を開発プロジェクトチームに完全に知らせる必要があります。

1999年、ケントベックは製品機能のユーザーストーリーという用語を思いつきました。彼は、ユーザーストーリーは、システムが彼のために何ができるかではなく、彼または彼女が何を望んでいるかに関してユーザーの観点からナレーションされていると説明しました。したがって、ビューは製品ごとに完全に変わり、ユーザーストーリーはすべてのアジャイルフレームワークの要件の事実上の標準になりました。

スクラムプロジェクトでは、製品バックログはユーザーストーリーのリストです。これらのユーザーストーリーは優先順位が付けられ、スプリント計画会議のスプリントバックログに取り込まれます。

見積もりもユーザーストーリーに基づいており、製品のサイズはユーザーストーリーポイントで見積もります。

ユーザーストーリーの構造

ユーザーストーリーの構造は次のとおりです-

<ユーザのタイプ>、

私が欲しい<いくつかのタスクを実行するために>、

だから<私はいくつかの目標/利益/値を達成することができます>。

銀行の顧客がATMから現金を引き出すシナリオのユーザーストーリーがどのように構成されているかを見てみましょう。

ユーザーストーリー：顧客の現金引き出し

として Customer、

したい withdraw cash from an ATM、

そのため I don't have to wait in line at the Bank

ユーザーストーリーの受け入れ基準

各ユーザーストーリーには受け入れ基準も定義されているため、ユーザーストーリーの実装の正確さは、受け入れ基準に基づく受け入れテストに合格することで確認されます。

以下は、ユーザーストーリーの顧客による現金の引き出しの例のサンプル受け入れ基準です。

Acceptance Criterion 1:

Given アカウントが信用できること

そしてカードは有効です
そしてディスペンサーには現金が含まれています、

When 顧客が現金を要求する

Then アカウントから引き落とされていることを確認します

そして、現金が分配されることを確認してください
そして、カードが返されることを確認してください。

Acceptance Criterion 2:

Given アカウントが引き落とされていること

そしてカードは有効です

When 顧客が現金を要求する

Then 拒否メッセージが表示されていることを確認します

そして、現金が分配されないことを確認してください
そして、カードが返されることを確認してください。

ユーザーストーリーの作成

プロダクトオーナーは、プロダクトバックログ、つまりユーザーストーリーに責任があります。ただし、製品の所有者だけがユーザーストーリーを書くという意味ではありません。スクラムチームの誰もがユーザーストーリーを書くことができ、要件が洗練され、新しい機能が追加されると、アクティビティをプロジェクト全体に広げることができます。

ユーザーストーリーの非機能要件

非機能要件をユーザーストーリーに組み込むことも可能です。与えられたATMの例では、ユーザーが24時間365日利用できるATMは非機能要件であり、ユースケースで説明できます。

ユーザーストーリーの管理

ユーザーストーリーは、製品バックログで管理されます。ユーザーストーリーは優先度に従って並べられています。最も優先度の高いユーザーストーリーは詳細レベルに絞り込まれ、最も優先度の低いユーザーストーリーはより詳細なレベルに保たれます。すべてのスプリントについて、最も優先順位が高く、したがってよりきめ細かいユーザーストーリーがスプリントバックログに取り込まれます。ユーザーストーリーを製品バックログに追加する場合は、最初にその優先度が決定され、優先度に従ってその場所に従って配置されます。ユーザーストーリーはいつでも優先順位を変更できます。必要に応じて、ユーザーストーリーを削除することもできます。

ユーザーストーリーのメリット

ユーザーストーリーの主な利点は、ユーザー中心の定義自体にあります。これは、最終的には、関連するユーザーシナリオで製品を使用するのはユーザーであるためです。エンドユーザーをチームメンバーに接続します。
ユーザーストーリー自体の構文は、ユーザーが達成したい目標、利益、または価値を確実に捉えます。
受け入れ基準はユーザーストーリー自体の一部を形成するため、スクラムチームに追加の利点があります。
プロジェクトの実行中にユーザーストーリーに変更を加えることができます。ユーザーストーリーの範囲が大きくなる場合は、より小さなユーザーストーリーに分割する必要があります。合格基準の条件も変更できます。
各スプリントの終了時に作業成果物の増分がユーザーに配信されると、スクラムチームはスプリントレビューミーティングでユーザーからフィードバックを得ることができます。これにより、フィードバックを製品に継続的に組み込むことができます。

結論

スクラムのユーザーストーリーは、ユーザーをスクラムチームに近づけ、土壇場での驚きを防ぎます。