アジャイル開発に最適！ Pivotal Trackerの使い方を丁寧に解説

mofmofではスクラムをベースとしたアジャイル開発を行っていますが、プロジェクト管理のためにPivotal Trackerと呼ばれるツールを使っています。

この記事ではPivotal Trackerの使い方をスクラムのイベントにごとに説明していきます。
スクラムのためのツールを探している方、Pivotal Trackerに興味をもっており実際の使い方を知りたい方におすすめの内容となっております。

また、mofmofに開発の依頼を考えていらっしゃる方には、mofmofのプロジェクトの進め方を知ってもらうために役に立つかもしれません。

Pivotal Trackerとは？

Pivotal Trackerはスクラム開発(アジャイル開発)に特化したプロジェクト管理ツールで、POを含めたプロジェクトメンバー全員で活用するのが大きな特徴です。

Pivotal Trackerの紹介やメリットなどはこちらのページで解説しております。
【おすすめツール】アジャイル開発にはPivotal Trackerがお勧め！その理由や実用例をご紹介

この記事ではPivotal Trackerの使い方にフォーカスを当てたいと思います。

スクラムイベントのおさらい

Pivotal Trackerの使い方を説明するまえに、Pivotal Trackerを導入する対象であるスクラムのイベントをおさらいします。
（mofmofではスクラムをベースとしつつmofmofらしくアレンジしたモジャイルという開発手法を採用しております。そのためのこの記事で説明している内容は厳密にはスクラムと異なる箇所があることをご了承ください）

スクラムでは次のようなイベントがあります

スプリントプランニング
- そのスプリントで実行する作業計画を立てる
デイリースクラム
- エンジニアどうしで作業の進捗を確認する
スプリントレビュー
- POがスプリントの成果を検査し受け入れ or リジェクトする
スプリントレトロスペクティブ
- スプリントを振り返りプロジェクトの品質を高める
- ※ここではPivotal Trackerを活用しません。

スクラムについてもっと知りたい方はこちらの記事をご覧ください。
非エンジニアでも3分でわかる開発用語④ スクラム

また、mofmofではMVP開発に携わることが多く、そのためにスプリントを始める前の準備として

ユーザーストーリー出し
- 開発したい内容をユーザーストーリーという単位で書き出す
ストーリーの詳細化とざっくり見積もり
- スコープ決めのために、まず大まかに作業量の見積もりをする
スコープ決め
- 見積もった作業量と期限をもとに、リリースまでに開発するストーリーを仮決めするというイベントを行っています。

この記事ではこれらのイベントごとにPivotal Trackerをどう使うのか説明していきます。
なお、デイリースクラムはmofmofでは実施していないため以後の説明では登場しません。
同様にスプリントレトロスペクティブもPivotal Trackerを活用しないため、以後の説明では登場しません。

Pivotal Trackerの準備

何はともあれまずはPivotal Trackerのプロジェクトを作りましょう。
以下のリンクからPivotal Trackerのページにいき、Sign upしてください。

https://www.pivotaltracker.com/

Sign upできたらダッシュボード画面が開くと思いますので、右上のCreate projectから新しいプロジェクトを作成します。

PivotalTracker1

ユーザーストーリー出し

プロジェクトが作れたら、ユーザーストーリーを追加していきましょう。画面上部にあるAdd Storyをタップすると追加することができます。

この時にオススメなのが、まずはIceboxのほうに追加することです。
Backlogに置かれるストーリーは詳細化が済み、優先順位を持った状態であることが望ましいです。
そのためこの時点ではIceboxに追加し、詳細化が済み優先順位をつけられる状態になったらBacklogに移すという運用がオススメです。

PivotalTracker2

ストーリーの詳細化とざっくり見積もり

開発したいストーリーをIceboxに登録できたら、そこからストーリーの詳細化とざっくりの見積もりを行いましょう。
ここでの詳細化と見積もりは、スコープ決めのためのものとなるため、ざっくりとしたもので良いことが多いです。
開発できるくらいの詳細化は実際着手する直前のスプリントプランニングで行うことが多いです。

ちなみにmofmofではPivotal Trackerのポイントの設定をカスタムにすることが多いです。というのもデフォルト設定ではポイントに応じてバーが積み重なる形で表示されるのですが、これが結構見づらいためです。

カスタムで設定すると単純に数字が表示されるので見やすくなります。

PivotalTracker5

またデフォルトでは最大8ポイントまでしか設定できないのため「このストーリーは分割する必要があるけどとりあえず大きめなポイントをつけておきたい」というときに対応できません。

設定画面へは上部のメニューバーのMOREをクリックして移動できます。
その中のPoint ScaleをクリックしてCustomを選択し、使用したい数列をカンマ区切りで入力してください。おすすめは「0,1,2,3,5,8,13,20」です。

設定を変更したら下部のSaveをクリックするのを忘れないように気をつけてください。 PivotalTracker6

詳細化と見積もりを行ったら、ストーリーにポイントをつけていきましょう。
ストーリーをクリックすると展開されるので、そのなかのPOINTSからポイントを設定することができます。 PivotalTracker8

また詳細化で話した内容はDESCRIPTIONに書いておくのがおすすめです。
DESCRIPTIONはマークダウンが使えるのも良い点です。

mofmofでは見積もりの時にはプランニングポーカーを用いることが多いです。詳しくはこちらの記事をご覧ください。
みんなで見積もれ！アジャイルな見積もり手法「プランニングポーカー」のやり方

ポイントをつけたストーリーは隣のBacklogに移動させていきましょう。
この時点で仮で良いので優先度順に上から並べてみてください。 PivotalTracker7

なお、デフォルトの設定だとBacklogの上から自動でCurrent Iterationに移動されてしまうので、設定画面からPlan Current Iteraion Automaticallyのチェックを外してSaveしておきましょう。 PivotalTracker10

スコープ決め

開発したいストーリーのざっくり見積もりが終わり、優先順位をつけられたら、ファーストリリースのスコープ決めを行いましょう！
スコープとは、目指すリリース日にむけてどこまでを開発するかという線引きのことです。

Pivotal Trackerでスコープ決めを行うためには3つ設定する必要があるものがあります。
一つめはプロジェクト開始日です。
プロジェクトの開始日は設定画面のProject Start Dateから設定しましょう。
プロジェクト開始日とは実際にスプリントを始める日のことです。
PivotalTracker9

次にリリースストーリーと呼ばれる、リリースの目標になるストーリーを用意します。
他のストーリーと同じように、Add Storyからストーリーを追加し、STORY TYPEをFeatureからReleaseに変更します。
そして、そのリリースを行いたい日付をRELEASE DATEから設定しましょう。
ストーリーのタイトルは、これがなんのリリースなのかわかりやすいようなタイトルをつけてください。ここではプロジェクト初めてのリリースということで「ファーストリリース」と命名しました。リリースストーリーは複数設定が可能ですので、プロジェクトの状況に応じて「β版リリース」や「製品版リリース」、「月次リリース」のような名前をつけてみてください。
リリースストーリーより上にあるストーリーが、そのリリースまでに開発を予定しているストーリーという意味になります。 PivotalTracker10

最後に、初期ベロシティを設定します。
ベロシティとは1スプリントで消化できるストーリーポイントのことです。
初期ベロシティは設定画面のInitial Velocityから設定できます。
PivotalTracker11

スクラム開発では、スプリントを回した実績に基づいたベロシティをもとにプロジェクトの計画をたてることになりますが、プロジェクト開始時点では実績に基づくベロシティが存在しないので、仮のベロシティを入れることになります。
可能であれば他のプロジェクトでの実績などをもとに決めるのが望ましいですが、それができない場合は、担当するエンジニアの感覚に基づいて決めることになります。
そのため、ここで決めるスコープというのは決定事項ではなく、あくまで一つの目安となります。
実際にスプリントをする中で実績に基づいたベロシティが得られるので、それをもとにスコープの調整をしていくことが常に求められます。

プロジェクト開始日、リリースストーリー、初期ベロシティが設定できたらBacklogのリリースストーリーを見てみましょう。
プロジェクト開始日から、初期ベロシティで定めたとおりにストーリーを消化して行った時に、リリース日に間に合う計算であればリリースストーリーは青く表示されるはずです。
逆に間に合わない計算の場合には赤く表示されます。
PivotalTracker12 間に合うか間に合わないかはストーリーポイントの合計と初期ベロシティから、Pivotal Trackerが自動で計算してくれるため、あとはリリースストーリーが青くなるようにリリースから外してもよいストーリーをリリースストーリーの下に移動させていくだけです。
PivotalTracker13

くりかえしとなりますが、ここで決めたスコープは暫定的なものです。
実際にスプリントを回してベロシティが初期ベロシティから変化したときに、この時予定していたよりも多くスコープに含めることができるかもしれませんし、さらにスコープから外す必要が出てくるかもしれません。
もちろん見込んでいたよりもベロシティがでないとわかった際には機械的にスコープからストーリーを外していて行けばよいというものではなく、どうしたらスコープを削らずにやりきれるかを考えることになりますが、この話はPivotal Trackerの使い方の話をオーバーしてしまうので、ここでは割愛します。

スプリントプランニング

スコープ決めも終われば、いよいよスプリントを開始し、実際に手を動かして開発を行なっていきます。
各スプリントの開始時に、そのスプリントで行うストーリーを決めることをスプリントプランニングと呼びます。

その時点でのベロシティに収まるように、Backlogの優先度が高いストーリーをCurrent Iterationに移動させていきます。（StartをクリックすることでもCurernt Iterationに移動します。）
このタイミングでさらにストーリーの詳細化を行い、完了条件をDESCRIPTIONに書き込みます。
完了条件とは何が満たせたらそのストーリーは完了したと言えるかを羅列したものです。
ここでしっかりとプロダクトオーナーとエンジニアで完了条件を合意できていないと手戻りが発生するので注意が必要です。

ストーリーの詳細化の時点で最初に想定していたより作業量が大きくなりそうな場合は、ポイントの見積もりを変えてもOKです。あるいは別ストーリーとして新たに追加する場合もあります。
いずれにしても、当初見込んでいたよりポイントの総量が増えることになるため、その影響についてはプロダクトオーナーと確認、対応を相談する必要があります。

なお、初期状態ではCurrent IterationとBacklogはひとつにまとまってますが、Add Storyの横の3点リーダーをクリックしてsplit Current Iteration and Backlogをクリックすることで分割することも可能です。
見やすさの好みに応じて設定してみてください。
PivotalTracker3 PivotalTracker4

スプリント中

Pivotal TrackerのストーリーにはSTATEが存在します。
ストーリーを追加したタイミングではUnstartedになっているので、スプリント中にそのストーリーに着手したタイミングでStartをクリックします。
PivotalTracker14

そのストーリーの実装が完了し、プルリクエストがマージされたタイミングでFinishをクリックします。
ちなみに、そのストーリーを担当しているエンジニアはOWNERSに名前が入りますが、その名前をクリックすることで担当から外すことも可能です。
PivotalTracker15

プルリクエストがマージされ、POがレビューできるように検証環境などにデプロイされた時点でDeliverをクリックします。
CDが整っている場合は、マージ＝デプロイとなると思うので、その場合はFinishとDeliverはほぼ同時に押すことになります。

スプリントレビュー

スプリントレビューとは、そのスプリントでDeliverしたストーリーをプロダクトオーナーに確認してもらい、受け入れOKかリジェクトかを判断してもらうイベントです。
ちなみに、mofmofではスプリント期間ごとに定例MTGを設定し、前スプリントのレビューと次スプリントのプランニングを一緒に行っています。

スプリントレビューでは前スプリントのCurrent Iterationをプロダクトオーナーを含めてチームメンバーでみながら行います。
PivotalTracker18

Pivotal Trackerの画面を共有する場合は右下にあるDisplay設定をNormalからProjectorに変更すると、文字サイズが大きくなるのでおすすめです。
PivotalTracker17

検証環境でプロダクトオーナーに確認してもらったら、プロダクトオーナーにAcceptかRejectをしてもらいます。
この操作はプロダクトオーナーに行ってもらうことがおすすめです。プロダクトオーナー自身がAcceptを行うことで「ほんとにこれを本番環境に反映させてよいのか？」という視点で確認をしてもらうことができます。

リジェクトとなったストーリーは基本的に次のスプリントに持ち越しとなります。
ちなみに、Pivotal TrackerはAcceptとなったストーリーだけから自動で最新のベロシティを計算してくれます。
逆に言えばスプリントレビューのタイミングでAcceptやRejectをしっかりと行わないと正しいベロシティが計測できないので注意が必要です。

また、Pivotal Trackerのストーリーにはコメントをつけることができるので、このタイミングでリジェクトとなった場合などは、コメントにリジェクト理由などを書いておくと時系列順に経緯を追えるので後から見返したときに便利です。

随時やること

新しいストーリーはアイスボックスにいれる

プロジェクトを進めていくうちに、あたらしいストーリーを入れたくなる時がきます。その場合は一旦アイスボックスに入れるのがおすすめです。
そして、定期MTGの時にアイスボックスにいれたストーリーを詳細化し、みつもりを行い、優先順位をつけてバックログにいれると、バックログには常に優先度がついたストーリーだけに保つことができます。

リリースに間に合うか常に確認

プロジェクト進行中、初めに想定していたよりベロシティが低くなったり、ストーリーが追加されたりすることで、リリースが間に合わない想定になることがあります。
そんな時、Pivotal Trackerではリリースストーリーが赤くなるのですぐにわかります。
リリースストーリーが赤くなっていたら、間に合うように対応が必要です。
例えば以下のような対応が考えられます。

優先度の低いストーリーをスコープ外にする
より少ないポイントで実装できるストーリーがないか探す
ベロシティを下げている要因を見つけて排除する

なお、ベロシティはCurrent Iterationのタイトルの右にある数字をクリックして一時的に変更することが可能です。
PivotalTracker19

試しにベロシティを上げたり下げたりすることで、それによってリリースストーリーに間に合うのかどうかを確認することができます。
調子が悪いとどうなるのかや、ベロシティをいくつまで上げれば間に合うのかを直感的に確認することができます。
ここでベロシティを変更しても、Revertをクリックするか画面を読み込み直せば元に戻ります。変更はあくまで確認のための一時的なものですのでご安心ください。

その他の設定など

祝日やメンバーの休みを考慮する

祝日があるスプリントや、メンバーが有給を取得したりで、あるスプリントの稼働が通常より少なくなる時があります。それをそのままベロシティに形状してしまうと、実際よりも少なく計算されてしまい、正しいベロシティが得られなくなってしまいます。
そんなときは、各スプリントの100％と書いてある部分をクリックして、実際の稼働時間に合うように％を変更しましょう。
例えば1スプリント1週間で行っている時に、1日祝日がある週であれば稼働時間は5日から4日に減るため、80%と設定します。
そうするとベロシティを4日でこの分のストーリーポイントを消化したと計算してくれるようになります。

助っ人などが入り、一時的に人が増える時は逆に150％のように設定もできます。 PivotalTracker21

ベロシティの平均をとる期間を変更できる

設定画面のVelocity Strategyから今のベロシティを直近何スプリントの平均とするかを選べます。
多くのスプリントの平均とするほうがより信用できるベロシティとなりますが、メンバーの入れ替わりが多いなどの都合がある場合は少ないスプリントの平均としたほうが良い場合もあるかもしれません。
PivotalTracker20

ちょっとしたタスクはChoreストーリーとして登録する

例えば「ここの文言だけを修正したい」のような1ポイントにも満たない小さなタスクが発生することがあります。それらを1ポイントとして計上してしまうと、ベロシティが正しく計れなくなります。
そのような時にはSTORY TYPEをChoreにします。
Choreストーリーはポイントを設定しなくてよいので、そのストーリーのせいベロシティが影響を受けることを防ぐことができます。