開発者とテスターはチームと単一のスプリントを分離しました
最初の少しの背景：
以前はVサイクルプロセスで、開発チームと製品定義/テスターチームがいます（これらをテスターと呼びます）。私たちは数ヶ月前にアジャイルに移行しましたが、それでもこの分離がありました。開発知識のある人と製品の定義/テストの人です。
開発チームは、しばらくの間、自動非回帰テストとの継続的な統合をすでに行っています。テスターチームには機能テスト能力しかなく、開発の可能性はありません。
また、開発者とテスターは別の場所にいます（ビデオ会議が使用されます）。
ソリューションを支援する場合は、Jira forScrumを使用しています。
現状：
開発者とテスターは同じスクラムチームに属しています。スプリント中は全員がチームに専念します。ユーザーストーリーには受け入れ基準が正しく設定されています...これまでのところ良好です。
ただし、ユーザーストーリーのテストはテスターによって処理され、受け入れ基準をチェックしてユーザーストーリーを統合できるかどうかをテストするようなものではありません（テストを追加してチェックしますが、ユーザーの検証には使用されません）物語）。そして明らかに、テスターはコーディングの知識がないため、コーディングできません。
これにより、サイジングを行うときに、同じスプリント内の開発者とテスターの両方にとって意味のあるサイジングを行うことができないという問題が発生します。サイジングを合計すると、スプリントを計画するときに、片側に75％のワークロードがあり、もう一方にはほとんど何もない可能性が高くなります。また、片側のみのサイズを設定する場合は、片側がスプリントに適切な量になるようにしますが、反対側はそうしない場合があります。両方のサイズを設定できますが、選択が優先度と一致しない場合があります。これは、ワークロードを適応させたい場合です。
これまでのところ、私たちは開発作業のサイズを決定し、テストされていないユーザーストーリーの巨大なバックログ（テストが失敗した場合に噛みつく可能性があります）に終わりました
私があちこちで読んだことから、解決策は、受け入れ基準（自動テスト）に基づいてスプリントと開発者が検証を行うことを分離し、テスターが自分のスプリントで追加のテストを行うことです。ただし、経営陣は、すべてを1つのスプリント、1つのボードに保持することを望んでいます...
したがって、両方のチームが同じスプリントで作業することで適切なサイジングを可能にするソリューションを見つけることができないので、同じ問題に遭遇して解決策を見つけた、または可能な改善についてのアイデアを持っている人がいるかもしれません。
TLDR：
特定のグループが開発する必要があり、特定のグループが1つのグループの空き時間なしでユーザーストーリーの受け入れをテストする必要があるユーザーストーリーでスプリントを計画および管理するにはどうすればよいですか？
問題を最も単純なケースに分解してみましょう。
テストされたストーリーを配信するために、1つのストーリー、1つの開発者、1つのテスター、および1つのスプリントがあります。
ストーリーが完全に特定されている場合、開発者は半分のスプリントで作業を完了することができるはずです。開発者は配信前に仕様に対してコードをテストするため、テスターは行う作業がありません。
ストーリーが漠然と指定されている場合、テスターは本質的にストーリーにタスクを追加するテストケースを作成する必要があります。これは彼らに半分のスプリントを取ります。
ただし、これらの追加されたタスクはスプリントの開始時に不明であるため、開発者はストーリーの開発作業を完了することを確約できず、したがってそのスプリントとは何の関係もありません。
したがって、テスターと開発者がストーリーを完成させることに専念している場合、同じスプリントで同じストーリーに取り組むことは不可能です。 QED。
あなたがそれをしなければならないなら、あなたはルールを破らなければならないでしょう。テスターにストーリーのv2で作業してもらうか、開発者にストーリー全体ではなく技術的なタスクをコミットさせるか、テスターに開発者の前にストーリーで作業してもらいます。
すべてのスプリントに出入りするものはペースを調整し、両方の部分ですべての問題/タスク/アイテム（顧客と開発チーム）について合意する必要があります。したがって、開発の境界と範囲が設定され、それはテストの範囲でもあります。
タスクを詰め込んだ開発チームは、設計を開始してから実装を開始できます。一方、（スプリントのリリースを証明する）テスターは計画と設計スプリントに関係するすべてのユーザーケースである必要があります。成功のユースケース、成功の代替ユーザーケース、そして最も重要なエラーのユースケース。それらのすべて!!!。次に、テスト段階でこれらのシナリオを適用します。最後に、さらなるスプリントのために問題を追跡するプロセスを開始します。
単体テスト、統合テスト、機能テスト、回帰テストなどの計画を立てるのに時間がかかります。成功したシナリオの場合、エラーの考えられるすべてのシナリオを見つけるのにさらに時間がかかります。
テスターはエンドユーザーのようなものでなければなりません。要件とビジネスについて最新の情報を入手する。この面で、QAは、機能分析中に誰も見なかった多くの予期しないシナリオを見つけ、発生するシナリオは計画外の変更を引き起こします（そして、私たちは皆、それらが毎日発生することを知っています）。一部の変更は大きな影響を及ぼし、開発者またはアナリストは一部を見逃す可能性があります。
ただし、開発者はテスターチームの作業を容易にする必要があります。開発者は、実装に関連するすべての単体テストを実行する必要があります。必要に応じて、統合テストも行います。
共同作業です。両方のチームが協力する必要があります。同じ目標を見てください。