技術的な負債/技術のアップグレードは、機能（ポイントを与える）または雑用（ポイントを与えない）としてスケジュールする必要がありますか？

Pivotal Trackerの技術的負債のユーザーストーリーに対して、私たちは何をすべきですか？これらを特徴（ポイントを与える）または雑用（ポイントを与えず、速度を下げる）と見なす必要がありますか？

私は雑用と見なされるべきものを混乱しています：

1. コードの重複-複数の場所に同じコードを配置した場合、それはコードの習慣としては非常に悪いことであり、チームの開発者はソフトウェアを保守可能にするためにより多くの検討を行い、リファクタリングを行い、コードレビューに時間を費やす必要があることを示しています。これにはすべて、成熟度、時間、コードレベルの経験が必要になるため、提供するポイント数を少なくして、コードの品質が損なわれないようにすることをお勧めします。したがって、そのようなミスは罰せられるべきであり、雑用にポイントを与えないことによって速度を下げる必要があります。

2. テクノロジーのアップグレード-JS、HTTP2、React、MVCまたはその他の新しい/より優れたテクノロジーのモジュール化への移行のように。これらの手順により、コードのパフォーマンスとメンテナンスが改善されます。しかし、これは雑用か機能か？これがテクノロジーの世界のあり方であり、新しいテクノロジーが時々やって来て、それに移行する必要があると思います。したがって、そのような作業に対してチームの速度にペナルティを課すことには意味がありません。提案？

3. レガシーコードの複製/サブスタンダードコード-長い間使用されていないコードや、新しいチームが結成されたがコードベースが少し古い場合、この問題に直面します。チームはこのセクションをコーディングしていないので、なぜそれらの負債を作成したことがないので、なぜそのような技術的負債を選ぶことによって彼らの速度にペナルティが課せられるべきであるとチームは言います。

4. ビジネスの緊急性が原因の標準以下のコード-競合他社/ターゲット/ビジネス/ユーザーのプレッシャーが原因で、開発者は機能をすぐにライブでプッシュしなければならない場合があります。そのような悪いコードのクリーンアップも雑用（ポイントを与えない）と見なす必要がありますか？今回の開発チームに問題はないので、なぜ彼らの速度を下げなければならないのですか？

上記のすべてのタイプの雑用は、賢明に行えば、将来的にチームの速度を向上させるはずです。しかし、チームの速度を維持しながらバランスを保ち、チームが悪い決定を下すことで技術的なミスを罰する必要があるでしょうか。

質問は次のようなものです。 技術的な負債は機能または雑用（またはバグ）としてスケジュールする必要がありますか？が、4つのポイントすべてを網羅する説得力のある回答が見つからなかったため、別の方法で再投稿しています。

短い答え：技術的負債の返済は面倒です。エンドユーザーに新しい機能を提供するわけではないため、指摘されません。

公式回答：

バグや雑用はデフォルトでは推定できません

特集記事は、ビジネス価値に貢献するため推定されています。バグと雑用は、通常のソフトウェア製品のオーバーヘッドの一部と見なされます。これらは時間の経過とともに発生し、継続的なオーバーヘッドであり、ビジネスを行うための継続的なコストです。Trackerの自動速度計算は、これを組み込みコストとして考慮し、ビジネス価値のある作業を各反復でどれだけ完了できるかを見積もります。これにより、計画をビジネス価値、リスク、優先順位に集中させることができます。したがって、トラッカーのバグや雑用は通常推定されません。プロジェクト設定でバグや雑用の見積もりを有効にできます。ただし、バグと雑用の見積もりを有効にすることはお勧めしません。気が変わった場合、後でオフにすることはできません。

https://www.pivotaltracker.com/help/articles/planning_with_velocity/#bugs_and_chores

これが、バグや雑用として分類されたストーリーに、PTのデフォルト設定では見積もりを割り当てることができない理由ですが、ポイントを獲得するためだけにこれらのタスクを機能として数えるべきではない理由も説明していると思います。

まず、速度の低下をペナルティとして数えるべきではないと思います。それは単なる情報です。新しい人が加わるなど、トレーニングに余分な時間を費やす必要があったのは、自然なことかもしれません。おそらく、容量が減ったり（病気など）余分に消費されたり（たとえば、「世界を止める」バグ）予期せぬ事態でした。おそらく、何らかの理由で機能を十分に評価していなかった可能性があります。これはあなたが学ぶことができるものです。あるいは、チームとして、新機能の提供よりも技術的な負債の支​​払いを優先することを決定したためかもしれません（そして、おそらくより多くの負債を負うことになるでしょう）。

第二に、技術的負債を負うことは必ずしも間違いではありません。偶発的に発生することは理想的ではありませんが、たとえば、後でユーザーのフィードバックを得たり、ハードに会ったりするために、後で整理する必要があるという知識の中で「迅速かつダーティ」なものを構築することを決定した場合締め切りは、チームとして意図的に選択したものであり、問​​題ありません。

何かが機能であるべきかどうかに関して、簡単な経験則は次のとおりです：エンドユーザーは気にしますか？あなたはSEOの改善について言及しています：これは彼らがまったく興味を持っているものですか？彼らが気にかけるパフォーマンスかもしれませんが、一方で、ロード時間を数百ミリ秒オフにした同じ機能よりも新しい機能を搭載したほうがいいかもしれません。いくつかの調査を行います。行き、彼らに何が欲しいか尋ねます。チームの時間を費やすことが最善であるものに優先順位を付けるのを手伝ってもらいます。

現在のテクノロジーの選択により、特定の機能を必要なだけ効率的に提供できない場合があると判断する場合があります。

上記のすべてのタイプの雑用は、賢明に行えば、将来的にチームの速度を向上させるはずです。

ここで私はあなたに完全に同意しますが、これらの家事の二重カウントのポイントを獲得していませんか？後でより多くの機能を提供できるように作業を行っている場合は、作業中ではなく、完了後にベロシティが高くなるはずです。

また、コードレビューや配信プロセスでの基本的なリファクタリング（例：TDDサイクルの「リファクタリング」部分）などは、すでに進行中の作業の一部であり、チームの全体的な速度の一部としてすでに含まれているはずです。

開示：私はピボットで、ロンドンのピボタルラボで働いていますが、トラッカーチームではありません。

ただ逆らうために、私たちは他のPBIと同様にバグと技術的負債を扱います。実際、「バグ」タイプすらありません。すべてがPBIです。私たちのバックログは、PBIに割り当てられたビジネス価値によって並べ替えられます。その結果、問題を引き起こしているユーザーに直面する顕著なバグには、ビジネス上の価値が高く割り当てられます。これは、そのようなことでお金を失うリスクがあり、おそらく最初に行うことの1つです。一方、実際にはあまり影響がなく、収益に影響しないバグは、ビジネス価値が比較的低く、しばらくは修正されない可能性があります。それは取り壊されるべき重要な精神壁です：すべてのバグが修正されるべきではありません。冒涜のように聞こえるかもしれませんが、バグの修正に伴う労力が、それを修正することによるビジネス上の価値よりも大きい場合、その場合、ROIは負になります。すべてをPBIとして扱うことで、それが「バグ」であるという理由だけで気が散ることなく、これらのタイプの経験的な決定を行う自由が与えられます。

同様に、技術的負債があっても、ビジネス上の価値はまだ非常に多く残っています。一部の技術的負債は、ほとんど費用がかからずに長期的に残る可能性がありますが、一部の技術的負債は時間の経過とともにビジネスを停止させるため、非常に高いビジネス価値があります。重要なのは、すべてが単なるPBIであることを認識することです。すべてがバックログに入り、ビジネスに付加する価値に基づいて、そのバックログのアイテムに取り組みます。それが機能、バグ、または技術的負債であるかどうかは、実際には重要ではありません。

これには、質問を完全に回避するという利点もあります。すべてがPBIであるため、すべてが速度に寄与します。実際の速度ではなく、実際のサイズではない作業を行うという考えは、私にはちょっと狂気です。基本的に、経験的データに巨大なブラックホールを作成しています。速度はすでにかなり大まかなメトリックであり、それはさらに多くの推定に基づく推定に基づいた推定です。追跡されていないさまざまな量の作業を追加すると、その数はほとんど意味がなくなります。チームがスプリントで行うことはすべて、ベロシティの一部です。