[XP]ストーリーの定義と運用事例（後編）（2024 Advent Calendar 17日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の17日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

ストーリー

本記事ではXPのストーリーの定義と自分たちのプロジェクトでの運用を紹介します。前回の記事の後編です。

ストーリーの運用: ポイントの運用のコツ

XPのストーリーを用いた開発手法をスクラムと組み合わせると、プロダクトバックログアイテムはストーリーの形式で記述されるようになります。それぞれのストーリーにストーリーポイントを付与し、全ポイントを合算することでプロダクトリリースまでの時間を見積もることができます。

さらにスクラムのスプリントでは、直近2スプリントで消化完了したポイント数の平均（ベロシティ）をもとに次のスプリントでに完了できるストーリーの数を予測することができます。

ストーリーが大きすぎる場合にはフィーチャーやタスクに分解することも検討できます。例えば、私のチームでは1～3ポイントのストーリーは問題なく扱えますが、5ポイントのストーリーは大きすぎる可能性があるので注意が必要とされ、8ポイント以上のストーリーについてはさらに細かく分解する方針を取っています。

これは、過去に8ポイントと見積もったストーリーが2週間のイテレーションを跨いでしまい、8ポイントを丸々ベロシティに計上できなかったという経験に基づきます。

例えば、今回のスプリントで8ポイントと見積もられたストーリーがスプリント内でほとんど完成したものの、スプリントレビューに間に合わず完了と見なされなかった場合、8ポイントはそのスプリントの完了として計上しませんでした。また、部分的な進捗として5ポイントや7ポイントを計上することもしていません。

この場合、残りのタスクを1ポイントと見積もって翌スプリントで完了させた場合、結果としてベロシティには1ポイントしか計上されません。同時に、スプリント中に開発者が「着手済みで順調に進んでいます」とPOに報告していても、ストーリーを完了としない限りバーンダウンチャートには何の進捗も反映されません。バーンダウンチャートのポイントが減らない状況が続くと、チームは「今回のスプリントは失敗だ。ゴールを達成できないかもしれない」と思い込んで士気が低下してしまいます。

ストーリーの運用: ストーリーのポイントが大きすぎるときの対処法

このような状況を改善するためには、次の2つの方法を組み合わせると効果的です。

手法1: ストーリーを細かいタスクに分解する 手法2: デイリーで再見積もりを提案する（スクラムでいう検査と適応）

1つ目の方法はシンプルなテクニックです。例えば、2～2.5日で終わるような2～3ポイントのストーリーには、このテクニックを適用する必要はありません。ただし、初回見積もりの時点で3日以上かかることが予想される5ポイントや8ポイント以上のストーリーには有効です。

2～3ポイントのストーリーの場合、それを分解したタスクにはポイントを設定しません。一方、5ポイントや8ポイントのストーリーの場合は、細かく分解したタスクにそれぞれにポイントを振ります。例えば、ユーザーに価値のある機能Xを実現するために8ポイントが必要と見積もった場合、機能XをタスクA、B、Cに分解して、それぞれに8ポイントを配分するのです。

この際、タスクの記述はユーザーストーリー形式にこだわらず開発者が自由に記述します。

2つ目の「デイリーで再見積もりを提案する」は勇気が必要です。「思ったより時間がかかっています」と伝えるのは簡単なことではありません。しかし、現実は変えられないため、勇気を持って状況をチームに共有しましょう。また、遅れそうだと伝えてくれたメンバーには、プロジェクトの透明性を重視している姿勢をリスペクトするべきです。

開発者としては「少し遅れそうですが間に合わせます」と言いたくなるかもしれません。しかし、その発言を聞いた周囲のメンバーは、「このストーリーは着手から最大3日以内に終わる見込みなのか？もしそうでなければ、ストーリーをさらに分解する必要があるのでは」と感じるかもしれません。そうした場合には、アイテム（ストーリーやタスク）のリファインメントを提案するのが適切です。

ストーリーについては、着手前よりも着手後の方が多くの情報が得られています。さらに、今日よりも明日の方が状況を詳しく把握できていることが多いです。このように情報が増えるということは、見積もりの判断材料も増えているということであり、より正確に見積もりを修正できるチャンスがあるということです。

毎日のスタンドアップミーティングの本質的な価値は、過去の進捗を共有するだけではなく、新たな情報を基に過去の判断を覆す必要がある場合、そのことをメンバーに共有し、チームでスプリントを見直す判断をすることにあります。

私のチームでは以前「このストーリーは重そうに見えるけど大丈夫ですか？そんなに日数をかけずに終わらせられますか？」という声かけを朝会でしていました。開発者は「大丈夫、すぐ終わります」と答え続けたのに、実際には2～3日以上が経過してしまうことがありました。周りのメンバーは進捗状況を正確に把握できなかったのです。

この経験を基に、スプリントレトロスペクティブで「今後のデイリーでは、現在取り組んでいるストーリーは着手から3日以内に終わっていますか？という質問を司会者が必ず行う」というネクストアクションを決めました。

毎日の朝会でこの質問を投げかけることにより、進捗を正確に把握しやすくなり、必要であれば再リファインメントやスプリント計画の見直しを早期に行えるようになりました。

ストーリーの運用: 具体的な作業が伝わりやすいストーリーの作り方

ストーリーの書き方にはフォーマットがあると冒頭で述べましたが、具体的な作業を想像するためにはどのように進めれば良いでしょうか。その問いの答えは、私の同僚である@tanden氏の「アジャイルで不確実性に向き合うための開発タスクの切り方」というスライドから引用します。

@tanden氏が述べる「全ての工程を含むように開発タスクを小さくする」というアプローチは、「More Effective Agile」という書籍の中で「バーティカルスライス」と呼ばれていますやり方です。各ユーザーストーリーをバーティカルスライスで開発しデリバリーすることは、アジャイル開発の重要な考え方の一つです。

短いスプリントがうまくいくには、動く機能を少しずつ頻繁にデリバリーする能力をチームが養わなければならない。こうした活動をサポートするために用いられる設計アプローチはバーティカルスライスと呼ばれる。バーティカルスライスは、増分的に機能または価値をデリバリーするために各アーキテクチャ層で変更を行う、というものである。 「More Effective Agile」9.4 基本原則：バーティカルスライスでのデリバリー

この考えを同僚の@hgsgtk氏は次のように表現しています。

「XxxAPIを実装します」や「テーブルの設計をします」といったレイヤごとの作業ではなく、「ユーザーとして自身のメールアドレスを変更できる」といったフルスタックの機能を指します。 「少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方）」| 詳説 | July Tech Festa 2020 登壇レポート

ユーザーストーリーはソフトウェアの機能を機能そのものではなく、ユーザーに対する価値として表現するものです。「全てのテーブル設計が終える」「全ての画面デザインを実装する」といった表記はユーザーストーリーとは言えません。

ユーザーに価値を素早く届けるには、ユーザー目線で何ができるかというストーリーを作成し、それを実現する機能をバーティカルスライスで開発してデリバリーすることが重要です。

ブログのシステムを例に考えると、管理画面、編集画面、一般ユーザーが見るブログ記事の閲覧画面を全て完成させてから公開するのではありません。まずは管理画面の記事一覧だけでも完成させてユーザーに見せ、フィードバックを得るのがアジャイルの姿勢です。この場合、ストーリーは「執筆者として、下書きの記事タイトルが一覧できる。ブログで発表したいアイデアがたくさんあるからだ」といった形になるでしょう。「管理画面の開発を完了する」はユーザーストーリーではないのです。

ストーリーポイントの注意点

自分たちのチームは開発の見積もりにストーリーポイントを活用していると紹介しました。

しかし、あなたの組織でストーリーポイントについて誤解が生じる場合はその使用を見直すべきだとRon Jeffries氏はブログ「ストーリーポイント再考」（"Story Points Revisited", 2019） で述べています。Ron Jeffries氏はKent Beck氏に並ぶXPの考案者の一人です。

このブログではストーリーポイントに関する誤解や誤用の例として、「見積もりは相対的なものであるにもかかわらず、AチームとBチームを比較してBチームがポイントを多く消化していれば優秀と見なされる」「マネージャーが見積もりと実際の作業時間の差に過剰反応する」といった事態を挙げています。

ストーリーポイントを誤解しているチームや組織は、アジャイル開発というものを十分に理解していない可能性があると思われます。ストーリーポイント自体が悪いわけではありませんが、それが誤用されるアジャイルの価値を十分に理解していない環境では使用を控えた方が良いのでしょう。そのような環境ではチームや開発者がリリースに対する過度なプレッシャーを受けてしまうからです。

次回はゆとりの定義と運用を解説します。