SprintレビューでUIのないソフトウェアをどのようにデモしますか？
基本的にはスクラムに従って、アジャイルなソフトウェア開発を行っています。私たちはスプリントレビューを行おうとしていますが、難しいと感じています。私たちのソフトウェアは多くのデータ処理を行っており、ストーリーはしばしばこれに関するさまざまなルールを変更することについてです。
UIまたは目に見えるワークフローの変更がないときにスプリントで発生した変更をデモするためのいくつかのオプションは何ですか？その代わり、変更は、数十分または数時間かかることもある処理ジョブの微妙なビジネスルールです？
スプリント中に価値を生み出します。スプリントの開始時と終了時の違いは常にあります。通常は、クライアントが気づく方法でも。違いを示してください。
場合によっては、スプリントは微妙に聞こえるかもしれない発見や内部の再配置を扱いますが、それでも違いを示し、あなたがそれを良いと思う理由と、加えられたすべての努力の利点は何であるかを公衆に説明できなければなりません。（？コーナーケースでは、動作する電球を作ることが不可能である方法をいくつかの方法で最初に発見したエジソンを参照できます。）
実際の処理に時間がかかる場合は、タイムジップされたビデオまたは図表のみを表示しても問題ありません。または事前に収集された結果の出力。
私自身、バックエンド作業を行うものに対する個人的な好みは、エンドユーザーの変更を見つけることです。処理中のデータが最終的にレポートに表示される場合は、レポートの前後の違いをレポートに表示します。
私は変化の欲求が必要から来たと思います。ストーリーを実行する必要性を引き起こした問題は何でしたか？ユーザーストーリーの「ボイスフォーム」は、ストーリーのユーザーとして行動することによって問題をデモできる方法を示す必要があります（つまり、ジョアンとして、ヨーロッパにいるユーザーなしでレポートを表示する必要があります）。
さらに、この場合は、テストチームに支援を求めることができます。テストチームがストーリーが完了したことを確認できた方法があったはずです。彼らはどのようにこれをしましたか？そのプロセスをデモで示すことができますか？
機能が自分で機能していることをどのようにして知っていますか？展開するときに、実際に機能することをどのように確認しますか？
これらの質問に答えられない場合は、スプリントレビューよりも大きな問題があります。デモでそれを示すことができるはずです。
スクラムでは、デモ中に、プロダクトオーナーが開発中の各ストーリーをレビューし、受け入れるか、開発に戻します。機能が動作していることを証明できる必要があります。これは通常、自動テストで行うのが最善です。受け入れテストに対応する自動テストを選び、主要な変更を強調できますか？
プロダクトオーナーも支援できる必要があります。開発中の製品を詳細に理解している必要があります。彼らは完全な実装の詳細を理解する必要はありませんが、各機能の目的（またはビジネス価値）の説明を理解できるように十分に理解する必要があります。結局のところ、プロダクトオーナーは、ストーリーを最初に実装するように依頼した人物です。