スクラムでプロジェクトを開始するための製品バックログを作成するための手順
小さなチーム（3または4）は、完了するまでに1年かかる可能性のあるかなり大きなプロジェクトに取り組んでいます。
私たちは基本的に既存のソフトウェアを再設計しています（指示なしで使用されている間に5〜6年以上開発されていました）。現在、欲しいもの（機能）のリストがあります。約25個あります。
これらを効果的に多くのバックログタスクに変換し、ここから仕様を構築するにはどうすればよいですか。私たちは皆、設計プロセスにかなり慣れていないので、どんなリソースや助けもいただければ幸いです。
バックログアイテムの理想的な形式はユーザーストーリーです。
それらは簡単にメンテナンスできます。バックログは、それらを文書化するのではなく、それらを整理する（推定+優先順位付け）ためのツールであることを忘れないでください。
アジャイルライフサイクル全体のユーザーストーリー をご覧になることをお勧めします。
アジャイルについて最初に覚えておくべきことは、それは方法論というよりも哲学であるということです。あなたのために働くことをしてください。スクラムなどの形式化されたものから始めることができますが、ある時点でカスタマイズする必要があります。
私たちがしていることは、私たちが持っているすべての物語を評価しようとすることです。 1回のスプリント（私たちにとっては2週間）には複雑すぎたり大きすぎたりするものがある場合は、それを分割します。重要なチャンクに分割しようとします。たとえば、ダイアグラム表示にテキストを描画します。ストーリー1は、そこにテキストを表示することです。ストーリー2は、それを選択して移動できるようにすることです。ストーリー3は、アタッチされているものを移動するときに移動させることです。ストーリー3は、ユーザーがフォントを変更できるようにすることです...など...など...各スプリントの最後に、ビジネスリーダーがそのように決定した場合に、実際にその方法で製品をリリースできる、合理的に役立つものがあります。
このビットにはかなり時間がかかります。完璧になると思い込んだり、必然的に試みたりするべきではありません。チームが進むにつれて進歩と速度を示す、合理的に合意された何かが必要なだけです。
5〜6年で開発されたプロジェクトがあり、今度は1年しかかからない新しいプロジェクトを構築したいと考えています。現在のシステムを理解し、新しいシステムのニーズを理解し、来年中に実装される機能の優先順位を定義する権限を管理者に与えられている製品所有者がいますか？答えが「いいえ」の場合、大きな問題があり、それを解決するまで続行する必要はありません。ビジネス/ユーザー/顧客の実際のニーズに基づいてプロジェクトを定義する責任と力を持つ人が必要です。
25の機能がありますが、機能のサイズはどのくらいですか？この機能の最も一般的な説明は、ユーザーストーリーです。ユーザーストーリーは機能のドキュメントではありません。ディスカッションの内容と制約を定義するのは、将来のディスカッション/コミュニケーションの「約束」です。ユーザーストーリーは小さくする必要があります。ユーザーストーリーは1回以上の反復（スプリント）にまたがることはできません。より大きな機能がある場合は、それらをエピックとテーマと呼ぶことができます。テーマはエリア全体/ビジネスドメインであり、複数のエピックに分割できます。 Epicは、いくつかの主要な機能を定義する機能の大規模なセットであり、複数のユーザーストーリーに分割できます。
ユーザーストーリー、エピック、テーマは製品のバックログを定義しますが、反復のために計画する必要があるのはユーザーストーリーのみです。何かがエピックまたはテーマとして定義されると、それはチームが有効な見積もりを行うには大きすぎて不確実であり、計画する前に分割する必要があることを意味します。ユーザーストーリーを定義し、叙事詩とテーマを分割するのは製品所有者の仕事です。
すべての機能が最初にわかっているわけではなく、プロジェクトの最初にすべてを定義できるわけではないことは非常に一般的（かつ有効）です（これを実行しようとすると、ウォーターフォールに戻ります）。アジャイルの製品バックログは、プロジェクト全体の開発中に継続的に定義および変更されます。プロジェクトの仕様/範囲が必要な場合は、テーマとおそらく最も重要な叙事詩を定義してみましょう。このスコープは修正されません。アプリケーションを構築すると、一部のテーマ/エピック/ユーザーストーリーが廃止されているか、スケジュールによってリリースに含めることができないことがわかります。同時に、別のより重要なテーマ/叙事詩または単純なユーザーストーリーを追加できます。