問題：ストーリーが長すぎ、解体と評価のプロセスが複雑すぎます。 ビジネスユーザーは、開発チームが提案したレイアウトオプションに満足していません。 チームには十分な経験がなく、ストーリーの技術的な分離のみを使用します。 新しいプロジェクトが開始されており、チームにはかなり単純なユーザーストーリーを作成する機会がありません。
解決策： ハンバーガー法
過去数か月にわたって、私はユーザーストーリーを分割し、修正を
経験の浅いチームは、多くの場合、ビジネス価値を維持しながらユーザーストーリーを破壊する方法を理解できず、代わりにストーリーを技術的なタスクとコンポーネントに頑固に分割します。 ビジネスプロセスに従って分類された全体像を表示するカスタムストーリーマップのアイデアが好きです。 ユーザーストーリーを構成するタスクについても、下位レベルで同じことを行うことができます。これにより、チームを快適ゾーンから外すことはできません。 この場合、ストーリーを壊して各反復の異なる品質レベルを決定し、出力スライスの基準を決定する垂直スライスを作成します。 以下はハンバーガーの作り方です。
ステップ1：タスクの定義-ハンバーガーレイヤー
チームは、ストーリーの実装に存在する上位レベルの技術段階を決定する必要があります。 この段階では、技術的なタスクまたはコンポーネントへの分割は正常です。 肉、サラダ、トマト、チーズ-このようなタスクは、ハンバーガーの層になります-あなたはより良い味のために小さなベーコンを追加することができます。
たとえば、電子メールで非アクティブなクライアントとの通信を確立することを意味するストーリーに取り組んでいる場合、手順は次のようになります。データベースから非アクティブなクライアントを選択する。 このサンプルの手紙を送る; 配信レポートの受信。 誤った連絡先の削除。 成功した連絡先をマークします。
ステップ2：タスクを達成するためのさまざまな方法を特定する
チームをいくつかの小さなグループに分け、各タスクに異なるレベルの品質を実装する方法を決定するよう依頼します。 そのようなレベルをステッカーに書き留めてください。
たとえば、実行速度と結果の精度は、データベースからの非アクティブなクライアントのサンプルの品質の指標になる場合があります。 この場合、2つの方法があります。データベース全体から低速で比較的不正確な要求を準備する方法、または日中の変更を反映しない毎日のトランザクションに基づいてサンプルを準備する方法です。 精度を高めるもう1つの方法は、非アクティブの兆候を割り当てる夜間タスクを開始し、完了したトランザクションごとに非アクティブの兆候を削除することです。これにより、精度が向上し、タスクをより速く完了できます。 最初のオプションは、レターが毎月送信される場合にのみ機能し、2番目のオプションは制限なしで機能します。
別の例は、送信されるメールの量、コンテンツのパーソナライズ、およびスパム対策フィルターへの侵入に対する保護です。 最初のオプションは、低速で非生産的な手動郵送です。 2つ目は、手動で返信する可能性のある非パーソナライズ文字の自動送信です。 3番目の方法は、パーソナライズされた手紙の自動メールですが、手動で返信します。 4番目-パーソナライズされた自動登録解除。 また、別のオプションとして、記載されているすべての機能を提供するサードパーティのサービスとの統合があります。
ステップ3：結果の結合
ボード上の一般的なハンバーガーで受信した情報を組み合わせます。 各グループの代表者に、ハンバーガー内部の適切な場所にステッカーを貼り付けて、提示されたオプションを簡単に説明させてください。 ボードから重複するステッカーを取り外します。 品質レベルの向上に基づいて、ステッカーを左から右に並べます。
ステップ4：ハンバーガーを切る
見つかったオプションをチーム全体で調べ、実装の複雑さに基づいて互いに比較し、ステッカー上の各オプションの複雑さに注意してください。 比較しやすいように、タスクをサイズ別にグループ化できます。 どの品質の低いオプションを捨てることができるかを考えてください。その一方で、ボリュームはほぼ同じですが、高品質のオプションを残してください。
また、各タスクに必要な品質の最大レベルを決定する必要があります。 たとえば、無効なアドレスをリアルタイムで削除するプロセスを実装することは、これらのアドレスを削除する夜間のタスクよりも価値のあるオプションではありません。 ハンバーガーの境界線を超えた品質の最大レベルを超えるオプションのステッカーを用意してください-これは、ハンバーガーを「食べた」後に残るものです。
ステップ5：最初の一口を取る
ハンバーガーの準備ができたので、あなたが噛む準備ができている部分の大きさを決定します。 ハンバーガーの各層の最低許容品質レベルを決定します。 たとえば、効率が低いため手動での郵送は受け入れられないと考えていますが、毎月の送信はかなり受け入れられる場合があります。 実装の複雑さの観点から、品質の低いオプションが高品質のオプションに多少近い場合は、すぐに大きな部分を噛み切る必要があります。 たとえば、手動での購読解除を伴う非パーソナライズ文字の自動送信の実装は、MailChimpとの統合よりもそれほど複雑ではありません。 逆の例は、クライアントアクティビティをリアルタイムで更新すると、オンデマンドでのデータベースからの遅い要求よりも時間がかかる可能性があることです。 また、たとえば、無効なアドレスを削除するタスクの一部のステージでは、実装の欠如がすでに最小要件である場合があります。
ステップ6：もう一度噛み砕いて...
将来的には、ハンバーガーの新しい「バイト」ごとに高品質が提供されるようになります。たとえば、無効なアドレスを削除する最も単純な実装でも、品質が向上し、頻繁に郵送されるようになります。 「噛まれた」ハンバーガーのサイズを決める前に、可能なオプションを実装する難しさを常に比較してください。
この方法は、十分に視覚的であるという事実により、そもそもうまく機能します。これは、チームが快適な領域にとどまり、別の方法を考えるのに役立ちます。 ハンバーガーを噛むことへのアナロジーもうまく機能します。 この方法を使用すると、通常、ハンバーガーのサラダだけを選択することはないため、履歴のコンテキストでの個々のコンポーネントの実装が意味をなさない理由を簡単に説明できます。 少なくとも彼らが空腹である間。