回答:
TL; DR：必要に応じてリリース
リリースに価値がある場合はいつでもリリースを行います。場合によっては、単一の機能またはバグ修正が完了した後にリリースを行うことを意味します。時にはそれは機能やバグ修正のコレクションをリリースすることを意味します。
これは、高速リリースが必要な「緊急事態」が頻繁に発生することを意味するものではありません。リリースを簡単にするために一生懸命取り組んできたということです。私たちのコードはすべてのビルドでテスト、タグ付け、パッケージ化されています。私たちは自動受け入れテストを使用しており、その結果、テストに合格したコードに高い信頼を築いています。ローカルのyumリポジトリを介してパッケージをすぐに利用できるため、リリースのデプロイは簡単です。
決して。これは「スプリント」の基本的な前提に違反しています。決心したことを終えるまで走ります。あなたが終わった後、それは本当に終わりました、そして、本当に働きます。その後、それを解放できます。
リリースは、リリース用にパッケージ化された別の種類のスプリントにすることができます。
バグ修正リリースは、短いスプリントにすぎません。同じ長さのスプリントの定期的なスケジュールがないことは、多くの人が悪い考えだと考えています。したがって、通常のルールでは、バグ修正は次のスプリント中に行われる優先度の高い作業にすぎません。
緊急の場合は、あまりにも多くのこと（サポートと開発）が行われているため、組織を変更して、より少ないことを行うことを検討する必要があります。
チームが取り組んでいる作業が、スプリント内で複数のリリースを実行するのに役立つ場合は、必要なだけリリースしてください。
同じことが、不具合修正リリースにも当てはまります。リリースすることが理にかなっている場合は、リリースしてください。
私が働いた最後のアジャイルの仕事はすべてのスプリントをリリースしました。コードは隔週木曜日（2週間のスプリント）に凍結され、その後、製品がパッケージ化され、クライアントが使用できるようにUATサーバーに公開されました。これは、製品の初期開発中です。成熟した製品、特にWebアプリではなく配布可能なプログラムの場合、2〜3週間ごとのアップグレードでユーザーに負担をかけたくないでしょう。
事実上、すべてのリリースにはストーリーポイントと欠陥（バグ）が混在していました。「理想的でない時間」として数えられる欠陥。仕事の1日の理想的な時間は5時間です。つまり、新しいポイント作業の前向きなコーディングです。残りの1日3〜4時間は、ミーティング、ディスカッション、デザイン、「スパイク」（集中的な研究/概念実証開発）、および欠陥作業です。より良い製品に貢献し、プロセスの必要な部分ですが、単にチーム全体のスプリントを取り上げることができないもの。欠陥のみのリリースを行ったのは、IPMの時点でバックログにストーリーポイントの作業がない場合のみでした。その後、QAスプリントをスケジュールし、「できるだけ多くの欠陥を解消する」ように指示されました。要件の準備が整っていないことは常にPOの責任であり（POはクライアントのために機能しました）、単に契約変更通知を発行して、私たちが持っていたもので作業することができます。もちろん、実際のストーリー作業が終わり、「保証」の開発に入ると、欠陥がすべてありました。
適切に管理されたアジャイルプロジェクトでは、要件が不足することはありません。バックログには、常にスプリントに相当する作業の準備ができている必要があります。しかし、POは時として生産要件を圧倒します。BA /テスターは、要件の品質やストーリーの競合に関連する理由により、ストーリーのリリースを開発バックログに保留することがあります。明確に定義されていないか、十分に評価されていないストーリーをチームが「パント」する必要があるとチームが判断し、残りのサイクルを簡単に取り上げることができない場合があります。要するに、アジャイルでも、たわごとが起こります。
リリースとはどういう意味ですか？PSPを意味する場合-おそらく出荷可能な製品には、2つのオプションがあります。
レベル2とレベル3の主な違いは、レベル2ではスプリントの最後に最終PSPを作成するために多少の労力を費やす必要がありますが、レベル3では最初にツールと構成にいくらかお金と労力を費やし、PSPを準備します。常に自動的に=手動での作業は必要ありません。レベル3を完全に達成することはまれです。
スクラムには、新しい機能をいつ導入するかについての規則はまったくありません。すべてのチームには「完了の定義」が必要です。これには常にテストに関する基準が含まれている必要があります。機能が「完了する」と、実際の世界で使用できるようになります。展開する前に満たす必要のある依存関係や条件がない場合は、スプリントの終了を待つ必要はありません。それを展開します。
いずれも、それがスプリントレビュー/計画会議で提示されないことを意味します。コンセプトは、チームが完了したすべてのものがPO（および他の顧客SME）に表示されるため、システムの進化に合わせてシステムの理解を深めることができるということです。
数週間後、私たちは自分たちのニーズに合った優れたソリューションを見つけました。いつでもリリースすることにしました。その方法：
それでおしまい。CIシステムとしてgitとmavenを使用しており、十分なテスト範囲があります。これが、このようにできる理由の1つです。
ほぼ2年前の質問に答えることは少し冗長かもしれませんが、うまくいけば、この質問に来た他の人に価値を追加するために、2セント程度追加したいと思います。:)
質問に答えるには、スプリントの最後に、スプリントでコミットしたことをリリースすることが望ましいです。そうすることで、他のすべての部品/プロセス/スクラムのガイドラインと結びつき、適切なタイミングで最高のビジネス価値を引き出すことに向けられます。
しかし、緊急事態、バグ、予期しないイベントなどがあなたの手を強制する可能性があります。この場合、「リリース計画」のコンセプトが役に立ちます。「リリース計画」とは、ウォーターフォールタイプの計画ではなく、製品のバックログとスプリントなどのストーリーの優先順位を管理するのに役立つ期待の計画を意味します。
しかし、恐らく、この質問に対するDavidのコメントは、最もよく検討すべきものです。スクラムは常に正しい答えとは限りません。