スクラム：1スプリントより長いバックログアイテムの処理方法

私はSCRUMから始めていますが、一つのことを理解するのに問題があります。SCRUMは、1つのスプリントよりも時間がかかるバックログアイテムをどのように処理しますか？

そのようなアイテムはEpicと呼ばれ、単一のスプリントよりも短く、そのために計画できるより小さなユーザーストーリーに分割するか、Epicと共通のストーリーに分割するテーマに分割する必要があります。エピックとテーマは主な特性を共有しています-高レベルの不確実性=それらは適切に推定できません（推定は通常非常に高く、そのため単一のスプリントに収まりません）。

したがって、そのようなストーリーから始めるのは良いことですが、製品所有者がそれらをより小さな特定のストーリーに分割するまで、それらを計画することはできません。これらのストーリーは、リクエストされた大きな機能（Epic）または機能セット全体（テーマ）を記録するためにのみ使用されます。これらのストーリーを破ると、機能が特定されます。

また、製品バックログの氷山構造に従います。

そのようなアイテムはありません。持っている場合、バックログアイテムは十分に具体的ではなく、小さなアイテムに適切に分割されていません。一部の人々はそれらをバックログではなくファットログ項目と呼び、スクラムではアンチパターンと見なされます。

ケーキのアナロジーユーザーストーリー：ケーキを食べる人として、私は午後にケーキを食べたいです。ある午後はケーキ全体を食べることができないので、食べられる量に合わせてスライスする必要があります。

スクラムが最初に「発明」されたとき、デフォルトのスプリントは通常4週間でした。

私が言ったことによると、この非常に長いスプリントサイズの理由は、単に、その時の人々が短いスプリントで何かを達成できると想像するのが非常に困難だったからです。

チームがスクラムに自信を持つにつれて、バックログアイテムをより管理しやすいサイズの小さなアイテムに分割する方法を学び、開発チームは事前設計をやり過ぎず、十分なことをすることで向上しました。

今日、私はほとんどのチームが4週間を非常に長いスプリント期間と見なすと信じています。私は2週間が非常に普通であるという印象です。XPチームは1週間のイテレーションのみを行い、各イテレーションで完全なユーザーストーリーを完了します。

そのため、バックログアイテムをより小さなアイテムに分割し、それぞれが最終製品のビジネス価値をわずかに増加させる必要があります。それは可能です、それは証明されています。（私はそれが難しいだろう非常に専門化されたドメインがあるかもしれないことを除外しませんが）

最近、4週間が長いスプリントであることに同意します。フィードバックループを減らして、短い作業で小さな作業単位を回避することを改善したい場合。そうすれば、間違った方向への変化が少なくなり、変化が少なくなり、一度に管理する複雑さが少なくなります。

ストーリーを分割することは、多くの場合、人々にとって問題のある領域ですが、あなたがやればやるほど、あなたはそれで良くなります。POを段階的に提供し、スプリントで価値を提供できる場合は、POと密接に連携して解決してください。

これはストーリーを分割するのに役立つ素晴らしいポスターで、agileforall.comというWebサイトから入手できます。このポスターはここで見つけることができます。

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

また、1つの短いスプリントで何かを完了することをコミットするときにそれを念頭に置いておくことができるように、洗練して計画するときに完了した定義を使用可能にすることも良いことです。