【スクラム開発】ユーザーストーリーとタスクの作り方

前回はプロダクトオーナー研修の感想でした、その中のチケット作成について自分なりに受け止めたことを記載してみたいと思います。

スクラムではユーザーストーリーはPOが作るというものがあります。
しかしユーザーストーリーという概念が難しく、イマイチわからず結局実装ベースのチケットを作ってしまう。という問題がありました。
そして実装ベースのチケットを作るとエンジニアからそれでは実装しづらいなど不満が上がったりしていました。
結局エンジニアがチケットを作るという流れがあったため、何かいい手がないかと思っていました。

研修ではそこのヒントを得られた気がしているので自分なりにまとめたいと思います。

前提

・POがユーザーストーリーを作る。
・ユーザーストーリーを元にタスクはチームメンバーが作成する。

このユーザーストーリーがスクラムの特徴で、ウォーターフォールとだいぶ異なることじゃないかと思います。

・POはユーザーストーリーを書く
　・POはタスクを書いてはならない
・ユーザーストーリーとは
　・チームが何を成し遂げるか、それはなぜなのかを示す
　・通常は異なるスキルを持つ多くのチームメンバーがいてチームが実現できる内容
　・他のユーザーストーリーと独立して完成させることができる粒度にする
・タスクとは
　・チームがどうやって仕事を成し遂げるかに集中する
　・通常は同じスキルセットのチームメンバーが１〜２人で行う
　・順番に終わらせる必要がある場合が多い

どうしても開発を行っていると、機能単位のストーリーを作ってしまいがちですが、
ユーザーが何を求めて、どのような価値が提供できるかを書くとよいと思います。
※ここから下記はチケット作り方を学んだこをとベースに自分で考えたことなので間違っているかもしれません。

例）ユーザはセール商品を知ることができ、お得に買い物ができる

上記の例のようにユーザーストーリーを作った場合、エンジニアが分かりづらいということで、「セールページを作る」みたいな感じに変更してしまうことがあります。
実際自分がやっている案件でも、最初はPOがユーザーストーリーを例にならってそう書いていましたが、分かりづらいということでページ毎の名称に記載を変更したりしていました。

ただここから、「セールページを作る」ストーリー（エピック）をさらにスライスしていく必要がでてきます。

「セールページを作る」を実装視点で分割していくとしたら、「セール商品が表示される」「値段順にソートできる」「割引順にソートできる」「１クリックで購入できる」とかでしょうか。
さらに「０件表示を作る」「エラー画面を作成する」「セール情報APIを作成する」など、どんどんストーリーを作っていくことになってしまいます。
そうすると、エンジニアから「○○が不足してる」「その分割方法は作りづらい」「非機能要件が足りてない」など色々言われることになります。
またPOがエンジニアがわかる情報を書ければいいですが、すべてのPOがシステム面を熟知しているわけではありません。
エンジニアが求めるレベルでチケットを作ることは非常に難しいと思われます。結局この部分をエンジニアが作っていたりします。

そこで先程のユーザーストーリーの出番です。

「ユーザはセール商品を知ることができ、お得に買い物ができる」

これを分割するとすると
「ユーザはセール商品を知れる」「ユーザーは値段順でセール商品を知ることができる」「ユーザーは割引順でセール商品を知ることができる」「ユーザーは１クリックでセール商品を買うことができる」
さらに「セール情報はない場合もある」「セール情報には配信時間がある」「セール情報はメールで提供される」「セール情報はモバイル・PCで見ることができる」「セール情報は３秒以内に表示されることが望ましい」「セール情報が取得できない場合に適切な表示がされる」など

ポイントはユーザができるようになることだけではないということです。
分割する際に役立つポイントが以下の７つです。

ユーザ：誰がプロダクトを欲しがるのか
アクション：ユーザができること
データ：データを集積したり取り出したり
制御：ポリシー・ルールなど制約を課す（地域、年齢、最大値、最小値、QRコード必須など）
環境：どこで、（オンライン、店舗、電話）
インターフェース：システム、デバイス（レシートが印刷なのか、メールなのか）
品質特性：満たすべきパフォーマンス

上記を記載することで、エンジニアが求めるタスクではないですが、ユーザーに提供できる価値を記載することができます

また上記のようにストーリーをスライスするにはPOだけでなくチームメンバー全員と相談しながらスライスします。
そしてこれらを優先順位順に並べ変えます。

「ユーザはセール商品を知れる」
「ユーザーは値段順でセール商品を知ることができる」
「ユーザーは割引順でセール商品を知ることができる」
「ユーザーは１クリックでセール商品を買うことができる」
「セール情報はモバイル・PCで見ることができる」
「セール情報には配信時間がある」
「セール情報はメールで提供される」
「セール情報は３秒以内に表示されることが望ましい」
「セール情報はない場合もある」
「セール情報が取得できない場合に適切な表示がされる」

こうすることで、エンジニアは着手順がわかりやすくなります。

そしてここからチームメンバーはタスクを作成していきます。例えば「ユーザはセール商品を知れる」だと以下の様にタスクを作成。

ユーザはセール商品を知れる
└ セール一覧のデザインを検討する
└ セール一覧の取得APIを作成する
└ セール一覧のAPIから情報を取得する
└ デザインから画面を制作する

タスクをさらに細かくしてOKです。

このようにしておくことで、システムを詳しくないPOがチケットを作ってもエンジニアメンバーは困らないですし、タスクの優先順位もおのずと決まってきます。
エンジニアはもし着手中に足りないタスクを発見したとしてもそれは、そのストーリー上で必要なタスクなので追加すれば問題ありません。
POが作ったチケットが足りないと不満を上げることもなくなります。

こうすることで、POはどのような価値を提供することができるかということに考えを集中できますし、
エンジニアはその価値を提供するために実際にどのようなタスクをこなす必要があるかがわかります。

おまけでタスクの分け方も記載
タスクがどれに当たるかを考えて作るとよいと思います。

タスクの分け方・考え方・種類
・技術的調査（スパイク）
・フィーチャー開発（新機能）
・改善のリファクタ（ブラッシュアップ・クオリティーアップ）
・負債のリファクタ
・レガシーな部分など
・バグの修正

また見積もりのポイントですが、タスクに対してポイントを付与するのではなくストーリーに対してポイント付を行う。
それによって後々タスクが増えてポイントをつけ直すということが発生しなくなります。
※ 追加タスクが発生するとベロシティーが下がるので、ポイントには影響がない。

こうすることで、あとから出てきたタスクに対してポイントを付け直さないといけないというジレンマも解消されますし機能に対しての見積もりではないので開発時間と紐づくことも有りません。

もちろんストーリーの分割が不適切で足りない場合はあるかもしれませんが、タスクの追加よりは回数も少なくなるはずです。

と、ここまで書いておきながら、まだ実践はできていませんし、本当にそれでよくなるという実感までは持てていません。

実際の案件では、POが大きいユーザーストーリー（エピック）を作って、そのエピックを分割するストーリーをエンジニアが作っているので、分割のところをエンジニアが行ってもよい可能性もあります。POとエンジニアの認識がそろっていれば結構これがよいのではとも思っています。
ただ上記視点を持っているとよりよいようなイメージがしているので実施してみても面白いかもと思っています。

アジャイルはよい所を適用していくことではあると思うので、いろいろ試していい部分を取り入れていければと思います！