スクラムを使用するときに冗長な要件に対処する方法
変更可能性は、いくつかの古典的な文献で強調されている要件の品質属性です。要件の変更可能性を得るために、それらは冗長であってはなりません。
ただし、スクラムの要件に対処する場合、一部のプラクティスでは、必然的にユーザーストーリーが冗長になります。たとえば、ソフトウェアに技術的な観点から類似した多数の機能が必要であるが、ユーザーはUIで機能ごとに異なるパスを使用している場合：ストーリーを小さく保つため（INVEST）、異なるストーリーを作成しますわずかに異なるか、または異なる受け入れ基準でのみ等しい可能性さえあります。さて、ビジネス要件が変わったときは、それに応じてすべての冗長なストーリーを更新する必要があります。
通常、これは管理可能です。結局のところ、多数のオープンストーリーがあるべきではなく、少数の今後のスプリントを埋めるのに十分であるべきです。実際には（「スクラム、しかし...」）、顧客は計画可能性に関する多数の要件の内訳を要求する場合があります。ただし、大規模なスクラムでは、オープンストーリーが多数発生する場合があります。
スクラムのメリットを失うことなく、オープンストーリーの長いリストを管理できますか？
これは grooming でカバーする必要があるようです。
絶え間ない変化とは、ストーリーの修正、拡張、分割、凝縮、結合、再推定などが必要になることを意味します。
すべてのタスクを定期的にグルーミングすることをお勧めします。計画を立てる前が理想的な時期ですが、定期的または必要なだけ頻繁に行う必要があります。