More than 3 years have passed since last update.

【スクラム】プロダクトバックログの書き方

Posted at 2022-02-21

概要

アジャイル開発におけるスクラムのプロダクトバックログの作成方法についてまとめてみた。

ユーザストーリ	デモ手順	見積もり
[Who(ユーザー・顧客)] として、[What(達成したいゴール)] をしたい。なぜなら[Why(理由) ] だから。	クライアント視点でどうのように手順で利用されるのかを書く	相対的なタスク量(フィナボッチ数)

ユーザストーリ
- この機能はなにか背景と意図が伝わるように書くこと
- 1番大事なのは、Whyの部分
  - クライアント側の意図がわかれば、よりよくものを実現してあげる時に役立つ
  - 例えば、「移動中に素早く見れるようにするためだ」とあれば、モバイルで見ることが多そうなので、モバイルベースで文字を大きくしようや、素早くなので、複雑はパス構成は避けようなどの議論が生まれる
- ここで気をつけるべきポイントは、How(方法)を書かないこと
  - Howについては、ユーザーストーリーを実現するためのタスクを開発者がスクラムチームに対して検討・整理する際に議論すべきことだから
デモ手順
- クライアント目線での手順を記載する
- スプリントレビューにおいてもこの操作を見せればよくなる
- 正解の定義にもなる
見積もり
- 具体的な時間ではなくて、作業量を相対的に出す
- フィナボッチ数で大まかに素早く見積もりを決めることができる
- 開発者が決めるので、後々で大丈夫
誰でも理解できる言葉を用いて記載する(＝専門用語を利用しない)ことを意識することもここでは重要なポイント

ストーリー	デモ手順	見積もり
動画の再生速度を変更したい。視聴者が自由に再生速度を早めることで、時間がないユーザにも動画を素早くみてもらうことができる。また、再生速度を遅くすることで、母国語ではない映像をゆっくり視聴できる。	プレイヤー内の再生速度変更のボタンを押すと再生速度一覧が表示されて、選択すると値に応じて再生速度が変更される。	3

今は必要ないこと、リリースに間に合わないかもしれないといった先入観を捨てて、なんでも追加する
- とりあえず多くの量を書く
- アイデアを書き出す
ユーザストーリ、デモ手順だけでは機能は作れないため、実際は話し合って要件を細かく落とし込む必要がある
- 話し合う機会を生む
- スプリントプランニングの時に落とし込んだりして、詳細を明確にしていく

スクラムチームで決める
- 自分達が大丈夫だと思える順番にすることで開発に自信をつける
超重要、重要、普通、あれば嬉しい、の４ジャンルに分類し、並び替える
- 超重要は、なければ業務が止まってしまうタスクやサービスの目玉
- 優先順位を決めることから始めてもOK
一列に並べる
並べ終えたら、開発初めにすぐ着手するであろう項目はもう一度順番の確認

見積もりは実際に作業する人(開発者)が決める
1,2,3,5,8,13,21...のフィナボッチ数で決定する
- フィナボッチ数を利用することで正確に見積もりを求める必要がなくなるため素早く見積もれる
- 基準のタスクがは3だとして仮に21などがあれば、不確実なことが多く実装が見えていないため、21になるってことになるため、見直す必要があるねって言う話になる
基準となる作業を決めて基準を3か5とする
- 簡単すぎても大変すぎてもダメ
- 少し大変そうで、作業の手順ややり方が想像つくものを選ぶ
プロダクトバックログの他項目は、基準をもとにどれくらいかで決める
- 各人理由も簡単に述べるとよい
あくまで推測なのでこれを決めるのに時間をかけすぎない！