ブログ

一年半ほど前に、ユーザーストーリーを台無しにする方法について書いた。 それから現在までの間に、ぞっとするようなユーザーストーリーをほかにも見てきた。 それがこの記事を書こうと思った理由だ。 以下にあげるのが、あなたがユーザーストーリーをうまく使えていない兆候のリストだ。

1. ユーザーストーリーが単なるラッパーになっている

もしユーザーストーリーがたった1つのタスクから構成されていたとすると、それはユーザーストーリーを単なるラッパーとして使っている兆候だ。 なぜなのか私には分からないが、全てのことをユーザーストーリー形式で書かなければならないと信じている人がいるようだ。 ユーザーストーリーは「会話の約束」だ。 なんら議論のない単なるタスクが故にそのように書いてしまうんだろう。 見せかけのユーザーストーリーでラップしてはいけない。 多くの場合、これはユーザーストーリーが小さすぎることのしるしでもある。

2. ユーザーストーリーが1日以内で完了できてしまう

もしスプリントバックログに40以上のユーザーストーリーがあったとしたら、チームからコミットメントを得ることはとても難しいことになる。 チームメンバーはこんな風に言うかもしれない。 「なぁ、こんな小さなストーリーを作ることができるなんてすごくない？」 うん、これらのストーリーが全てタスクではなくストーリーだとしたらすごい。 この場合、これらの小さなストーリーは大きなストーリーに属していて、筋が通っていない。 ストーリーが新しい機能の追加を意味しているかどうかを確認してほしい。 もしそうでないなら何かが間違っている。

3. ユーザーストーリーにフィーチャーを記述してない

これは1と2の項目にもちょっと関連していて、多くの場合、同時に発生する。 もしユーザーストーリーに新しい機能の説明ではなく開発者のタスクを記述してしまっているなら間違いだ。 プロダクトオーナーが「Xのドキュメントを書く」とか「Yの受け入れテストを書く」といったユーザーストーリーを書いているのを見たことがある。 このような場合、チームの完成の定義を質問するようにしている。 というのは、これらのドキュメントを書くとかテストを書くということは明らかに完成の定義に属している話だからだ。 そして、もしこれらを完成の定義に追加したくないならば、タスクとすれば良い。 ユーザーストーリーの形式をねじ曲げてはいけない

4. ユーザーストーリーを全てのことに使う

プロダクトバックログをつくるのにユーザーストーリーを使うと決めたのは素晴らしい。 だが、ユーザーストーリー形式に限らず好きな形式を利用できるということは知っておいてほしい。 ユーザーストーリーを使わなければいけないという決まりはScrumにはないのだ。 プロダクトバックログの全ての項目でこの形式を使うことを強制されることはない。 多くの場合、例えば非機能要件を追加するときに無理にユーザーストーリー形式に揃えることは道理にかなっていない。 代わりに、これらの非機能要件はユーザーストーリーの受け入れ条件に記述するという手もある。 この非機能要件をを複数のストーリーに適用しなければならない場合には、エピックを作りそこに記述することも考えられる。 いずれにせよ、プロダクトバックログの全ての項目をユーザーストーリー形式で書こうとはしないことだ。

5. 利用者を見失っている

ユーザーストーリーにおいて、「プロジェクトマネージャーとして」とか「プロダクトマネージャーとして」とか「開発者として」とか「テスト技術者として」とか書いていないだろうか？ こうなっているとそのソフトウェアの利用者を見失っているということになる。 プロジェクトマネージャーとかプロダクトマネージャーはソフトウェアの利用者ではないはずだ。 誰がソフトウェアを使うのかという点について原点に立ち戻って考えて、利用者の視点でユーザーストーリーを書いてほしい。 別の手としてはペルソナを用意するという手もある。 いずれにせよ、常に利用者にフォーカスをあてることだ。