ユニファ開発者ブログ

ユニファ株式会社システム開発部メンバーによるブログです。

サーバ / アプリ担当者が混在するチームにおける、ベロシティ計測・リファレンスストーリーの考え方

突然ですが、バーンダウンチャートを眺めていると、あれやこれやを考えて、「あぁ、あのときこうしておけば…」「おっしゃ!良い感じ良い感じ!」「次が楽しみだなぁ…」「こう来られたら、こんなアプローチで…」なんて思ったりしますよね。

…これ、まるで恋をしているようではありませんか?

そうなんです、私達はバーンダウンチャートに恋をしているのです。

本題

改めましてこんにちは、スクラムマスターの渡部です!

今回は、サーバ / アプリ担当者が混在するチームにおける、ベロシティ計測・リファレンスストーリーの考え方について説明していきます。

「サーバ / アプリ担当者が混在するチーム」と記載しましたが、要はそれぞれで専門領域があり、お互いの作業を代わることができない場合のことです。

考えれば納得なのですが、自分も迷いましたし、なかなか言及している記事も見つからないので、同じ悩みを抱える方のためにも残しておきます。

結論

はじめに結論ですが、同じチームと言えど、お互いの作業を代わることができないのであればリファレンスストーリーは別々で用意し、ベロシティ計測も異なるチームとして扱うべきです。

では何故そうすべきなのか?については、以降のセクションで、「ベロシティ計測」「リファレンスストーリー」の順に図を使いながら説明していきます。

前提

なお、以降の説明では下記の前提条件を使用していきます。

  • 人数
    • サーバ担当:3名
    • アプリ担当:2名
  • 合計見積もり
    • サーバ:250pt
    • アプリ:50pt
  • 1 sprintで一人あたり、 5pt を消化できる
    • サーバ:3名 × 5pt = 15pt
    • アプリ:2名 × 5pt = 10pt

ベロシティ計測

パターン①:同じチームなんだし、サーバ / アプリの見積もりをまとめて表示しちゃおうよ!案

一見、違和感は無いように見えますよね。

では、ここで図を見ていきましょう。

f:id:unifa_tech:20200523005036p:plain
サーバ / アプリ合算で3sprint経過

合計見積もりは 250pt(サーバ) + 50pt(アプリ) = 300pt となり、1sprintあたり25ptが消化されていきそうに見えます。

このまま経過を見守って見ましょう。

f:id:unifa_tech:20200523134950p:plain
サーバ / アプリ合算で5sprint経過

f:id:unifa_tech:20200523135017p:plain
サーバ / アプリ合算で8sprint経過

5sprint経過時点とそれ以降だと、着地地点がかなり後ろにずれてしまいました。

お気づきの方もいると思いますが、5sprint経過した時点でアプリ側の作業(50pt)が全て完了してしまったため、このチームが1sprintで完了できる作業が15ptに変わってしまったんですね。

f:id:unifa_tech:20200523135456p:plain
サーバ / アプリ合算で8sprint経過(説明)

今回は説明のために比較しやすい前提条件としているため、実際はここまでわかりやすくずれないと思いますが、(できる限り)妥当な予測をするためにも、「途中で一部の人の作業が完了したのでチームのベロシティが変わり、予測も変わる」ということは避けたいですよね。

パターン②:担当する作業ごとに分けて表示しようよ!案

次は、分けた場合にどうなるかを見ていきましょう。

私の場合はGoogle スプレッドシートを使っているのですが、こんな感じで1つの図に並べて表示しています。

f:id:unifa_tech:20200523141455p:plain
サーバ / アプリ分割で3sprint経過

f:id:unifa_tech:20200523141545p:plain
サーバ / アプリ分割で8sprint経過

これであれば、パターン①の問題は排除できるので、純粋にチームのベロシティを視覚的に見ることができるようになります。

以上で、ベロシティ計測については異なるチームとして扱うのが良いということがわかりますね。

リファレンスストーリー

リファレンスストーリーを、同一チームならサーバ / アプリを統一した方が良いのでは?と思う理由としては「担当する作業は違ったとしても、チーム内で1ptの重みが異なるとマズそうでは?」というのがあると思いますので、今回はそこに絞って見ていきます。

基本的にはこれまで見てきた例を使いますが、今回は仮に、アプリ側が5倍大きいストーリーポイントを見積もったと仮定しましょう。

すると、アプリの合計見積もり = 250pt となります。

…おっと、ちょっと心配な数字になってきましたね。

では図で見ていきましょう。

f:id:unifa_tech:20200523142728p:plain
アプリ側が5倍大きい数字を見積もった場合で8sprint経過

図の緑の縦棒は、これまでと比較して大きく伸びているのですが、これまでの例と同じ時期に着地しているのがわかると思います。何故でしょうか?

そうです、見積もりが5倍に膨らんだのと同様、アプリ担当者が1週間で消化できる作業につけられた見積もりも5倍になったので、結果、5倍の速度で数字が減っていくことになるのです。

つまり、担当する作業が異なるのであれば、1ptの重みは違っていて問題無いと言えます。

まとめ

以上のことから、同じチームと言えど、お互いの作業を代わることができない状況であれば、「リファレンスストーリーは別々で用意」し、「ベロシティ計測も異なるチームとして扱う」のが良いと言えます。

※ リファレンスストーリーについては、メンバーがイメージしやすく、メンテナンス性が担保されているのであれば、統一しちゃっても問題ないと思われますが、基本的には別々が良さそうですね。

さいごに

以上で今回の説明を終わりにさせていただきます。

次回は、「複数チームでリファレンスストーリーを統一した方が良い?」についてお話しようかと思っています。

また、スプレッドシートで作ったバーンダウンチャートをブログで解説したら需要あるのでは?という意見も社内から出たので、どこかで取り上げようかとも思います。

f:id:unifa_tech:20200523145038p:plain
バーンダウンチャートを表示している表

それではまた次回、Have a good sprint!