Blog
長期計画（リリース計画）はストーリーポイントにあるべきだと私たちは知っています。
しかし、スプリント計画の場合、それはコミットメントでなければなりません。
製品バックログアイテム/ユーザーストーリーをタスクに分割してタスクを見積もり、チームは製品バックログアイテムの提供にコミットできるかどうかを自問し、いっぱいになるまで繰り返しますか？
3週間のスプリントの場合、1人のストーリーの大きさはどれくらいにする必要がありますか？
また、一部のチームはこのタスクベースの計画を廃止し、2日間のストーリーしかありません。 ？
これをチーム用に標準化する必要がありますか？
スプリントの前に、ストーリーをこの標準に合うような短編小説に分割します。
お願いします、これについてのあなたの見解を教えてください。そして、一般的な慣行は何ですか？
から"予測"。 この変更の理由についてはこちらをご覧ください。
基本的に、計画の前提条件全体はアジャイルではありません。イテレーションをどのように計画しているか、およびチームが現在のイテレーションで完了できると考える作業をどのように見積もるかを再検討する必要があります。より詳細な分析が続きます。
長期計画（リリース計画）はストーリーポイントにあるべきだと私たちは知っています。[原文のまま]
いいえ。アジャイルリリース計画は反復で行われます。したがって、スクラムプロジェクト計画では、実行可能な最小製品に到達するか、最初の製品バックログを完了するために必要な反復の概算範囲を見積もります。これはバックログの内容は時間の経過とともに変化し、見積もりの長さと精度も Cone of Uncertainty とともに変更されるため見積もり。
ただし、スプリント計画の場合は、コミットメントベースである必要があります。
繰り返しますが、スプリント計画は容量ベース。追跡の唯一のポイント（またはチームの平均速度の最初の推測を作成することは、時間の経過とともに作業するためのチームの持続可能な能力を見つけることです。速度範囲または平均が利用可能な容量があるべきであると言っているという理由だけで、チームはスプリントでの作業に過剰にコミットしないようにする必要がありますが、チームの構成、可用性を考慮して現在の反復を計画するのはチームの責任です、および現在のスプリントに影響を与える他の要因を考慮に入れます。
スプリントが「コミットメントベース」であると言うことは、チームにコミットさせるための感情的な殴打として使用される可能性がありますもちろん、チームメンバーは「コミット」する必要があるため、 必要以上に作業します。ただし、それは「誤用です。現実の世界では、チームのキャパシティは一般的に削減する必要がありますが、計画中に膨らむことはめったにありません。チームのコミットメントが不十分な場合は、必要に応じて追加の作業を製品バックログから取り除くことができますが、トリミング範囲はほとんどの場合政治的に問題があり、スプリント目標を危険にさらすことがよくあります。ですから、そうしないでください。
容量 は比較的客観的な指標になり得ます。一方、コミットメント（愛国心のように）は「あなたがいない限り測定できません」。アジャイルな持続可能性の前提全体とは正反対の「究極の犠牲を払う」ように人々に求めます。死の行進を絶対に約束しないでください。 p>
3週間のスプリントの場合、1人のストーリーの大きさはどれくらいにする必要がありますか？
これは、「いいえ」で満たされた本全体に値します。ストーリーは、個人のサイズに合わせたり、受け入れられたりすることはありません。すべてのストーリーは、一緒に働く機能横断的なチームの完全で調整されたリソースに基づいて推定されます。 em>各ストーリーを完成させる。ストーリーは、次のいずれかに基づいて承認または拒否されます。
単一の製品バックログアイテムはどのようなものでもかまいません。 0ストーリーポイントからスプリント全体で利用可能な最大値まで再。ただし、 INVEST基準を満たす優れたストーリーは、通常、長さが約0。5日から2。0日のスプリントバックログタスクで構成されます。タスクまたはストーリーが小さいほど、通常、見積もりはより正確になるため、1ダースの5ポイントストーリー（正確に見積もられた場合）は、通常、単一の60ポイントストーリーよりも信頼性が高いことに注意してください。ただし、チームの成熟度と見積もりの精度は確かに異なる場合があります。
複数のチームメンバーが同じユーザーで作業する必要があります同時に物語。これは要件ではなく、推奨事項です。ラグビー用語の本質であるスクラム。チームはユニットとしてゴールラインに向かって進みます。この概念はスウォーミングと呼ばれます。誰もが特定の瞬間に1つ（またはそれ以下）のタスクに集中し、それを完了して、次の作業に取り組みます（繰り返し）。利点：
チームはストーリーを選び、それを技術的なタスクに分解します。この場合、毎日のスクラムミーティングで役立つ責任が明確であるため、1人の担当者だけが1つの技術タスクに取り組む必要があります。理想的には、1つの技術タスクが十分に小さく、1日で完了する必要があります。
スクラムは何も定義しませんユーザーストーリーの推奨サイズ。ただし、ストーリーは1回のスプリントで完了できるようなサイズにする必要があります。 「完了」とは、「完了の定義」をカバーすることを意味します。
ストーリーを明確に理解し、同じスプリントで検証される明確な承認基準が必要です。通常、大きなストーリーを明確にし、すべての受け入れ基準を詳しく説明するのは難しいため、ストーリーは十分に推定してテストできるように小さくする必要があります。
ストーリーも十分に大きいので、利害関係者に具体的なビジネス価値を提供します。
したがって、答えは小さすぎず大きすぎません。練習と経験を積むことで、ユーザーストーリーの作成と分割が上手になります。科学というよりは芸術です。
スプリントの計画もストーリーポイントに含める必要があります。プロセスは長期計画の場合と同じです。 速度と容量を確認します（休日などのためにチームメンバーの数がそこにいます）
スプリント2を計画している場合は、スプリント1の速度（たとえば10ポイント）を確認し、10ポイント相当のユーザーストーリーを反復バックログに入れます。
スプリント3を計画している場合は、スプリント1から2までの速度の傾向を確認し、コミットできる量を見つけます。
スプリント1を計画している場合は、
スクラムはであるため、人ができるポイントの数を確認しないようにしてください人ではなくチームについて。たとえば、ジュニアはシニアよりも少ないことができますが、人々は互いに助け合って「紙の上」ほど多くを提供することはできません。チームで作業して計算する、より理にかなっている（そして簡単である）ため。