「ゆるく書いた仕様書」みたいなプロダクトバックログアイテムを今すぐ投げ捨てろ

想定する状況

• チームはスクラムを始めたばかり。プロダクトバックログは存在する。
• プロダクトバックログにはプロダクトバックログアイテムが並んでいる
• プロダクトバックログアイテムが仕様書っぽい

「プロダクトバックログアイテムが仕様書っぽい」とはどういうことか

スクラムを始めたばかりのチームではよくあることですがプロダクトバックログアイテムが本来プロダクトバックログアイテムにあるべき情報を備えていません。
かわりに仕様書っぽく作られています。

しかし仕様書というには情報に抜けが多く、過度に具体的に書かれている部分と情報が抜け落ちている部分の差が激しい状態になっています。

デザインはおおむね具体的に書かれています。デザイナーが毎日残業しながら書いているからです。

なぜかというとスクラムを導入すると大量のプロダクトバックログアイテムが生成されます。
プロダクトバックログアイテムのチケット１枚を作るのに、タイトルとゆるっと書いた仕様以外にプロダクトオーナーに書くべき項目は存在せず製造コストが安い。
そして作りたいものは無限に思いつく、というのがその理由です。

細かい仕様に関する制約も書かれます。
しかし仕様書ほど全てを網羅しているわけではありません。
「スクラムはちゃんとしたドキュメントを書かない」という絶好のエクスキューズがあるためにプロダクトオーナーが１〜数行の説明しかないチケットを書き散らす。
スクラム導入初期によくある現象です。

大変なのはデザイナーです。
チケットそれぞれにちゃんとしたデザインや画面UIをつけねばなりません。
なぜつけなばならないと考えているかというと、スクラム導入前の時からそういう仕事のやり方をしていたからです。
プロダクトオーナーは適当に書いても許されますが、デザイナーには「UIやデザインはラフでいい」という指針が与えられない限りfigmaなどでちゃんと書くことが求められる、と考えがちです。
なぜならばスクラム導入前の時からそういう仕事のやり方をしていたからです。
製造コストはプロダクトオーナーの比ではありません
そしてスクラム導入により大量のプロダクトバックログアイテムが作られてしまいました。
とりあえず優先度が高い順に一生懸命デザインをつけていくことになります。

開発者から見ると

プロダクトバックログアイテムのチケットを開くと、デザインだけはかなり具体的に決められています。
一方で仕様についてはかなりふわっとした内容しか書かれていません。
それでいてデザインの細部について疑問を抱き「なぜこうなっているのか？」というWHYを求めますがチケットのどこにもその情報はありません。

助けを求めるように完成の定義を見ますが「テストが書かれていること」「POのレビューを終わらせていること」「正常系の成功パターンと失敗パターン、異常系に考慮されていること」という一般論が並んでいて助けになる文言はありません。

スクラム導入初期にありがちなことですが、職種間のコミュニケーションは会話をせずにドキュメントやチケットで行われます。
そのため混乱がさらに拡大します。

全てが曖昧な開発

とりあえずスプリントに積まれたプロダクトバックログアイテムについて開発チームは行間を推測と忖度で補い「こんな感じかな？」と作ります。
これがプロダクトオーナーのレビューで「まあいいんじゃないですか？」とOKが出る感じです。
あるいはUIや仕様についてPOから「なんでこうなっているんですか？」と聞かれることもあります。
「チケットに書かれていないから適当に補った」か「UIデザインにそう書いてあったから従った。デザイナーに聞いてくれ」がPOへの答えとなるでしょう。
あるいはそこが差し戻しになるかもしれません。
開始時点では曖昧なのに、レビュー時点では曖昧なところを差し戻されるわけです。ストレスが溜まる開発者も多いのではないでしょうか。
当然開発スピードも上がらないでしょう。

曖昧なチケットから全てが始まり、曖昧に終わる（あるいは終わらずに差し戻される）。
それがプロダクトバックログアイテムが機能していないスクラムでよくあることです。

デザインがない場合はさらに最悪です。
デザイナーの手が足らずデザインがないのです。
しかしスプリントに積まれることもあるためデザイナーのデザイン完成を待たずに開発を開始します。
するとさらにPOレビューでの差し戻しが増えるわけです。
開発者体験はさらに悪くなりますね。

• 「デザインをつけろ」という開発者
• 「手が足りない、差し戻しを防ぐにはデザインをつけるしかない」というデザイナー
• 「差し戻しが多くて開発スピードが上がらない」とぼやくプロダクトオーナー
  よくない状況ですね。
  これは正しいスクラムなのでしょうか？
  おそらく違うと思います。

問題は何か

プロダクトオーナーは何か考えがあり、実現したいUXがあってプロダクトバックログアイテムを作ったはずです。
しかしプロダクトバックログアイテムにその考えは十分に反映されていません。

はっきり言えばプロダクトオーナー(PO)にとってUIの詳細などどうでもいいことです。
実現したいものが実現されていればそれでいいのです。
なのでデザイナーなり開発者なりがいい感じに考えて欲しいとそう考えています。
ではPOは任せたいと考えているのに、任せたくせになぜPOレビューで差し戻すのでしょうか？
答えは実現されるものが自分のイメージと合致するかチェックする機会が最終盤のPOレビューしかないからです。

デザイナーの手が遅いことが問題でしょうか？
それも正しい理解ではないと思います。

開発者は「質の悪いインプット」である手抜き仕様書もどきのプロダクトバックログアイテムを使って開発しており、それが差し戻しの多発と開発スピードの低下の原因となっています。

ではプロダクトバックログアイテムをしっかり書いた仕様書にすれば問題は解決するのでしょうか？
しかしそれはスクラムらしくはありません。

ではどうすればいいのか

スクラムにおいてATDD（受け入れテスト駆動開発）は必須要素の一つです。
プロダクトバックログアイテムをインプットとするならば受け入れテストは必須です。
そしてプロダクトバックログアイテムにつけるべき受け入れテストは「受け入れの基準」の形で実現されます。

「受け入れの基準」はプロダクトバックログアイテムについた画面遷移を表す画面ラフとテストケースによって実現されます。
受け入れの基準を誰が作るのかは明確な定義がありませんが我々のチームでは開発者が作成します。

手順としてはこうです。
プロダクトオーナーは受け入れの基準を書くのに十分な情報をプロダクトバックログアイテムに記述します。
それがスプリントプランニングでプロダクトバックログアイテムをスプリントに積める条件です。
開発者はスプリントに積まれたプロダクトバックログアイテムに対して、受け入れの基準を画面ラフとテストケースの形で記述します。そのタイミングはスプリントプランニングです。
テストケースは主に機能要件について記述されます。
またDBと接続失敗した場合のエラーと画面表示などのテストケースについてはPOが求めない限りは記述されません。記述されるテストケースは主に正常系が中心となります。
記述された受け入れの基準をプロダクトオーナーはチェックします。

この際にPOは以下のことを行います。

• UXやテストケースの指摘
• アウトプットの画面ラフとテストケースを見てのフィードバック

POがOKを出せばプロダクトバックログアイテムはReadyとなります。
またテストケースの内容については異常系など最後のテスト（呼び名はQAでもシステムテストでも）に必要なケースは別途追加されます。
テストケースの内容を元にプロダクトバックログアイテムが分割されることもあります。

受け入れの基準を使った運用にすることでの利点

開発開始時にPOは画面ラフとテストケースの形で仕様をチェックします。
受け入れテスト駆動開発においてテストケースとは仕様だからです。

そのため実装が終わった後でPOがリジェクトや差し戻しをかける数を大きく減らし、開発スピードが上げられます。

また開発者は自分で受け入れの基準を作る必要があるため、開発者がプロダクトバックログアイテムを「上流から降ってくる書類」扱いしなくなります。
その結果内容が不完全でReadyにできないプロダクトバックログアイテムが減ります。またバックログリファインメントで活発な質問が飛ぶことも期待できます。

スプリント開始時点で受け入れの基準の画面ラフとテストケースが揃うため、次スプリント以降の計画に「完成イメージ」をインプットとして使うこともできます。

受け入れの基準導入に関する意見

受け入れの基準導入は時間と手間がかかること、またスクラムには受け入れの基準は必要だが受け入れの基準はスクラムを必要としないという特徴があります。
なのでチームにスクラムを導入する前に、プロダクトバックログアイテム型のチケットと受け入れの基準を先に導入してしまうのはスムーズなスクラム立ち上げに資すると私は考えます。