スクラム：不規則なイベントを推定する必要がありますか？
スクラムチームは、新しいユーザーや潜在的な顧客への概要/デモなど、不規則で計画的なイベントを推定する必要がありますか？私たちのチームはかなり小さいので、これらのイベントを準備して実施する努力は私たち（主にプロダクトオーナー、テストリード、およびスクラムマスター）に任されています。ユーザーの操作やフィードバックについてメモを取り、チームの一部がチームの一部を担当することもありました。
スクラムマスターとして、これらの会議はオーバーヘッドであり、見積もるべきではないと私は信じています。ソフトウェアに直接付加価値を与えるものではありません。その主な成果物は、新しいバックログストーリーの生成と関心のある顧客の識別です。しかし、チームは私がこれらのイベントにかなりの努力を払っていることに同意しません。私の意見では、より大きな問題は、私たちのチームメンバーがこれらのイベントの調整と参加に責任を負うことです。彼らはこれらのタスクから保護されるべきであり、それを行うために他に何もないからといって妥協すべきではないと私は信じています。
ご入力いただきありがとうございます。
極端なことを考えてみてください。チームが4週間かけて30分のデモをセットアップすると、明らかに問題が発生します。同様に、彼らがその会議で12時間を費やしている場合、何が起こっているのかを知りたいでしょう。
これらは私が提供した合理的な数値ではありません。もちろん、もっと妥当な数が必要です。この例は、単に行が存在するであることを証明するために存在するので、それがどこにあるのかを推定することには意味があります。
ただし、次の質問は、締め切りを逃した結果はどうなるかです。開発時には、問題のコードベース（維持するhrd）または問題の開発者（作業を行っていない、または作業に苦労している）の最初の兆候である可能性があります。
ただし、同じ指標は、新規ユーザー（トレーニング）および潜在的な顧客（販売/マーケティング）の概要/デモには適用されません。
時間がかかるトレーニングは、悪い生徒（または悪い先生）を示しているとは限りません。売り込みに時間がかかる場合でも、実際に商品を販売する可能性が高まれば問題はありません。
見積もりは、開発者が技術以外の管理に費やす時間を正当化する方法として使用されていますか？次に、見積もりに妥当な制限を設定する必要があります。予測からの逸脱は、イベントの予測不可能な性質を指摘することで正当化できます。
これはバグハンティングタスクと同じです。いくつかのバグはほんの数分で修正されます。他の人は数日または数週間かかります。問題が修正されるまでにかかる時間を常に知ることはできません。見積もりのポイントは正確ではありませんが、合理性の線を引くであるため、誰かがレッドフラグを立てるか、見積もりを超えて、それでもなお、タスクを介入する必要はありません配信されていません。
私の意見では、より大きな問題は、私たちのチームメンバーがこれらのイベントの調整と参加に責任を負うことです。
あなたの開発者がこの仕事をすべきではなく、他の誰かがそれをすべきだと言うなら、私はまったく同意しません。
開発者がこれに費やした時間を開発時間として数えるべきではないという意味であれば、それは正しいことです。
単純化した例として、開発者の1人が天才の会計士でもあり、経理部門が追加の手を必要としているとします。会計部門は彼がどれほど彼を必要とするかをあなたに言うことができません、彼らが言うすべては「本が正しいまで」です。
あなたは会計士ではないので、あなたが会計タスクに見積もりを出すことは意味がありません。第二に、会計士の成功の測定基準は、結果を予測する能力ではなく、実際の結果の精度で測定されます。
これらのタイプのケースでは、これらのデモ/プレゼンテーションが「開発の不在」であると考える必要があります。つまり、employee（開発者ではない）が会社が開発タスクを実行していません。
しかし、論理的な結果が迫っています。
次のスプリントを計画する必要がある場合は、彼らが不在になる期間を知る必要があります。したがって、彼らが不在になる期間を予測する必要があります。
あなたは彼らの不在を推定しますが、その推定が悪かった場合、赤旗を上げません。これは優先順位付けの問題です。デモ/プレゼンテーションが開発よりも優先されると会社が言う場合、デモ/プレゼンテーションによる正当な欠如はスプリント計画を台無しにすることになります。
あなたはそれを避けることはできません。しかし、同社はデモ/プレゼンテーションが優先されることに彼ら自身が同意したので、不正確なスプリントについてあなたを責めることもできません。
これは、病気休暇による開発者の不在、またはオフィスの火災のために部門が期限を守っていないことと実質的に違いはありません。現実は、あなたが起こると思っていたものよりも優先されました。あなたはそれを避けることはできません。意味的な定義では、予期しないことは期待できません。
会議はおそらく見積もられるべきではありませんが、それらを準備して実施するために行われる仕事はそうであるべきです。新規ユーザー向けのデモを設計することは、ソフトウェアを正確に改善するタスクではありませんが、意味のある出力（デモの設計）はあります。会議の準備には、ドキュメントなどのアーティファクトも含まれる場合があります。その一部はおそらくオーバーヘッドですが、ビジネスのために行う必要がある作業は作業です。
次の回顧展でチームと話し合って、スプリントを1〜2回試してから、再評価することをお勧めします。うまくいけば、うまくいきます！そうでない場合は、あなたとチームの両方が、それが悪い考えである理由をよりよく理解する必要があります。
これは予測できることではないと思いますが、おそらく発見することができます。
まず、プレゼンテーションの準備が含まれていないスプリントの平均速度を取得します。これがベースラインです。次に、この準備作業が行われたスプリントを見つけ、その平均速度を記録します。 2つを差し引くと、この作業のストーリーポイント値が何を伴うのかがおおまかにわかります。
人々がこの準備作業を行った個々のスプリントをより詳細に見て、通常の速度との違いを記録します。うまくいけば、準備していた正確なデモを特定できます。そのスプリントの速度の違いは、そのデモの準備によって「補う」ことができます。
いくつかの具体的な数。
準備作業のない3つのスプリントで、チームは平均68ポイントでした。準備作業が完了した他の3つのスプリントは平均62ポイントでした。この準備作業はチームにとって約6点の努力のポイントであるように見え始めているので、標準の8ストーリーポイントに切り上げます。
次に、特定のスプリントを見てください。 1人の開発者が新しいクライアントのデモを準備していたとしましょう。そのスプリントにより、チームは58ストーリーポイントを達成しました。これは、通常の速度から10ポイントの差です。先に進み、それを13ポイントに切り上げます。
つまり、特定のスプリントで新しいクライアントにアプリケーションをデモする必要がある場合、それを比較するものがあります。次に、次のいずれかを実行するだけです。
- デモに13ポイントのストーリーを追加する
- 13少ないポイントを提供することを約束
プロジェクト管理を背負わないオプションを選択してください。