Scrumの記事の見積もり

Question

Scrum/XPで管理するプロジェクトを開始しました。我々は評価目的のために製品のバックログを全面的に書きました。私たちは作っていることを確認すべてのストーリーが顧客中心であり、私たちは

• ストーリービジネス価値によってそれらを評価している：モスクワ技術 - 、、、/これは
を実装していませんでしょうができなければならない必要があります
• ストーリー労力/複雑（=ストーリーポイント）：1、2、3、5、8、13、21、100 - ストーリーの複雑/努力ではなく、理想的な日の期間

100ストーリー・ポイントに関連します〜/ありませんでしたいくつかの物語を持っている可能性がありますなぜなら、実際にはもっと複雑な物語で、必要に応じて後で分解されるからです。

計算話題の重要度は、MoSCoWストーリーを重複させないことによって、値&に基づいています。

しかし、100点のストーリーがなくても、私たちの話はこれまで（また分解された）2〜8の複雑さを持ち、マイクロマネジメントを避けるための適切なストーリーサイズだと思います。しかし、いくつかの物語は互いに関連しているか、または互いに依存しています。私たちは最初にやるならばもっと多くの話をし、前に他の話がある場合はそれほど少なくなります。我々は新しいが、既存の削除、追加、それらを再評価することができますか、これは話の場合ではありません話のタスクを実行できるよう

質問
は、それは、開発中後でストーリーポイントを調整することは可能ですか？複雑さを変えるため、計画された速度に基づいて終了日の見積もりも変更されます。この場合のベストプラクティスは何ですか？

Answer 1

あなたの話をもう一度見積もることができます。ポイントは、スプリントの開始直前にスプリント計画セッションでコミットした時点でのみロックされます。私が使用した

一つの練習は、個人スプリント計画をしているときに、もう一度、各話を評価する必要があります。チームは時間とともに学習し、見積もりと依存関係の特定により正確になります。スプリントに入るのはチームまでであることを忘れないでください。プロダクトオーナーは全体のバックログを定義します。プロジェクトがタイムバインドされている場合、見積もりを終了日に合わせないようにしてください。失敗した場合は、自分自身を設定してください。

ベロシティでは、達成できるものを推測することを忘れないでください。通常、3番目または4番目のスプリントがヒットするまで、チームが管理できる現実的なベロシティを特定するまではありません。はい、これは、チームがスプリントあたり20ポイントを払うことができ、実際には15ポイントしか行うことができないと仮定している可能性があります。はい、納期が過ぎるか、物語がカットラインを下回ることを意味します。

従属ストーリーについては、製品の所有者と協力して作業する必要があります。チームが彼らと話をする場合、通常、話を並べ替えることができます。ほとんどの人は、「今私たちは今は完全なスプリントを服用すればよいが、後でそれを行うとスプリントの15％を取る」と言っている人に受け入れられる。

スプリント内でストーリーをスケジューリングするのが便利です。計画セッション中に、すべてのストーリーが検証され、議論されると、チームはカレンダーをプルアップし、何かをしたいと思ったときに議論します。カレンダーに目的の日付を入れることで、ストーリー間の重複や依存関係を特定するのに役立ちます。これは本質的に連続しているものを特定することができ、スプリントが失敗する可能性があります。

希望すると便利です。

Answer 2

私は私のexpirienceを記述することができます。

最初のスプリントを計画していたとき、私たちは18ポイントを達成できると決めました。だから我々はいくつかの話を取った、そして合計評価は15点だった。私が上で述べたように、私たちはスクラムで最初のステップを踏んでいたので、3つの未使用ポイントとフォームファクタ0.6が成功を保証すると決めました。

しかし、各ストーリーの見積もりは概算に過ぎませんでした。私たちはまた、いくつかの依存的な話をしましたそして、私たちは、それがアジャイルの方法論と変わらないと思ったので、各ストーリーの実装の計画を立てませんでした。

その結果、最初のスプリントは8ポイントしか失われませんでした。

私たちは2回目のスプリントの前に、古い良いカスケードと反復方法から何かを取るべきだと決めました（そして私はスクラムマスターでした）。そこで、私たちは来年の春の正確な見積もりを計画して、簡単な図、すべての依存関係、実装の詳細など、各ストーリー（ストーリーごとに約20分）を計画しました。計画は難しく、2回の会議が必要でした。

しかし、2回目のスプリントははるかに優れており、ほぼすべてを行っています（実際にはすべてを行っていますが、いくつかのバグがあります）。私は第3スプリントでフォームファクタを減らし成功すると思います。

Answer 3

あなたの説明からあなたはすでに素晴らしい仕事をしています。もちろん、常に依存関係のある話があります。一部の企業は、直接的に見える顧客価値を持っていない場合もあります。すなわち、アーキテクチャおよびいくつかのフレームワークを設定するための初期の努力）。しかし、あなたがそれらを残しておけば、多くの技術的負債が生まれるでしょう。可能であれば、方程式を完成させ、何らかの形でタスク間の関係を示すようにすることをお勧めします。例えば

： - 独立して行う場合、タスク3をタスク2の後に行われた場合に8点であるが、12ポイント。

この方法では、製品の所有者は、依存関係を無視しての痛みを感じるだろうが、それでも最初の最も貴重な話を行うための選択をすることができます。製品の所有者が、すべてのストーリーが次のスプリントでそれを作ることを確信している場合、最も効果的な順序でそれらのストーリーを実装するように指示できます。たとえば、依存関係が満たされていないアイテムをブロックすることによって（つまり、「webenabledバージョン」のストーリーが完了した後で、「ウェブサイト上で私のロゴを変更する」機能のみを持つことができます）

幸運を祈る！

Answer 4

彼らはあなたが特に依存関係、サイズ、テスト容易性と値を保存しようと意味INVEST、残るような方法で分割ユーザーストーリーであなたを助けるいくつかのパターンがあります。 http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/リチャードは積極的にそれらを適用し、改善しており、彼は一人ではありません;-)

ガントチャートでクリティカルパスを作成するような、依存関係の分割と保持は、チームの創造力とその話を交渉する能力を抜き、「価値のない命題」を隠す可能性があります。

HTH
ANdreaT