• プライオリティスライダーは、これから着手する活動（アジャイル開発等）でのトピック（関心事）の相対的な優先度をメンバー間で議論して合意するためのツールです。

• 複数のトピックの相対的な優先度を可視化します。

• 各トピックの相対的な重要性をスライダーで表現します。（例：右は優先度高、左は低）

• このプラクティスによりチームの意思決定の自律性を高めることができます。

ホワイトボードには「ユーザーエクスペリエンス」、「セキュリティ」などの単語を書き、単語の横に数字(優先度)を書いた付箋を貼ります。(https://github.com/openpracticelibrary/opl-media/blob/master/images/final_priority-sliders.png?raw=true)

• 今から行う開発や活動で、特に注力する領域が何なのかをメンバーで合意することに役立ちます。

• ステークホルダ間で動機や要望を明確にすることができます。

• 開発/活動の優先順位を決めるためのフィルタリング機構として使用することができます。（例えばプロダクトバックログアイテムの優先順位付け）

• チームの意思決定（例えば、機能の採否やプロダクト戦略に関する決定）に利用することができます。プロダクトに関する優先度判断の客観的な基準がスライダーとして明確化されることで、スライダーを判断基準としてチームが自律的に意思決定を行うことができます。（意思決定の都度、複数のステークホルダに意見を聞き調整を行うという事を減らすことができます。）

Steps:

1. 優先度を評価するトピックを選びます。

例:

• 機能面での完成度
• テストの完全性（ソフトウェア品質）
• 製品のマーケットへの適合性
• ユーザーエクスペリエンス
• 性能
• 安定性
• セキュリティ
• チーム自身の学び・成長

2. プライオリティスライダー作成の参加者間で、プライオリティスライダーについてと、選択したトピックに関する共通理解を得ておきます。

3. スケールをトピックの数だけ用意します。また、各スケールの優先度の最大値もトピック数と同じにします（例えば下図のようにトピック数が8の場合、1~8の優先度スケールが8個用意されます）。メンバーはトピック毎に付箋に番号（優先度）を書いてもらいます（～5分）。この作業は個々人で行い、この段階ではチームメンバー間で共有しません。こうすることで偏見を最小限に抑えることができます。時間が来たら、スケールに付箋を貼ってもらいます。

4. スライダーをチームでレビューし、メンバー間の認識の整合性について協議します。メンバー間で優先度の認識が大きく異なるトピックについては、なぜその違いが生じたのかをチームで話し合い、チームで合意できるポイントを探ります。最終的にはすべてのスケールが異なる整数値（優先度）になるように合意を得ていきます。（このとき、優先度の平均値はスケールの真ん中の値に一致します。下図の例では、優先度の平均値は4.5。）(〜20分)