スクラムでプロダクトバックログアイテムを分解するための１０の強力な戦略（早見表付き）
この記事は、Christiaan Verwijs さんの「10 powerful strategies for breaking down Product Backlog Items in Scrum (with cheatsheet)」の翻訳です。翻訳・公開については、Christiaan さんの快諾をいただいております。
誤字脱字、誤訳がありましたら、お手数ですがご指摘ください。
スクラムを熟知したチームは、プロダクトバックログ上の作業を、必要なときに（just-in-time）、より洗練されたものに分解することが、成功の鍵だと知っています。チームは、スプリントバックログが、いくつかの大きなアイテムを並べるのではなく、たくさんの小さく（機能的な）アイテムで構成されていることを好みます。小さなアイテムはフローを改善し、スプリントが失敗するリスクを減らします。この記事では、なぜ作業の分解が重要なのか、そして、なぜそれが技術的ではなく、機能的な境界を越えて行われるべきなのかを説明します。経験豊富なスクラムチームが作業を分解するために使っている10個の便利な戦略を紹介します。
早見表のダウンロード(早見表は英語のままです）
アイテムを分解する理由とタイミング
ソフトウェア開発は本質的に予測不可能です。バックログ上のプロダクトバックログアイテム(PBI)の中には、予想以上に多くの労力を必要とするものもあれば、それほど労力を必要としないものもあります。
そのため、１つの項目を過小評価してしまうと、大きなアイテムが少ししか含まれていない場合でも、スプリントに多大な影響を与えることになります。
また、大きなアイテムは見積もりや理解が難しくなりがちで、スプリントが失敗する可能性はさらに高まります。
経験豊富なスクラムチームは、大きなPBIをより小さなストーリーに分解するために時間と労力を費やしています。新しいスプリントの計画中にこの作業を行うこともありますが、スプリント、特にスプリント計画をよりスムーズに進めるためには、この「リファインメント」のプロセスを継続的に行うべきだということを学んできました。
そのため、チームはスプリントが進行中のときでも、次のスプリントのPBIを分解することにも時間を費やします。しかし、この作業は「必要な時に必要な分だけ(just-in-time-manner)」行われるため、チームはさらに先のスプリントに費やす時間をますます減らすことになります。
このように作業を分解するプロセスは、共通理解と見積もりの精度を高め、プロダクトオーナーの優先順位付けを簡単にします。しかし、作業の分解を上手に行うのは楽ではなく、”臨機応変に”実行するには練習が必要です。ありがたいことに、アジャイルコミュニティは、作業をより小さな断片に分解するための、多くの便利な戦略を編み出してくれました。
垂直分解が水平分解よりも優れている理由
大まかに言えば、大きなPBIを分解するには、2つのアプローチがあります。最初のアプローチは「水平分解(horizontal break-down)」と呼ばれるもので、行う必要がある作業の種類や、関係するレイヤーやコンポーネントによってストーリーを分解します。つまり、UI、データベース、コンポーネント、フロントエンド、テストのために行わなければならない作業は、バックログの技術的なアイテムとして分解されます。これはいくつかの理由から、スクラムではうまく機能しません。
- 個々のアイテムでは、動作するデモが可能なソフトウェアにはなりません。あるチームがスプリントでウェブショップの注文プロセスに取り組んでいるとします。PBIを水平に分解すると、デザイン、データベース、フロントエンド、テストの作業になってしまいます。これらのアイテムは確かに小さくなっていますが、それだけでは動作するソフトウェアを提供することはできません。結局のところ、UIだけが完成しても、データベースだけが修正されても、新しい機能が稼働することはありません。また、十分なテストを行わずに本番を迎えるのもよくありません。つまり、個々のアイテムは、動作し、実証可能なソフトウェア、ひいてはビジネス価値を生み出すものではありません。すべての作業の組み合わせだけがビジネス価値を生み出します。しかし、それはすべての作業が完了した場合に限ります。そして、これは次の箇条書きで説明するように、しばしば問題となります。
- ボトルネックを減らす代わりに、増加させます。水平分解は、「サイロ思考」を伴うことが多く、すべてのメンバーは、ソフトウェア開発に必要なサイロの一つから連れてこられます。「設計者」が設計を担当し、「データベース担当」がデータベースをセットアップし、「開発者」がコードを書き、「テスター」がテストを行います。チームのメンバーが交換可能でない場合(このアプローチを使用している場合はよくあることです)、ボトルネックが引き起こされます。もし「設計者」が時間通りに仕事ができなければ、設計に続くタスクに影響を与えることになります。チームメンバーはお互いに助け合うことができないので、遅延、問題、中断のたびにスプリント全体に影響を与えることになります。
- 水平方向のスライスは優先順位をつけることができません。もし、バックログが水平方向のスライスで構成されている場合、プロダクトオーナーはどのようにしてバックログに優先順位をつけることができるでしょうか？どのアイテムも、それ自体ではビジネス価値や動作するソフトウェアを提供しないため、プロダクトオーナーは作業に優先順位をつけることができません。また、スライスがかなり技術的なものになる可能性も高く、プロダクトオーナーとチームの間に距離や誤解が生じます。
PBIを水平方向に分解することで、より小さなアイテムになりますが、チームが動作するソフトウェアを提供したり、ボトルネックを回避したり、作業の優先順位付けの能力が著しく制限されます。そのため、スプリントに失敗するリスクが高まります。これは悪いアイデアです。
スクラムでは、PBIを（技術的なタスクの代わりに）より小さなPBIに分解する垂直分解が大変便利です。PBIが縦割りの場合、より小さなアイテムでも、まだ動作するデモが可能なソフトウェアとして分解されています。機能は、技術的なレイヤーやタスクにまたがって分解されるのではなく、機能的なレイヤーにまたがって分解されます。そのため、PBIが「顧客として私は注文の支払いができるので、品物を受け取ることができます」だとした場合、それは次のような小さなPBIに分解することができます。「顧客として私は電信送金で支払うことができるので、品物を受け取ることができます」または「顧客として私はクレジットカードで支払うことができるので、品物を受け取ることができます」
例え話をすると、その違いがさらに明確になります。クリーム、フルーツ、ケーキを何層にも重ねた、スライスされたケーキを想像してみてください。もしあなたがケーキを水平にカットしたとしたら、どのゲストもケーキやクリーム、フルーツのスライスしか手に入らないでしょう。きっとゲストはそれ以外のものを期待していたでしょう。ケーキの単一の層を得るだけでは、彼らはケーキ全体を試食することはできません。
馴染みのあるやり方は、ケーキ、クリーム、フルーツのそれぞれの一部が含まれるように、垂直に切り取ることです。
大規模なPBIを分解するための戦略は たくさんあります。その中でも特に使えるものを１０個集めてみました。また、このページの一番下にある便利な早見表をダウンロードすることもできます。ご覧のとおり、これらの戦略はPBIを分解するために役立つだけでなく、何が重要で何が重要でないかを決定する際にも役立ちます。このようにして、プロダクトオーナーは作業に優先順位をつけやすくなり、スクラムチームが何に時間を費やすべきかについて、より多くの情報に基づいた決定を下すことができるようになります。
戦略1：ワークフローのステップ別に分解する
PBIがある種のワークフローを含む場合、そのアイテムは通常、個々のステップに分けられます。通常のウェブショップの注文プロセスをPBIで見てみましょう。
顧客として、私は買い物かごに入っている商品の代金を支払うことができるので、自宅で商品を受け取ることができます。
よくある注文手順を考えると、次のような手順を確認することができます。
- 顧客として、私は自分のアカウントでログインできるので、毎回個人情報を再入力する必要はありません。
- 顧客として、私は注文を再検討したり、確認することができるので、支払う前に間違いを修正することができます。
- 顧客として、私は電信送金で注文を支払うことができるため、自分の注文を確認することができます。
- 顧客として、私はクレジットカードで注文を支払うことができるため、自分の注文を確認することができます。
- 顧客として、私は注文の確認メールを受け取るため、私が購入した証拠を持っています。
このように大きなPBIを分解することで、機能の理解が深まり、見積もる能力が向上しました。また、プロダクトオーナーが作業の優先順位をつけやすくなります。ワークフローのいくつかのステップは、今すぐには重要ではないかもしれません、それらは将来のスプリントに移すことができます。当分の間、注文確認メールは、手作業で行うかもしれませんし、顧客は今のところクレジットカードでしか支払えないかもしれません。また、注文のたびに個人情報を（一時的に）再入力してもらうようにしてもいいかもしれません。これは確かに、ウェブショップの機能を制限することになりますが、スプリントの最後に完成した機能をスクラムチームがレビューし（そしてデプロイし）、テストし、そのフィードバックをもとに必要な変更を行うことができます。
戦略２：ビジネスルールによって分解する
多くの場合、PBIは、明示的または暗黙的にビジネスルールと共に語られます。このプロダクトバックログを例に、再度通常のウェブショップの注文プロセスを考えてみましょう。
顧客である私は買い物かごに入っている商品を購入し、自宅で商品を受け取ることができます。
よくある注文手順を考えると、次のような「ビジネスルール」を確認することができます。
- 店のオーナーとして、10ドル以下の注文は利益が出ないので断ることができます。
- 店のオーナーとして、送料がかかると採算が合わなくなるため、アメリカ以外の国からのお客さんを断ることができます。
- 店のオーナーとして、在庫から注文した商品を48時間予約できるため、他の顧客は現実の在庫を確認することができます。
- 店のオーナーとして、48時間以内に支払いを受けていない注文を自動的にキャンセルすることができるため、他の顧客に再度販売することができます。
- ビジネスルールはときに暗黙のルールのため、見つけるにはある程度のスキルと分析力が必要になります。別の戦略を採用すると役立つかもしれません（以下で説明する#7のように）機能はどのようにしてテストされるのでしょうか？
多くの場合、テストケースは重要なビジネスルールを暗示しています。ビジネスルールが特定されれば、私たちの理解と見積もり能力は再び向上します。プロダクトオーナーは、いくつかのビジネスルールは今のところ重要ではない、あるいは簡略化した形で実装できると判断するかもしれません。48時間以内に支払いされない場合は、未払いの商品を手動で在庫に戻し、注文を手動でキャンセルしても、今のところは問題ないかもしれません。さらに現実的には、サイト上に「注文は米国外には出荷されません」とか「最低注文価格は10ドル以上でなければなりません」というメッセージがあれば、現状は十分かもしれません。このビジネスルールを実施するために必要な時間と費用を節約することができます。
戦略3：ハッピー/アンハッピーの流れで分解する
多くの場合、機能には、ハッピーフローとアンハッピーフローがあります。ハッピーフローは、すべてがうまくいっているときに機能がどのように振る舞うかを説明します。逸脱や例外、その他の問題がある場合は、アンハッピーフローが呼び出されます。
この安全なウェブサイトにログインするためのPBIを例にしてみましょう。
顧客として、私は自分のアカウントでログインすることができるので、安全なページにアクセスすることができます。
通常のログイン手順を考えると、ハッピーフローといくつかの潜在的なアンハッピーフローを確認することができます。
- ユーザーとして、自分のアカウントでログインできるので、安全なページにアクセスできます(ハッピー)。
- ユーザーとして、ログインに失敗したときにパスワードをリセットできるので、もう一度ログイン試みることができます(アンハッピー)。
- ユーザーとして、ログインがわからない場合、新しいアカウントを登録するオプションがあるため、安全なページにアクセスすることが出来ます(アンハッピー)。
- サイトの所有者として、3回連続で誤ってログインしたユーザーをブロックできるので、ハッカーからサイトを守ることができます(アンハッピー)。
アンハッピーフローは例外を記述します。様々なフローを特定することで、必要な機能をより明確に理解することができます。プロダクトオーナーは、今何が重要なのかをより簡単に判断することができます。最初のバージョンではユーザーの数が少ないため、3回の失敗でユーザーをブロックすることは今は重要ではないのかもしれません。あるいは、パスワードのリセットは、当面の間、カスタマーケアの従業員にメールを送ることで完了させられるかもしれません。繰り返しになりますが、機能を分解することで、より正確にビジネス価値について質問し、それに応じた判断をすることができるようになります。
戦略4：入力オプション/プラットフォームで分解する
ほとんどのウェブアプリケーションは、デスクトップ、タブレット、携帯電話、タッチスクリーンなど、さまざまな入力オプションやプラットフォームをサポートしなければなりません。大きなアイテムを入力オプションごとに分解することは有益かもしれません。チームのデジタルスクラムボードを例にしてみましょう。
チームメンバーとして、スクラムボードを見ることができるので、チームとしてどうやっているかがわかります。
以下のような入力オプションを確認することができます。
- チームメンバーとして、デスクトップでスクラムボードを見ることができるので、スプリントの状況を知ることができる。
- チームメンバーとして、携帯電話でスクラムボードを見ることができるので、スプリントの状況を知ることができます。
- チームメンバーとして、タッチスクリーンでスクラムボードを見ることができるので、スプリントの状況を知ることができます。
- チームメンバーとして、スクラムボードをプリントアウトして見ることができるので、スプリントの状況を知ることができます。
このように大きなアイテムを分解することで、プロダクトオーナーは、どの入力オプションやプラットフォームがより重要かを、より簡単に優先順位付けすることができます。今のところはデスクトップ版で十分なようで、モバイル版は将来のスプリントに送ることができます。あるいは、印刷に特化したバージョンを作成しなくても、当面はシンプルな PDF キャプチャで印刷出力を実装することもできます。
戦略5：データタイプやパラメータで分解する
PBIの中には、返すデータ型や扱うことになっているパラメータに基づいて分解できるものもあります。例えば、ウェブショップの検索機能を考えてみましょう。
顧客として商品を検索できるので、商品を見て注文することができます。
商品を検索する方法はたくさんあります。これらすべての潜在的なパラメータを考慮して、より小さなPBIに分解することができます。
- 顧客として、商品番号で商品を検索できるため、すでに知っている商品をすぐに見つけることができます。
- 顧客として、価格帯で商品を検索できるため、より関連性の高い検索結果が得られます。
- 顧客として、色で商品を検索できるため、より関連性の高い検索結果が得られます。
- 顧客として、商品グループ内の商品を検索できるため、より関連性の高い検索結果が得られます。
この方法で検索機能を分解することで、どのような検索パラメータが使われるのかをより明確に把握することができます。これにより、より正確に機能を見積もることができ、プロダクトオーナーが優先順位の判断をすることも可能になります。商品数が少ないため、ページングはまだ関連性がないかもしれません。商品数が増えれば関連性が高まるかもしれません。あるいは、検索機能の一部は、今のところシンプルな方法で実装できるかもしれません。この戦略のもう一つの例は、返ってくるデータ型に基づいて管理情報を含む機能を分解する場合です。情報の一部は、チャートやグラフ（data types）で視覚的に表示することができますが、表形式（datatype）で表示することもできます。おそらく、プロダクトオーナーは、データをエクセルにエクスポートして、当面はそこですべてのグラフやチャートを手動で作成しても問題ないかもしれません。
戦略6：オペレーションによる分解
PBIでは、多くの場合、Create、Read、Update、Deleted（一般的にCRUDと略される）などのようなデフォルトの操作が行われます。CRUD操作は、機能に商品、ユーザー、注文などのエンティティの管理が必要な場合に非常によく使われます。
お店のオーナーとして、ウェブショップの商品を管理できるため、価格や商品情報が変更された場合に更新することができます。
この機能に必要な個々の操作を特定することで、次のような小さな機能を導き出すことができます。
- ショップオーナーとして、新しい商品を追加することができるため、顧客はそれらを購入することができます。
- ショップオーナーとして、既存の商品を更新することができるため、価格や商品情報の変更に合わせて調整することができます。
- ショップオーナーとして、商品を削除することができるため、もう在庫のない商品を削除することができます。
- ショップオーナーとして、商品を非表示にすることができるため、しばらくの間、その商品は販売しないことができます。
この戦略を提示されたとき、多くのチームは、小さな項目が実際にビジネス価値を提供しているかどうか不思議に思うでしょう。
結局のところ、後から更新や削除ができないのに、エンティティを作成するだけに何の意味があるのでしょうか？しかし、プロダクト・オーナーは商品の数が限られているので、編集や削除はおそらくデータベースで直接行うことができます。場合によっては、操作はシンプルなフォームで簡単に実装することができます。
商品の削除には2つの方法があります。対象のレコードと関連するすべてのレコードを完全に削除するか、商品を「ソフトデリート」することができます。この場合、商品はデータベースに残っていますが、「削除済み」マークが付きます。場合によっては、これらのアプローチのうちいずれか一つは実装が簡単で、現時点では「十分事足りている」ことがあります。
戦略7：テストシナリオ／テストケースによって分解する
この戦略は、大規模なPBIを機能だけに基づいて分解することが、難しい場合に有効です。その場合、ある機能の一部がどうやってテストされるのかを求める際に役立ちます。機能がうまくいくかどうかを知るためには、どのようなシナリオをチェックする必要があるのでしょうか？タスク計画システムを考えてみましょう。
私はマネージャーとして従業員にタスクを割り当てることができるため、従業員はタスクに取り組むことができます。
この機能を潜在的なシナリオに基づいて考えると、アイテムを以下のように分解することができます。
- テストケース1：従業員がすでに割り当てられている場合、その従業員を別のタスクに割り当てることはできません。
- テストケース2：従業員が病欠届を出した場合、その従業員は視覚的にわかるようにマークをつけられます。
- テストケース3：従業員が病欠届を出した場合、その従業員はタスクに割り当てることはできません。
- テストケース4：従業員がまだ割り当てられていない場合、タスクに割り当てることができます。
- テストケース5：従業員はタッチスクリーンモニターで割り当てることができます。
この戦略は、気づかないうちに他の戦略を考慮する手助けとなります。テストについて考えることで、自動的に多くのビジネスルール（#1, #2, #3, #4）、ハッピーフロー/アンハッピーフロー（#1, #2, #3）、さらには入力オプション（#5）に至ります。テストシナリオは、テストの設定やテスト実施に関する作業で、とても複雑になることがあります。
テストシナリオが、そもそも特殊な場合や、リスクがあまり高くない場合、プロダクトオーナーは、当面の間、その機能をスキップして、より多くの価値を提供するテストシナリオに集中することができます。また、緊急性の高い問題をカバーするためにテストシナリオを簡素化することもできます。いずれにしても、関連するテストシナリオをバックログアイテムに簡単に変換して、スプリントやバックログに追加することができます。
戦略8：役割別に分解する
PBIには、多くの場合、その機能の一部を実行するために、いくつかの役割（またはグループ）が含まれています。新聞社のホームページに新しい記事を掲載するPBIを考えてみましょう。
新聞社として、ホームページに新しい記事を掲載できるため、顧客は定期的に戻ってくる理由がある
関係する様々な役割を考えることで、機能を次のような断片に分解することができます。
- 顧客として、私は新しい記事を読むことができるので、重要なイベントの情報を得ることができます。
- ジャーナリストとして記事を書くことができるので、お客様に読んでもらうことができます。
- 編集者として、サイトに載せる前に記事を確認することができので、タイプミスを防ぐことができます。
- 管理者として、サイトから記事を削除することができるので、問題のある記事を削除することが出来ます。
- 顧客として、私は注文を検討し確認することができるので、支払い前に間違いを正すことが出来ます。
機能の一部を実行しなければならない役割に分解することで、どのような機能が必要なのかをより明確に理解し、関連する作業をより正確に見積もることができるようになります。PBIを書くことは、この戦略を適用するための素晴らしい方法です。また、プロダクトオーナーの優先順位付けにも役立ちます。いくつかの役割は、現時点ではあまり関連性がなく、後からでも実装できるかもしれません。おそらく、編集者は、その時点では必要ないでしょう。もしくは、編集者はジャーナリストに呼ばれて手動で記事をチェックすることが出来ます。
戦略9：「すぐに最適化」と「後で最適化」によって分解する
多くの場合、PBIは、記載されている機能の様々な完成度と最適化の度合いによって実装することができます。このPBIを使ってみましょう。
訪問者として近隣のホテルを検索することができるため、検索結果を絞り込むことができる。
このようなストーリーは、最適化に適した様々な度合いで分解することができます。
- 訪問者として、住所から半径内にあるホテルを検索できるため、検索結果を絞り込むことができます。
- 訪問者として、郵便番号を入力して住所の自動補完ができるため、住所全体を手動で入力する必要がありません。
- 訪問者として、位置情報(GPS)を使用して近隣を検索できるため、手動で住所を入力する必要がありません。
- 訪問者として、他のホテルがバックグラウンドで読み込まれている間にも、近隣で最も検索されたホテルをすぐに取得できるため、私はより迅速に結果を得ることができます。
1つだけはっきりさせておくと。この戦略は、今は「くだらないコード」を書いて、将来は「より良いコード」を書くための口実として使われるべきではありません。スクラムチームは常に、保守性があり、（自動）テストされた、より良いコードを届けるように努めなければなりません。この戦略は、機能の最適化に関係しています。いずれにしろ、プロダクトオーナーはこれらのアイテムをより簡単に優先順位付けすることができます。訪問者は住所（と半径）で検索できれば今は十分かもしれませんが、将来的にはより複雑な機能（自動補完、GPS）が実装されることになるでしょう。
戦略10：ブラウザの互換性によって分解する
戦略4のバリエーションでは、WebアプリケーションのPBIは、さまざまなブラウザプラットフォームで動作する必要がままあります。
最近のブラウザは標準に準拠していて開発しやすい傾向にありますが、古いブラウザではすべてを正しく動作させるためにハックやカスタマイズが必要になることもよくあります。このストーリーを見てみましょう。
顧客として商品詳細を表示できるため、購入したいかどうかがわかります。
ブラウザのバージョンを考えることで、作業をより小さいアイテムに分解していくことができます。
- 顧客として、標準に準拠した最新のブラウザで商品の詳細を見ることができるので、購入したいかどうかがわかります。
- 顧客として、IE7で商品の詳細を見ることができるので、購入したいかどうかがわかります。
- 顧客として、私はテキストブラウザで商品の詳細を表示することができるので、購入したいかどうかがわかります。
この機能を、すべてのブラウザバージョンに完全に対応させて、提供することが望ましいのは確かですが、このような分解が可能なシナリオも確かにあります。おそらく、訪問者の大多数は最新のブラウザを使用しており、古いブラウザをサポートするための（警告を表示する以外の）努力は必要としないでしょう。あるいは、アプリケーションは、すべてのユーザがIE7を使用している内部ネットワーク上で実行されているかもしれません。繰り返しになりますが、これにより、プロダクトオーナーは優先順位をつけることができ、最初にチームが最も重要な機能に、時間と労力を費やすことができます。
その他の戦略
大規模なPBIを分解するときに役立つ戦略は、他にもたくさんあります。
- 特定された受け入れ条件に基づいてアイテムを分解する。これは非常に当たり前に思えますが、ストーリーを分解するための最も簡単で自然な方法であることが多いです。なぜなら、PBIの受け入れ条件を見つけ出すには、この記事で説明したのと同じような戦略が必要だからです。
- 実装が難しい部分と簡単な部分で、アイテムを分解する。高度なUIで機能の一部を構成するのは難しいかもしれませんが、単純なUIで動作するようにすることで、今のところは簡単かつ十分かもしれません。繰り返しになりますが、すべては実際に役立ちつつ、ビジネス価値を提供することです。
- 外部との依存関係でアイテムを分解する。機能が外部要因に依存していることがあります。リモートウェブサービス（電子決済やTwitterへの接続など）のためにコンシューマを実装するなどです。これは難しいかもしれませんが、優先度は高くないかもしれません。あるいは当面の間、依存関係をモックにすることもできます。
- ユーザビリティの要件でアイテムを分解する。これには、レコードのリストをページングしたり、目の不自由な人や色弱の人が読めるようにしたり、パンくずを実装したりするための機能が含まれます。
- SEO要件に基づいてアイテムを分解する。特定のキーワード専用のランディングページの設定、Googleアナリティクスのゴールの設定、XMLサイトマップの設定などです。
プロダクトバックログアイテムは、どれくらいの小ささがちょうどよいのでしょうか？
PBIがどれくらい小さければ理想的かという明確なルールはありません。これは、スプリントの長さ、アプリケーションの性質、チームの規模と経験に大きく依存します。スクラムチームがちょうどよいサイズを見つけるために、数スプリント必要とすることはよくあります。
私自身の経験では、チームは1週間のスプリントで少なくとも5つのストーリーを追加するよう努めるべきです（1日に1つ）。ストーリーの大きさは同じである必要はありませんが、大きすぎてもいけません。チームがストーリーポイントを見積もりに使っている場合、スプリントに持ち込むストーリーの最大サイズに合意しておくことがよくあります。そのため、ストーリーは（例えば）8ポイント以下の場合のみスプリントに持ち込まれます。またこれは、今後作業するリファインメントプロセスに明確なゴールを与えてくれます。
スクラムチームからのよくある懸念事項について
スクラムチームがPBIを分解しようとしているときに、よく聞く懸念事項があります。1つ目は、アイテムを小さくすることでビジネス価値が低下することをチームが心配する時です。もちろん、小さなアイテムは大きなアイテムに比べてビジネス価値が低下します。しかし、機能を分解する主な目的は、リスクを減らし、フローを増やし、各スプリントの終わりにレビューできる動く機能の量を増やすことです。代替案は、先に述べた全ての結果とリスクを伴う、非常に大きな機能の塊を使って、そのまま作業を続けることです。
もう一つの懸念は、機能を分解すると作業が増えるということです。チームにとっては、ある機能が完全に完成するまで作業を続けた方が簡単で早いということがよくあります。スプリント中に断片的な作業を再検討することは、無駄に感じます。これはある程度は正しいかもしれませんが、それでもこれを行う十分な理由があります。スクラムでは、自分たちの作業を継続的に見直し、テストし、得られたフィードバックに応じて調整するように設計されたプロセスを実装しています。そのため、今思い描いている機能と、スクラムを使ったときに実際に実装される機能は大きく異なる可能性があります。ある機能の一部に取り組み続けることは魅力的かもしれませんが、（ユーザーや利害関係者などのフィードバックに基づいて）今後変更されるであろう機能に時間を費やしている可能性が高いです。
最後の懸念は、多くのチームが機能を分解する方法をすぐに「理解」できないことです。その結果、抵抗を感じることも珍しくありません。これは理解できます。新しいことに挑戦することは、人々を弱気にさせてしまうので難しいものです。これに対処する最善の方法は、チームがPBIを分解することを粘り強く、そして優しくコーチングで助けることです。
まとめ
この記事では、（継続的に）大きなPBIを小さなものに分解することの重要性を強調してきました。スプリントは、いくつかの大きなアイテムの代わりに、多くの小さなアイテムで構成されることが望ましいです。スプリントのアイテムが少なければ少ないほど（そして大きければ大きいほど）、スプリントに失敗するリスクは大きくなります。経験豊富なスクラムチームが使用している10個のよく知られた戦略を紹介しました、あなたのチームの役に立つかもしれません。幸運を祈ります。
チートシートをダウンロードする(早見表は英語のままです）