モダンオフショアでスクラム開発④ プロダクトバックログの書き方で工夫していること

masamiohtani

July 09, 2022

1 min read

はじめに

スクラム開発において、中心となるのがプロダクトバックログ。開発チームにとっての入口であり、出口でもあります。そのため、プロダクトバックログの出来が、製品の出来に直結します。今回、POとして、プロダクトバックログの作成開始からREADYな状態に至るまでの書き方で工夫していることを紹介します。一例として目を通していただければと幸いです。

ツールの使い分け

| | | | | -------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------- | | ツール役割補足 | 役割 | 補足 | | Confluence | バックログ | JIRA内のチケットにバックログを記載することはできるが、見づらくなる。あとで仕様を確認するために検索しやすい。 | | JIRA | 優先順位付けタスク管理 | Confluenceにリンクで紐付けている。 |

Step1.プロダクトバックログの作成開始

まずは、Confluenceのみで作成を開始します。開発者は直接Confluenceを見ることないので、安心して作成することができます。 ↓テンプレートはこんな感じです。

| | | | -------------- | ---------------------------------------------------- | | ステータス | 意味 | | CREATING | まだ開発チームには公開出来ない状態 | | PENDING | バックログリファインメントで説明できる状態 | | READY | スプリントバックログに詰める状態 ※翻訳GOのタイミング |

エピック単位もしくは大きなストーリー単位でページを作成する。
- のちに大きなページ構成の変更が発生しないように。
Acceptance Criteria（受け入れ条件）は、最初は１行からでもよい。

Step2.PENDINGにするまでの作業

以前、紹介したデザインファーストというプロセスを経由して、内容を充実化していきます。

Step3.JIRAの作成

ConfluenceのバックログのステータスがPENDINGにできたら、JIRAを作成します。 JIRA自体はとてもシンプルです。

↓基本、これだけです。

件名
ラベル
エピック
修正バージョン
Confluenceへのリンク（上図の赤枠）

JIRAの準備ができたら、バックログリファインメントで開発チームに説明・相談します。

工夫していること

ストーリーの大きさは開発チームと調整することになりますが、ストーリーを細分化する必要が出た場合、大元のConfluenceのバックログはそのままで、JIRAだけを細分化することができます。とても便利です！
JIRAのタイトルにアイコンを付けて、リリース可能な単位を区別できるようにし、開発者がスプリントバックログにストーリーを追加するとき、検討しやすくなります。つまり、できるだけ同一のアイコンをスプリントバックログに入れます。いまは動物シリーズを使っていますｗ

ベトナムのオフショアメンバーとスクラムチームを組んでいますが、Acceptance Criteria（受け入れ条件）で気をつけていることがあります。

細かい（すぎる）仕様は記載せずに、開発チームに協力してもらう。

まず我々の製品は、既存サービスであり、基本的な開発コンセプトが存在しているという背景があります。
そして、開発チームに敢えて検討してもらい、提案してもらうことを期待しています。開発チームとの信頼関係が重要になります。カッコいい表現を使いましたが、POが全ての細かい仕様まで頭が回らない・気づかないということもあります😓
細かすぎる仕様をした場合、もし欠陥があったときの後戻りのほうが怖い。
細かい仕様はスプリント期間中、デイリースクラムなどで調整していきます。
QAテストに関係があるものは、Confluenceのバックログにきちんと反映します。

Step４.PENDINGからREADYにする

バックログリファインメントを経て、Screen Image（レイアウト図）とAcceptance Criteria（受け入れ条件）を確定させることができたら、ステータスをREADYにします。これで、スプリントバックログに積める状態になりましたー！　このタイミングで翻訳GOするのがベストです。 POは、スプリントバックログを修正することは原則NGですが、実際には仕様の小さな修正・追加が発生することがあり、開発と慎重に調整したうえ、スプリントゴールに影響を受けないという前提で、バックログを更新することはあります。 ↓これまでのステップをまとめると

サブタスク化

これは開発者が行うことですが、紹介しておきます。スプリントプランニング後、開発チームはスプリントバックログに積んだストーリーに対して、サブタスク化します。

開発プロセスをサブタスク化します。
デイリースクラムで進捗が確認しやすくなります。

さいごに

プロダクトバックログはちょっとした工夫が大きな効果を得られることを実感しています。ですので、デイリースクラムやレトロスペクティブなどを通じて、今後も改善していきますーもしチャンスがあれば、他のプロダクトバックログの作成方法をより多く知りたいなと。。情報交換できる方がいましたら、ご連絡いただけると嬉しいです☺️