ブログ

ryuzeeによるブログ記事。不定期更新
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料)

【書籍紹介】Fifty Quick Ideas To Improve Your User Stories

みなさんこんにちは。@ryuzeeです。本日は書籍のご紹介です。


  • 出版社: Neuri Consulting LLP (2014/10/12)
  • Gojko Adzic、David Evans(著)
  • 価格: 1,191円(Kindle版)
  • 言語: 英語
  • ASIN: B00OGT2U7M
詳細を見る

スクラムでプロダクトバックログアイテムを用意する際に、具体的にどのような書き方をするのかは特に決められていません

「◯◯機能」といった書き方をすることもあれば、「プレミアム会員としてホテルの部屋を予約できる」のような書き方をすることもあります。 また、解決したい課題、期限、プラットフォーム、成功失敗の判断のためのKPI、リリース希望タイミング、リファレンス情報、関係者などを含めているような会社もあるようです。 いずれにせよ、仕様書ではなく、あくまで会話のための道具なので、ステークホルダーとの間やスクラムチーム内で、共通理解や合意が形成できるのであれば、どんな形でも構いません(全部を同じ形式で書かなければいけないわけでもありません)。 また、プロダクトバックログの上位ほど具体的で、下位にいけばいくほどエピックのようなものになるのが一般的で、全部同じ粒度で書くこと自体も無駄になります。

本書**『Fifty Quick Ideas To Improve Your User Stories』** (日本語にすると「良いユーザーストーリーにするための50のアイデア」) は、タイトルのとおり、ユーザーストーリーを作ったり利用する上でのTIPSを50個まとめた書籍です。 発売自体は2014年と少々前になりますが、今でも内容自体は変わることなく、アジャイル開発チームに適用可能だと思います。

それぞれの項目は数ページ程度で簡潔にまとめられており、最初から順番に読む必要もなく、必要なときに必要な箇所を読むこともできます。 英語ですが、平易な文章なので辞書なしでも大丈夫です。

著者の1人Gojko Adzicは、他にImpact Mappingなどの本も書いているアジャイル界隈では知られた人で、本書もお勧めです。

目次(の意訳)だけでも参考になると思いますので、以下に紹介しておきます。

それでは。


ユーザーストーリーの作成

  • 詳細に書き出すのではなく話して伝える
  • フォーマットにこだわりすぎない
  • ふるまいがどう変わるかを記述する
  • システムがどう変わるかを記述する
  • 生存のための実験だと考える
  • 一般的な登場人物に気をつける
  • コントロールゾーンと影響範囲を評価する
  • いつまでにできているといちばん良いかを含める

ユーザーストーリーを使った計画づくり

  • 大きなリスクに対処するための期限を設定する
  • バックログを階層構造化する
  • インパクトでストーリーをグルーピングする
  • ユーザーストーリーマップを作ってみる
  • CREATEファネルを活用する
  • マイルストーン開始時に全体の関心事を決める
  • 成長段階に応じて優先順位を変える
  • 目標への適合性で優先順位を変える
  • ステークホルダーチャートを作る
  • マイルストンに名前をつける
  • 一部のユーザーセグメントのマイルストンに着目する

ユーザーストーリーを使った議論

  • 議論にローテクの道具を使う
  • デモを想像する
  • 議論を発散したり収束したりする
  • 全部のロールで集まって議論する
  • フィードバックエクササイズを使ってアラインメントを測定する
  • 反論役を演じてみる
  • ストーリー作成時の責任範囲を分担する
  • ビジネス上の議論と技術上の議論を分ける
  • さまざまなレベルで価値を調査する
  • QUPERモデルを使ってスライディングスケールの議論をする

ユーザーストーリーの分割

  • 成果物からはじめる
  • ウォーキングスケルトンを忘れる
  • 顧客セグメントを狭める
  • 有効性の例で分割する
  • キャパシティで分割する
  • ダミーからはじめて、その後動的にする
  • 成果を単純化する
  • 学習から分割する
  • 基本的な操作を抽出する
  • それでもダメならハンバーガーをスライスするように分割する

イテレーティブなデリバリ

  • なんでもかんでもストーリーのリストに入れない
  • 見積りの代わりに予算を使う
  • 数字のストーリーサイズを避ける
  • できあがったストーリーの数を踏まえてキャパシティを見積もる
  • 分析にかかった時間を元にキャパシティを見積もる
  • 優先順位付けでなくインパクトの大きい物を選ぶ
  • 「No」とはいわないで「今じゃない」と言う
  • 一貫性の追求作業からUX部分の改良を分離する
  • UIの大きな変更では利用者にオプトインさせる
  • 実際のユーザーと一緒に成果を確認する
  • デリバリが終わったらストーリーを捨てる