Retty Tech Blog

実名口コミグルメサービスRettyのエンジニアによるTech Blogです。プロダクト開発にまつわるナレッジをアウトプットして、世の中がHappyになっていくようなコンテンツを発信します。

ストーリーポイント定規を作ってみた

この記事はRetty Advent Calendar Part1の13日目の記事です。

※ Part2はこちら

toB(飲食店)向けプロダクトの開発をしているエンジニアの今井です。 運動不足で代謝が落ちたせいか、例年よりも足元の冷えに辛さを感じる日々を送っています。

今年も終わろうとしていますが、去年に引き続いて個人としてもチームとしても、様々な気づきが得られた年でした。 その一つとして、ストーリーポイント定規を作った話を紹介します!

ストーリーポイント定規とは

ストーリーポイント定規は、「アジャイルコーチの道具箱 – 見える化実例集」で紹介されているプラクティスです。

leanpub.com

プロダクトバックログアイテムの規模を見積もるときにストーリーポイントを使ったりすると思います。 ストーリーポイントは他のアイテムとの相対値になるので、チームごとに微妙に違ってきますよね。

このプラクティスは、「自分たちならこのアイテムに何ポイントつける?」という指標を、定規として見える化する、というものです。

なぜ作ろうと思ったのか

過去に見積もった内容と矛盾が生じ始めた

私が所属しているチーム、「ももてん」では、毎日のリファインメントの中でプロダクトバックログアイテムの見積もりを行なっています。 (ももてんの日々の活動についてはこちらで紹介しています!)

見積もりをする中で、

「これは3ポイントですかね」

「さっき見積もったアイテムが5ポイントだからそんなもんだね」

「あれ、でも2週間前に見積もったあのアイテムも3ポイントなのでそれと同じくらいってことになりますけど」

「・・・それはどうだろう?」

というような会話がたまに行われることがあり、明らかにストーリーポイントの基準がブレていました。

スプリント内でアイテムがDoneできなくなってきた

特に大きいポイント(5ポイント〜)がつけられるアイテムの完了率が悪くなっていました。 思っていたよりも規模が大きかったケースがほとんどだったと思います。

そんなことが続くとスプリント終了後に「これは5ではなかったね」という会話がされますが、明示的にチームの指標をアップデートしていなかったので、一度定義しよう!となりました。

定規作成の流れ

引用元では、毎スプリントの終わりに完了したプロダクトバックログアイテムを定規に追加していく方法として紹介されています。 私たちのチームでは現状そういった習慣がなかったので、過去のスプリントで対応した内容から振り返っていきました。

まずはプロダクトバックログから対応済みのアイテムを見返して、定規に載せるアイテムを見繕います。 着手前はどれくらいで見積もっていたのかがわかるように、こんな感じで置いてみました。

この時気をつけたのは、できるだけ今のチームと同じ状態で対応したアイテムだけ選ぶことです。 作った定規は今後チームがアイテムの規模を見積もる際に使いたいので、何かしらの要因で見積もり基準が違っていた可能性があるアイテムは対象外とします。

私のチームの場合はちょうどメンバー変更があったので、定規に載せるアイテムはメンバー変更後の期間から選んでいます。

定規に載せるアイテムが決まったら、次はそのアイテムについてみんなでふりかえりです。

まずは、対応した時のことを思い出しながらざっくりと配置してみます。 人によって意見が違うかもしれませんが、後から議論するのでここでは一旦自由においてもらいます。

あとは、置かれたアイテムについて一つずつ認識合わせをしていきます。

「このアイテムは時間かかった印象はあるけど、他のバグ対応と重なっただけで実はそんなに大きくないよね」

「これは見積もり時点ではわからなかった影響範囲の修正が結構重たくて、実際もっとかかってそう」

「この手の対応は全部1ポイントとして扱ってしまえばいいんじゃない?」

というように、会話しながらチームの指標をプロットしていきます。

最終的にはこんな形になりました。

作ってみて気づいたこと・変わったこと

ストーリーポイント定規を作ってみて一番強く感じている変化は、不確実性が高いアイテムに対して大きいポイントをつけられるようになったことです。

見積もり時点で見えている情報だけでポイントをつけていると、思わぬ形で対応内容が膨れてしまい、計画通りにスプリントを終えられなくなります。 実際には「見えている」と思っていてもその精度が怪しいことは多々あって、それでも見積もりを出すために「わかっている範囲のポイント」を出していたんじゃないかと思います。

「無意識に1スプリントに収まるポイントをつけたくなってるかも」という意見もありました。それもそうかも。 確かに、過去の見積もりで8ポイント以上がついたことはほとんどありませんでした。

定規作成後は、不確実性の高いアイテムに対しては大きめのポイントをつけるようになっています。 一見バッファっぽく見えてしまいますが、無闇に多めにつけるのではなく、「やってみないとわからない」分のポイントを上乗せているイメージです。

加えて、そういった理由で大きめのポイントがつけられたアイテムについては、PO含むメンバー間で「これだけ大きいポイントがついているってことは、進めながら計画見直していかないとね」と会話ができるようになりました。

あらかじめ「計画の見直し」を計画しておけるので、不足の事態があったときの方向修正がスムーズになったと思います。

また、定規を作ったことにより、当初の課題感であった見積もりのズレも減ってきていると感じています!

以前はプロダクトバックログを見返して「あの時はこういう見積もりだった」という情報を参考にしていましたが、それだと「アイテム着手前の見積もり値」をインプットにしていることになります。 実績値ではない値を基準にした見積もりでズレが生じて、また次の見積もりではズレた見積もりを参照して・・・と負の連鎖によりチームの指標が壊れていました。 定規を作成してからは実績値を元にした指標を基準にしているので、大きなズレは発生しにくくなっています。

以上、チームがストーリーポイント定規を作ったお話でした!

作った定規は、チームの変化に合わせてアップデートしていかないとまた見積もりにズレを発生させてしまいます。 私のチームでもその後定規の見直しを行いましたが、やはり最初に作った定規とは少し違う指標になっていて、チームが日々変化していることを実感したりしました!

また、見積もり時に議論が発散しそうになった時には「一回定規見てみます?」と一呼吸おいて確認ができるようになり、チーム内の共通言語としてもとても役に立っています。

プロダクトバックログアイテムの見積もりで困ったら、日々の開発をふりかえってチームの共通言語を作ってみると、改善が見えてくるかもしれません!