『ZenHub x GitHub』を使ったプロダクトバックログ運用について

以前、下記のような記事を書いたが運用が固まってきたので新しく書きます。

■ ZenHubとは

• 基本的に、ZenHub Guidesを参照していただければ概要については掴めます。

■ZenHubを使った最初のスプリント※参考程度

ZenHubを使った最初のスプリントの仕方についてです。ある程度公式に書かれているものをベースに作っていきます。https://www.zenhub.com/guides/your-first-sprint-using-zenhub

■全体俯瞰図

サマリー

1. 基本的にOrganizationの中で操作します。
2. プロダクトバックログの可視化について、専用の『backlog』というチケット可視化専用のリポジトリを用意し、その中にZenHubのBoradを用意します。
3. プロダクトオーナーは、普段どおり、『backlog』に対してプロダクトバックログを積んでいきます。
4. ScrumTeamは、各リポジトリ(ex.api, infra, lambda)に対して、各自やったほうがよいものを各リポジトリのIssueとして、随時発行していきます。※バグや改善ポイント….etc
5. ZenHubのBoardには、Organizationと紐づくリポジトリのIssueをMergeする機能があるためMergeし、『backlog』のBoardに指定したリポジトリのIssueが可視化できるようにします。

メリット

1. リポジトリを起因にIssueを発行することで、どのコンポーネントに対してコミットすればよいかわかる。
2. ZenHubを使うことで1.のIssueが一元管理 / 可視化できる。
3. コミットとチケットを紐付けることができる。
4. バグや改善ポイントを気軽にリポジトリに対して開発者が発行できる。

ざっくりとした運用方法については

1. 開発者は、気づいたことをIssueとして発行する。
2. POは普段どおりストーリーをベースとしてPBIを作成し続ける。
3. スプリントプランニングの際に1,2を精査し、スプリントバックログを作っていく。といった形です。

■ 利用機能について

下記に運用について記載していきます。

独自レーンの説明

Epic

エピックについては、ある程度のストーリーごとに作成していき、ストーリに紐づくPBIを追跡できるようにします。

Milestones

マイルストーン機能で、特定の期間を作成できるのでこちらを利用してスプリントを作成していきます。

Release reports

リリースレポート機能を使って、リリースバージョンを作成していきます。

• 何をリリースするか。
• Release reportsのタグとPBIをつも付けていき、該当PBIがいつリリースされるインクリメントなのかを可視化します。
• 開始日
• こちらはリリース運用にもよりますが、おそらくスプリントの開始日となる予定です。
• リリース日

Burndown charts

スプリントごとにグラフ化していきます。

Velocity Tracking

スプリントの終わりにベロシティーを確認します。

ラベル

ラベルについてはバックログアイテムについて種類を記載するのに利用します。

見積もり

フィボナッチ数列で見積もりをつけます。相対見積もりです。

Tips

また、スプリントプランニング後は、Reports機能を使って分析しています。

以上です。