私は、大きなバックエンドコンポーネントを備えたAndroidおよびiOS用の新しいモバイルアプリに取り組んでいる開発者です。私たちはこのプロジェクトの3つのスプリントに参加しており、スクラムをそのすべてのセレモニー（洗練、計画、デイリー、回顧など）で使用しています。

2つのスプリントでは、チームは残業と週末に（無給で）働かなければなりませんでした。誰もが一生懸命働きましたが、外部の依存関係と楽観的な見積もりにより、すべてのスプリントストーリーを達成するのに苦労しました。

私の経験では、一部のスプリント中にストーリーの一部が完了しないことはある程度普通であり、次のストーリーで取り組むことができます。しかし、プロジェクトマネージャーは、自分で見積もりを行ったのは私たちのせいだと言っているので、スプリントのすべての項目を完了する必要があります。

1. これは、私が知らないスクラムの許容可能な/一般的なバリエーションですか？

2. これに基づいて行動することをどのように提案しますか？

いくつかのことが際立っています。

チームが一連の作業にコミットするという経営陣の考えは、スクラムガイドの最新バージョンと矛盾しています。「コミット」または「コミットメント」という言葉は、スクラムガイドの最新（2017年11月）バージョンで2回のみ使用されます。 「。

目標の概念はスクラムにとって重要です。組織やチームが幅広い目標を持っているだけでなく、スクラムでは、各スプリントに、製品所有者と開発チーム間のコラボレーションとしてスプリント計画で定義されたスプリント目標があります。Sprint Goalは、Product Backlogの項目を実装することで満たされますが、単に「この一連の作業を終了する」だけでなく、多くの場合、完全なSprint Backlogを表すものではありません。つまり、スプリント用に選択されたすべての製品バックログアイテム、またはスプリントバックログ内のすべてのアイテムを完了することなく、スプリント目標を達成できるはずです。私の現在の考えでは、スプリントの目標を達成するために必要な作業は、チームの能力の約60〜70％である必要がありますが、能力を考慮する必要があります。ただし、異なる組織は異なるでしょうが、それは '

残業や週末の勤務も反アジャイルソフトウェア開発の実践です。根底にある原則の1つは、取り組みのすべての利害関係者が持続可能なペースで作業できることです。長い日や週末は、たとえ支払われたとしても、チームにとって持続可能ではありません。

この時点で、次のステップがいくつかあります。チームのスクラムマスターは、スクラムとアジャイルソフトウェア開発の価値と原則（「コミットメント」や「持続可能なペース」など）について経営陣を教育する必要があります。チームは、作業を予測し、プロダクトオーナーと範囲を交渉する能力に取り組む必要があります。また、チームは、この状況を引き起こした障害の解決または防止（外部依存関係の影響の排除または軽減）を特定し、それに向けて取り組む必要があります。

チームが計画されたすべてのストーリーを完了するために残業する必要がある経営者が説明する状況は、スクラムの文献が「コミットメント」という用語の使用をやめた理由の1つです。真のコミットメントは、サードパーティの依存関係、各項目の作業量、病気を考慮に入れて誰もが利用できる時間など、すべての不確実性が取り除かれた場合にのみ与えることができます。

スクラムの基本的な考え方の1つは、チームが持続可能なペースで作業するということです。これは、基本的に、残業なしの通常の時間（有給または無給）で作業することを意味します。これは、スクラムの許容可能なバリエーションを経験していないことを直接意味します。

あなたができることはあなたの役割に依存します。

あなたが開発者である場合、できる最善のことは

• （まとめて開発チームとして）スプリント内で納品できると確信している以上の作業を「コミット」することを拒否します。これはおそらく、管理者が望んでいるものよりもはるかに少ないでしょう。
• 新しいタスクに着手するのではなく、仕上げ作業に集中してください。一部の作業を完了できない場合は、計画を調整できるように、できるだけ早くこれを示してください。

スクラムの達人であれば、スクラムに関する管理者を教育することで、あなたの価値を本当に証明することができます。私に際立っているいくつかのポイント：

• 最初の段落で述べたように、チームはスプリント計画中にコミットメントを与えませんが、彼らが完了すると予想される作業の予測を与えます。
• チームはスプリントの終わりに未完成の作業を避ける必要がありますが、この状況はプロジェクトの開始時（またはチームの構成の変更後）にはほぼ避けられません。チームがスプリントで現実的に達成できる作業量は、この構成のチームの最後の数スプリントの履歴値に基づいてのみ決定できます。プロジェクトの初期段階では、このような歴史上の数字は存在しないため、最初の3つのスプリントでチームが各スプリントの計画を正確に達成することは、優れた計画よりも偶然です。持続可能なペースで約5回のスプリントを行った後、チームがスプリント内で実際にどれだけの作業を完了することができるかを合理的に把握するのに十分なデータがあります。

あなたのPMには、スクラムに関与するビジネスはありません。

PMには、未払いの残業を求めるビジネスはありません。

明らかなことは、すべてのタスクを時間内に完了することを保証できるような方法で推定することです。次に、タスクを過小評価すると無料で終了することを意味する場合、明らかに過労することは仕事のない時間を意味するため、2番目の方法でパブに行くことができるはずです。

これには多くの側面がありますが、高いレベルで、はい-PMは、計画された作業が完了していない理由を明確に理解したいと思うでしょう。ただし、これは遡及的に提起（および解決）する必要があります。開発者側からは、スプリントの失敗に寄与する多くの要因があります。

考慮したいことがいくつかあります：

スプリントが多すぎる

定期的に多くの作業を行っている場合、スプリントは失敗します。スプリント速度は、経時的に追跡して、最適なポイント数（または日数）を確認する必要があります。

資源配分

スプリント計画が、式典、休日、トレーニング、管理、サポート、およびその他のプロジェクトなどの開発以外の活動を適切に考慮していることを確認します。出発からあなたを後ろ足に乗せます。

変動を推定する

改良を行っていますが、常にオーバーランする特定の種類のタスクがありますか？一般的に、これらは要件が欠落しているかあいまいになっています。要件が羊毛質である場合、十分に洗練されているか、スパイクが計画されていない限り、ストーリーはスプリントに入らないようにする必要があります。

速度

速度が適切に追跡されている場合、ストーリーの真の数が明らかになるはずです。それは、彼らが常に時間通りに行われると言うことではありませんが、それは物事をはるかに簡単にするはずです。

善意

どのプロジェクトでも、善意は限られています。常に何時間もかけて仕事をしていると、士気が落ち、開発者が燃え尽きてしまいます。これはプロジェクト管理の失敗です。既に概説したように、スプリントプランニングでは、速度とスパイクを使用して現実的な数のストーリーのみをスケジュールし、途中で役立つようにします。

スパイク

アイテムがひどく洗練されているか、単なる羊毛のようなものである場合、後のスプリントのより良い見積もりを提供するためにスパイクを入れることを恐れないでください。はい、見積りが苦手な人もいますが、ほとんどの場合、その時点で完全な事実は知られていないだけです。理想的には、これは洗練でカバーされるか、POによって早期に取り上げられるべきですが、時にはスプリントに滑り込むこともあります。開発者はこれらのハードを押し戻すべきです。そうしないとうまくいかないスプリントを簡単に魚雷で攻撃できるからです。

いいえ、これはアジャイルの認識の形式ではない 1つの非常に重要な理由のために、：あなたが提供することにコミットしている場合、すべてを、あなたは、あなたが滝やっているアジャイルをやっていない-あなたが考える場合は、代わりにアジャイルをやっています、あなたはおそらく、Waterfallをうまくやっていないでしょう。昔の「良い、速い、安い、2つを選んで」を見たことは聞いたことがあると思いますよね？ソフトウェア開発では、「すべての機能が時間通りに、予算通りに提供され、最初のまたは他の2つを選択する」ことに似ています。Waterfallが最初を選び、Agileが2番目を選びます。

アジャイルになるためには、時間内に完了できないストーリーをスプリントからドロップする柔軟性が必要です。これを行う1つの方法は、製品所有者にMoSCoW優先順位付けを使用してストーリーを評価するよう依頼することです。これには、ストーリーの60％（ストーリーポイント合計で）を完了する必要がある必須アイテムとして選択し、20％をプロジェクトで完了する必要がある必須アイテムとして選択し、最小実行可能製品をリリースします。時間がある場合に完了する可能性のあるHaves、およびWo n't Havesとして現在のリリースの範囲外のもの。また、Must Havesを組み合わせた場合、他のカテゴリのアイテムを含める必要なく、Minimum Viable Productを作成するのに十分な肉を骨に入れる必要があることに注意することも重要です。

スプリントバックログからアイテムをドロップするかどうかの決定は、チームから要求された後、プロダクトオーナーの責任であり、スプリントバックログからドロップされたアイテムはプロダクトオーナーによって評価され、その後、プロジェクトから完全に削除されるか、適切にランク付けされたプロジェクトバックログに配置されます。

この場合、プロダクトオーナーがプロジェクトマネージャーであると思いますか？どのタスクをドロップするかを決定するのは彼の仕事です。そのため、タスクをドロップしてそれを補うのは彼の仕事であり、彼はそうしていないようです。

彼は正しい。スプリントの間に持ち越しがあってはならない。スプリント間でキャリーオーバーを行うスクラムチームはアンチパターンであり、正規のスクラムが有効な結果として受け入れるものではありません。

しかし、彼のアプローチは良いものではありません。

スプリント中、チームは、行われている作業と、選択したストーリーの仕上げに関するスプリント計画のコミットメントを維持できるかどうかを常に監視する必要があります。チームがすべてのストーリーを完了できないと判断した場合、POに会い、スプリントから削除するストーリーを選択する必要があります。そうすることで、誰もがストーリーの作業をやめ、残りのストーリーを完成させることに集中します。要確認：2つのストーリーを半分に仕上げるよりも、常に1つのストーリーを完全に仕上げる方が良いです。

外部依存性と不正確な推定の問題は、まさにレトロスペクティブが存在する理由です。Retroの実行中、チームはこれらの問題を反映して特定する必要があります。そして、チームはそれらの問題の解決策を見つけて実装する必要があります。システムと単純な経験をよりよく知ることにより、推定をより正確に行うことができます。外部依存関係はより困難ですが、修正することは不可能ではありません。

あなたのPM（スクラムチームでPMが何をしているのですか??）は、スクラムマスターがすべてのストーリーを完了するように強制することを許可されるべきではありません。代わりに、もし彼が文句を言うなら、彼はそれらを回顧展のために保管すべきです。さらに良いことには、ストーリーが時間通りに終了するのを妨げていた問題を解決することの一部であるべきです。

これは、私が知らないスクラムの許容可能な/一般的なバリエーションですか？

いいえ。それは完全に間違っています。POがスプリント終了前に見積もりを事実として提供するというミスを犯した場合、私は多分有給の残業に同情することができますが、無給の残業は完全にばかげており、私はできるだけ早く別の仕事を探します。

これについて私が行動することをどのように提案しますか？

私の経験では、それほど多くのレールを使用している人は論理的な議論を聞かないでしょう。彼らがそれがどれほど壊れているかを見る唯一の方法は、伝えるのではなく、見せることです。そのため、次回推定してコミットするときは、可能な限り最小限にコミットしてください。スプリント終了までに小さなチケットを完了することを約束します。1日でできること。PMの反応をご覧ください。その後、システムがために使用されているもので、そこから議論を開始し、どのようなシステムがなければならないために使用されます。

一般的に、プロジェクトの開始時に、チームの速度を決定するとき、新しいチームであるという事実を考慮して、保守的な（通常よりも低い）数値を求めます。チームが落ち着くには少し時間がかかります。 、お互いを理解し、機能とNFRの要件などを理解します。基本的に、最初の数回のスプリントの後、チームの速度を最適化し、明らかに速度はその時点からのみ向上します。

最初からより速い速度を約束し、それを達成するためにチームを引き伸ばすことには意味がありません。

もう1つは、見逃せない納期のコミットメントがある1回限りのシナリオでは、プロジェクトマネージャーがチームにストレッチ、遅刻、週末の作業を強いる可能性があるということです。しかし、それは例外と見なされるべきであり、仕事の規範ではありません。そのように作業すると、短期的には速度が上がる可能性がありますが、長期的にはコード品質の問題、チームのバーンアウトの問題、モチベーションの低い不幸なチームなどにつながる可能性があるため、逆効果になります。

コミットメントFAQ

この動作は正常ですか？

よく分かりません。

驚きですか？

いいえ。一部の人々は、「コミットメント」を常に理解し、コミットメントのすべてを完了する必要があることを意味します。

それは良い考えですか？

いいえ。アジャイル開発には持続可能性がありますが中心的なトピックとしてあります。無期限にできる限り多く/長く/一生懸命に作業してください。それはほとんどの場合、賢明な考えです。（経営陣がこれを受け入れない場合、彼らは彼らの組織をアジャイルと呼ぶべきではありません。）

私たちは何をすべき？

• スプリントの内容は推定に基づいていることを説明します。「推定」とは、正しい場合もあれば、通常は間違っている場合もあることを意味します。間違っているときは、低すぎたり、高すぎたりすることがあります。
• 作業速度よりも推定動作を変更する方がはるかに簡単であることを説明します。
• チームが見積もりが高すぎると処罰されると、チームは見積もりを低くするだけであり、管理者はあるスプリントから次のスプリントにコンテンツの一部を時々プッシュするよりも、そのように多くの進歩を失うことを説明します。

良い点は、プロジェクトマネージャーがこれらすべてのことを既に知っており、正しいことを認識することです。短期的にはそれらを無視することを好む可能性があるだけです。

私はあなたの経営陣に同意しません。彼らはあなたにスプリントを終わらせるために残業させてはいけません。

ただし、コミットメントが不可能であるという考えは、ソフトウェア開発の誤解に由来しています。多くのチームが、以前のスプリントで完了したストーリーポイントの数によって、スプリントで完了できるストーリーを予測しようとするのを見てきました。それが可能であれば、ソフトウェア開発は線形であると言えます。つまり、2時間働くと、1時間の2倍の時間がかかります。

ソフトウェア開発は創造的であるため、線形ではありません。チームがスプリントで何ができるかを経営陣に伝えてから、それらのストーリーを伝えることは、チームにとってより良い習慣です。一貫してコミットメントを欠いている場合、最初からストーリーの範囲がわからないか、製品所有者からさらに引き継ぐようプレッシャーがかかっています。

前者の場合、ストーリーを引き受けることに同意する前に、ストーリーの範囲を理解していることを確認する必要があります。後者の場合、文化の問題があり、実行できることはほとんどありません。