問題のケース:
スプリントはほぼ終了し、私のスクラムチームの1つはいくつかのタスクを完了しませんでした。 (この理由は、この質問では必須ではないので、それに応じて対処します。)それらの1つは、かなり多くのストーリーポイントを持つ古典的な「90%完了」のケースであり、次のスプリントの一部になります。質問 ここ 。
バックロググルーミングと次のスプリントのためのいくつかの予備的な見積もりを行い、この未完成のタスクを処理する方法について説明しました。このスプリントの速度にはカウントされないことに私たちは皆同意していますが、本当の複雑さと行われた作業全体をまだ見えています。そして推定を振り返ってみると正しかった。 -(スケーリングされた)アジャイルに移行しているだけであり、一部の管理レベルでは、提供された製品よりも多くの点で生産性を維持していることを「確認」する必要があります。
明らかに、このスプリントの速度は低下しますが、転送された「すでに完了した」パーツは、次のスプリントで再び上昇するはずです。
これまでのところ、全員が同意しています。
しかし、私たちのチームはかなり小さいので、4ポイントは大きなかたまりです。私はこのタスクのみと適切なドキュメントを意識的に提案することを提案しました4点の過負荷を計画します。
それは実現可能なアプローチですか、それとも私は
スプリントの最後にストーリーが完了しない場合、ストーリーのポイントはそのスプリントの速度にカウントされず、ストーリーはバックログに戻ります。
次のスプリントの計画中にストーリーが終了するように選択されている場合は、残りの作業をすばやく再推定できます。この見積もりは、計画セッション中にのみ使用してください。実際に非常に少ない作業で完了する必要のある多数のポイントを持つストーリーがスプリントに不足していないことを確認してください。
ボード上(および新しいスプリントの速度)では、持ち越されたストーリーの元の推定値を使用する必要があります。
このように持ち越されたストーリーは、速度がスプリントごとに異なる可能性がある1つの理由であり、スプリントを計画するときは、平均を使用してチームの容量を計算する必要があります。
完了していないストーリーが次のスプリントで取得されない場合、速度が上がるまでに時間がかかるため、再度取得されるときに完全なポイント値を計画することをお勧めします。再び、チームが作業を停止したときの状態を示しました。
速度を実際よりも良く見せようとしないでください。今後は、タスクが完了しなかったことを認め、スプリントで実行できることを過大評価して失敗したことを認めます。しかし、それは人生であり、学ぶ機会でもあります。
したがって、不完全なタスクの場合は0ポイントです。
新しいスプリントについては、ストーリーポイントでタスクを完了するために必要な作業を見積もり、それを通常のタスクとして数えます。
あなたはあなたの速度が低すぎるように見えることを心配しています、あなたはあなたの速度が人為的に高すぎることを心配する必要があります。
あなたが実際に達成できるよりも速い速度を持っていると、何度も何度も失敗の準備ができます。
私たちのチームでは、状況に応じて、キャリーオーバーストーリーを処理するためにいくつかの異なる方法を使用しています。
スプリントがほぼ終了し、すべての計画が既に完了している場合(他のすべてのスプリントで発生)、バックログの次のストーリーから開始します(ただし、スプリントリリースにコミットしないでください)。これらは次のスプリントに自動的に含まれ、レポート目的ですべてのストーリーポイントが次のスプリントに移動します。
ストーリーの一部が完全に完成し、それ自体にビジネス価値がある場合、通常、元のストーリーのスコープと見積もりの両方を再調整し、残りの部分はバックログに戻ります。
ストーリーの最初の見積もりがずれていた場合(大規模で複雑なストーリーの場合に発生することがあります)、それから学ぼうとします:)。現在のスプリントにストーリーポイントはありません。次のスプリント計画でストーリー全体を再推定してください。
一部のストーリーが前のスプリントから引き継がれる場合、スプリント計画では、空のスプリントバックログから開始しません。チームは、その上でどれだけ余分な作業を実行できるかを決定します。例:通常のチームキャパシティ100 SP /スプリント、20ポイントは既に進行中、チームは90個の新しいSPを取得することを決定したため、スプリントの開始時にスプリントに110個のSPが存在します。
このアプローチの主な欠点は、ベロシティレポートが一部のマネージャが望んでいるほど適切ではないことです。しかし、長期的にはすべてが均等になり、このようにして、解放可能な可能性のあるすべてのものができるだけ早く配信され、チームは彼らの作業に対するクレジットを取得します。
背景:元々このチームはスプリントの期限に非常に厳密なアプローチをとっていたため、(2週間のスプリントの)最初の週に完了するよりも大きなストーリーを取り上げることを拒否し、小さくて安全なものを使用しましたスプリントの残りの部分のために働く。これにより、スプリントの最後にニースの空のスプリントバックログが発生しましたが、これは「次は何に取り組みますか?」という質問に大きな影響を与えました。
これは簡単な答えの質問ではありません。何をすべきかについては多くの意見がありますが、まずは、満たす必要のあるさまざまなニーズを特定し、それらに基づいた解決策を考え出すことをお勧めします。例:
決定を導くのに役立つ「ガードレール」がいくつかあります。
そうは言っても、多くのチームがこれをさまざまな方法で処理するのを見てきました。
私が注目するのはこれです。「そのうちの1つは、かなり多くのストーリーポイントを持つ古典的な「90%完了」のケースです」-ここでの鍵は大きなストーリーです!投資を忘れないでください:ストーリーは小さくなければなりません。チームは、ストーリーを分割する(推奨)か、それらに群がるかを検討する必要があります。しかし、群がっていたとしても、大きいほど常にリスクが高くなります。