「ユーザーストーリー」や「ユースケース」は機能要求について記します。
一方、「テクニカルストーリー」は非機能要求について記載します。
ストーリーはメモでしかありませんから、要求の全体像を理解するには会話が必要です。
ユーザーストーリーは仕様書ではありません。ユーザーのニーズを理解するための、会話を促すメモカードです。
ユーザーストーリーはプロダクトオーナー、利害関係者、ドメインエキスパートとの対話を通して理解を深めます。
一方、テクニカルストーリーについては、エンタープライズアーキテクトや運用担当者との対話を通して、詳細情報を取得します。
技術的ストーリーをプロダクトオーナーがエントリーすることは、基本的にありません。技術的ストーリーは、将来の保守性や可用性も考慮できる開発チームが記載し、プロダクトバックログに含めてもらいます。
優先度は、プロダクトオーナーと交渉して上げてもらいます。
プロダクトを長期に渡ってメンテナンスするのは開発チームです。技術的負債を減らし、コードをヘルシーに保つため、継続的にリファクタリングしなくてはなりません。
また、現行のソリューションが、将来的な機能の拡張性を担保できるのかも評価しなくてはなりません。アジャイルのような反復開発では、当初描いたアーキテクチャーが崩れがちです。
開発チームは、技術的ストーリーを通して、プロダクトを継続的に手入れしていかなくてはなりません。
アジャイルのアーキテクチャーはこちらをどうぞ。