休暇の物語を作るべきか？
チームメンバーがスプリントの始めに数日間休暇をとるスクラムスプリントの状況がありました。これにより、スプリントの開始時にバーンダウンチャートの理想的な傾向に遅れをとるようになりましたが、リソースがわずかに少なく、結果として配信がやや少ないことがわかっていたため、後で追いつきました。
私たちの回顧では、製品オーナーから休暇のストーリーを作成するよう提案されました。休暇が完了すると、残り時間が短縮されます。その結果、バーンダウンチャートは、チームリソースが少ないときに発生した「穴」を修正し、そうでなければ問題を誤って示すことになります。
これは良い考えですか？
番号。
まず、休暇は問題ではなく、現実です。バーンダウンチャートは、プロジェクトの進捗状況の現実を反映することになっています。プロジェクトが休暇のために別のスプリントと比較して進捗が少ない場合、適切なスプリントバーンダウンチャートはそれを反映します。
次に、休暇は（他の管理機能とともに）プロジェクトの過程で発生することが予想されます。このような中断がプロジェクトの平均スプリント速度に与える影響は、時間の経過とともに均一になります。結果の平均速度は、#OfDevelopers * SomeStandard#OfHours per Sprintのようないくつかの計算よりも、スプリントごとの利用可能な開発作業のより現実的な指標になります。
実際のストーリーではないストーリーを追加してスプリント速度を損なうと、プロジェクトの進捗状況についてこの現実的なビューが得られません。
それは良い考えではないと思います。
そのような話は、製品所有者にビジネス価値を提供しません。これは、バーンダウンチャートを機能させるためのハックに過ぎません。
ハッキングは好きではありません:)
予想される速度を調整して、バーンダウンチャートの予測完了日を単に調整しないのはなぜですか？
バーンダウンチャートは、プロダクトオーナーを含むチームが、スプリントへの取り組みを順調に進めているかどうかを判断するのに役立ちます。あなたはそれをその目的のために有用にするために必要なことは何でもすべきです。それを見て、逸脱があればすぐに説明でき、順調に進んでいるかどうかを判断できれば、休暇の話などは必要ありません。
一方で、ツールの使い方が原因でバーンダウンチャートがまったく役に立たなくなったため、人々はそれを見て気にするのをやめました。それが頻繁にあなたの状況であるなら、休暇の話のようなものが非常に役に立ちます。
個人的には、ツールが理想的なラインを線形進行以外のものに変更できればいいと思いますが、ほとんどの場合は変更できないため、ストーリーを使用してバーンダウンを調整し、線形進行を行うことは確かに問題ありません実際の進捗状況を忠実に表したものとしてチャートを保存する限りまだオフィスにいる人がいないときでもバーンダウンをきれいに見せるために操作している場合本当の進歩を遂げていないなら、あなたはそれを間違っています。
他の回答が指摘した理由により、そのようなストーリーは速度には影響せず、バーンダウンにのみ影響を与えたいことに注意してください。つまり、休暇ポイントにストーリーポイントを割り当てるのではなく、数時間だけです。
いいえ、それは標準的なアプローチではありません。
しかし、プロダクトオーナーが変更を要求したため、チームは時間の追跡/記録/特定に問題があります。だからあなたの場合には意味があるかもしれません。
一般的に、チームメンバーは、そのスプリント内に持つと信じているポイントの数に基づいてプロジェクトに入札します。つまり、各チームメンバーは、全スプリントに相当するポイントを獲得することを妨げるコミットメントを認識する必要があります。
また、アドホック会議、カスタマーサポート、管理などのために、他の「包括的な」ストーリータイプを検討する必要がある場合もあります。プロダクトオーナーがスプリントに反映されるはずのすべての時間を常に感じているわけではない場合。
これはごまかしのようなものです。それは非常に悪い考えです。
バーンダウンはあなたの本当の進歩を示します、そして明らかに誰かの休暇はあなたの製品の進歩ではありません。
POが主張する場合、私には1つの命題があります。すべてのユーザー履歴は休暇中です。人々は幸せで、燃え尽き症候群も幸せです！そして、決して、あなたの貴重なバーンダウンチャートに偏差があることは決してありません！ （それは冗談だ）
休暇が計画されていると仮定すると、それに応じて開発者に割り当てられる時間を調整するだけです。その場合、バーンダウンは最初はそれほど良くないかもしれませんが、最後には適切に追いつくはずです。
ただし、計画されていない場合は、スプリント障害として追加できます。どちらに注意する必要があります。その場合、計画外の事態が発生した場合は、遡及的に検討して、標準の割り当てを調整するか、それを無視してください（これは有効です）。
私はパーティーに遅れますが、純粋主義的な答えに対して反論することが重要です。
ベロシティチャートとバーンダウンチャートの2つの大きな理由は、PMチームの予測可能性を改善することと、レトロで役立つように明確な視覚的インジケーターを提供することです障害を特定する =。
このスプリントでこれらの休暇ポイントを考慮すると、より正確な3つのスプリントの移動平均が予測次のスプリントの容量（この休暇ではない）が得られるようにすることができます。次のスプリントの速度に影響を与える）;チームがより正確に計画を立てるのを助けます。
さらに、制御可能な影響（休暇など）によって引き起こされた分散を正規化できる場合、実際の障害が原因である可能性のある実際の変化がグラフで一目でわかると、より明確になります。レトロで議論が発生します。
一方、休暇は実際には出力されないので、純粋主義者は休暇は実際にはチームの速度を犠牲にしていると言い、これは数値に反映されるべきです。
チームとして、休暇をタイムボックス化されたスパイクと同じように（質問者が示唆するように）処理するか、トレンドを探すときにチャートで追加の計算を行って追加の煙を受け入れることができます。それはスクラムフレームワークを現在のチームと組織のニーズに合わせるについてです。
「次のスプリントでいくつの点を計画する必要があるか」という質問にどの方法で答えますか？