project-management - ストーリー マップかフラット バックログか?

Question

スクラム プロジェクトの優れた視覚化/追跡の作成に苦労しているため、いくつかの代替案を検討しています。興味深い概念の 1 つに、ストーリー マッピングがあります。フラット バックログの代わりにストーリー マップを使用することについて何か意見はありますか?

Answer 1

スクラムの場合と同様に、必要と思われる最小限のことを行います。ドキュメントが多すぎると、維持できなくなり、あなたを縛ってしまうだけです。

つまり、約 15 のスクラム チームがあった以前の役割では、ストーリーが壁サイズのホワイトボードにマッピングされる「作戦室」がありました。

これらのストーリーのほとんどは「叙事詩」でした。個々のスクラム チームが後でそれらをより小さく、より管理しやすいストーリーに分割するという前提があったからです。

マップの目的は、エピック間の依存関係を特定し、どのチームがどのエピックを実行するのに最も適しているかを大まかに把握することであったため、最初は、これらのエピックに関連付けられた時間の見積もりはありませんでした。

次のイテレーションで、時間の見積もりを計算し、各チームのバックログのどこに位置するかを書き始めました。これにより、いくつかのストーリーが入れ替わりましたが、全体として、最初の推測はほぼ正しいものでした。

「戦争室」を開始してから 2、3 回のスプリントで維持が難しくなったため、その時点で、エピックが順番にリストされた Excel スプレッドシートに戻りました。しかし、その時までに、製品の所有者と顧客はプロジェクト計画を内部化していたので、それを維持する必要はありませんでした.

Answer 2

ストーリーマッピングは優れた計画手法ですが、ストーリーマップ自体を追跡に使用することはありません。マップ上で機能のバケットとして識別された機能/シナリオを使用し、駐車場のチャートを使用して各機能の進捗状況を示します。ここでの良いアイデアは、各機能の出荷に必要な最小限の機能を特定し（もちろん、それらはその機能の最も優先度の高いストーリーである必要があります）、各機能の駐車場チャートに、その最小限の機能がいつあるかを示す線を引くことです。実装されています。これは、製品が外部の利害関係者にどこにあるかを正確に示す明確な方法です。

Answer 3

あなたがリンクした記事で説明されているように、ストーリー マッピングのコンセプトは、彼らにとってうまく機能しない何かを変更した結果です。すべてのチームは異なりますが、(私の意見では) できる最善のことは、あなた (チーム) が有望だと思うことを 1 つ選び、それをスプリントで試して、次の振り返りでもう一度話し合うことです。調整を行い、さらに試して、振り返ってもう一度振り返るなどです。