ドキュメントはユーザーストーリーですか？[閉まっている]

過去数回のスプリントで取り組んできた製品のユーザーマニュアルを作成する必要があります。現在、私たちは次のスプリントで新しいプロジェクトを開始しており、POは以前に作成された製品のドキュメントをこのスプリントのユーザーストーリーにしています。

このアプローチについてのあなたの意見を知りたいだけです。個人的には、ドキュメントはコードを生成しないため、スクラム内のユーザーストーリーであることに同意しません。

編集：ご意見ありがとうございます。私は頭の後ろで、スプリントが作業ソフトウェアの増分を実装することであると思っていましたが、あなたの意見は私の見通しを変えました。答えてくれてありがとう。

「Xのユーザーとして、Xがどのように機能するかを知る必要があります」は、私にとって正当なユーザーストーリーのようです。これにより、文書またはオンラインヘルプが作成される場合があります。

ポイントは単なるコードではなく、ユーザーの要件を満たしていることです。

理想的には、ドキュメントはすべてのユーザーストーリーの一部であり、決して蓄積されることはありません。しかし、現実の世界では、それはしばしば起こりません。その場合、ドキュメントの特定の欠落部分に追いつくためのユーザーストーリーを作成する必要があります。

あなたは正しい、それはコードを生成しません。ただし、ユーザーの要件を満たしているため、他のユーザーの要件よりも優先する必要があります。

この機能が機能しているために、これが実行されないことを意味する場合、おそらくそれほどひどいドキュメントは必要ありません。

要件、技術、またはプロジェクトのドキュメントに関するpdrのドキュメント評価に同意します。理想的には、スプリント作業に組み込む必要があります。

実際にユーザーが要求する成果物であり、ユーザーに価値を直接提供するため、製品ドキュメントは非常に異なっています。これは、製品ドキュメントが本質的であることはもちろん理解されるべきではない技術的なタスクが、機能、タスク、およびまたはプロジェクトの技術的なリソースに適した活動であってもなくてもよいです。

これはユーザーのストーリーであるべきだと思いますが、ビジネス要件、ユーザーの視点、および優れたテクニカルライティングスキルをしっかりと理解しているプロジェクトリソースにこれらのタスクを割り当てる必要があると感じています。理想的には、これが利用可能な場合はビジネスアナリスト、または要件、ユーザーストーリー、優れたテクニカルライティングスキルを十分に理解している高品質のQAテスターに​​なります。これも開発者になる可能性がありますが、開発者は通常、技術的な詳細に近すぎるため、開発者が作成した製品ドキュメントはそれほど高品質または有用ではない傾向があります。

私たちの組織では、継続的インテグレーションシステムの維持と強化を担当するツールチームがスクラムを使用して作業の管理を支援しています。彼らはコードを書いていませんが、それでもスクラムを練習しています。

具体的にあなたの質問に答えるために、私はチームがドキュメントが「完了の定義」の一部であると考えるかどうか尋ねます。

ドキュメントが「完了の定義」の一部であるとチームが考える場合、追加のストーリーは不要であり、ドキュメントを作成して検証しない限り、ストーリーを受け入れることはできません。

ドキュメントが「完了の定義」の一部ではないとチームが考える場合、プロダクトオーナーが作業を管理できるように、別のストーリーを作成します。