成果物 #

スクラムガイドにおいてスクラムチームが作成するべき成果物は3つ規定されています。

• プロダクトバックログ
• スプリントバックログ
• インクリメント

それぞれについて見ていきましょう。

プロダクトバックログ #

プロダクトバックログとは実現したい機能や要求、要望、修正などプロダクトに必要なものを抽出して、順番に並べたリストですです。

具体例を見てみましょう。これは筆者がアサインされているプロジェクトの実際にプロダクトバックログです。

ヒント
ここで例としてあげたプロダクトバックログは、スプリントバックログを兼ねており、すでに作業粒度が十分細かいものになっています。

プロダクトバックログをどのいう単位で書くかというのはプロジェクトやチームによって判断が分かれるところなのですが、 ザックリ機能A、機能B・・・というふうに羅列してもいいですし、 筆者のプロジェクトのように数時間から1日以内で終わる作業単位に分割したものでもいいと思います。 大事なのはそれがプロジェクトを通して一貫性があることです。

このプロジェクトではプロダクトバックログを Pivotal Tracker で管理しています。 プロダクトバックログの管理サービスはPivotal Trackerでなくても、使い慣れたものをつかえば良いです。

さて、プロダクトバックでは図のように実現したいことを列挙し、それを実現したい順番に並べます。 これを管理し最新化するのがプロダクトオーナーの役割です。

プロダクトバックログに挙げられているものは仮説検証が終わったものだけです。 つまりエンドユーザに対してヒアリングが行い有用だと認められた機能がここに要件として載ることになります。

プロダクトデベロッパーはプロダクトバックログとして挙げられた要件について作業量の見積もりを定期的に行い、 あとは何も考えずにリストの上から順番に機能として実装、リリースしていくことになります。

スプリントバックログ #

スプリントバックログはプロダクトバックログのうち、1スプリントでやる内容を抽出して作業に分割したものです。 では1スプリントでチームがやれる作業量とはどの程度なのでしょうか？ まず作業量の見積もりについて考えてみましょう。

作業量の見積もり #

作業量見積もりは金額や時間、コード量と言った絶対値ではなく、作業量を相対的に表した値であるストーリーポイントが使われます。

例として適当に描いた二本の矢印を見てください。 「下の矢印の長さを求めてください」と言われると、けっこう大変です。 画面に定規を当てたりして長さを求めたりすることになると思います。

しかし「上の矢印と比較して下の矢印の長さを求めてください」と言われると、 誰もが「だいたい3倍ぐらい」と一瞬で見積もりを導き出せると思います！ 精緻な見積もりは導くのに時間がかかりますが、相対的な比較であれば一瞬でできてしまいます。このスピードが大事なのです！

上記の例は線の長さでしたが、作業の見積もりも同じです。 「この機能の実装はなんステップぐらい？」と聞かれると誰もがその場では答えられないでしょう。 しかし、「この機能と比較してこの機能はどのぐらい難しい？」と聞くと誰もが感覚的に見積もりを出すことができます。

アジャイル開発12の原則において、 『アジャイルでは 「ムダ=価値を生まない」を探して「やめる勇気」を持つこと がとても大事です。』という一節がありました。 つまり精緻な見積もりは役に立つかもしれないけどそれを出すのに、多大な時間がかかるならそれはムダだという判断です。 たとえ見積もりの精度がどんなに良くても見積もりは見積もりでしかなく、それはユーザ価値を生みません。

ウォーターフォール開発の感覚だと「そんな精度のない曖昧な方法でいいの？」と思われるかもしれません。 しかし、一つ一つのバックログの項目は数時間からどんなに長くても1日2日で終わる程度の作業量しかありません。 多少外れたところで大した影響はないのです。それよりも見積もりにかかる時間を減らして、そのぶんプロダクトを生産した方がよっぽど効果があるというわけです。

では基準となる作業量はどのように決めればいいのでしょうか？

これはチームによって異なりますが、数時間でおわる簡単な作業を基準となる1ポイントにするのが良いでしょう。 チーム内で基準となる作業量について合意できていて、それが開発を通して一貫していることが大事です。

スプリントの計画 #

各々の作業項目の作業量の見積もりはできました。では1スプリントでそのチームができる作業量はどこから抽出したら良いでしょうか？

答えはこれまでの作業実績値の平均から導き出します。

再びプロダクトバックログを見てみてください。画面上部に「12」という数値があります。 これはベロシティと呼ばれ決められた期間の中でそのチームが届けられる要求の量のことです。 直近数スプリントで完了したストーリーポイントの平均から導かれ、イテレーションごとに実績を反映して変動します。

ベロシティについてよくある誤解 その1
ベロシティは生産性なのかとよく言われますが、生産性のことではありません。 ベロシティは特定のチームのための、特定のコンテキストにおけるもので、決して標準化されたものではありません。 ベロシティでそのチームの生産性を図ることはできません。

ベロシティについてよくある誤解 その2
ベロシティを複数チーム間で比較することはできません。 上述の通りベロシティは特定のチームのための、特定のコンテキストにおけるものであるため、 複数チーム間で比較することやできません。そもそも見積もりの基準にしている作業量はチームによって異なるということを忘れないでください。 また同じチームであっても、メンバーの入れ替わりがあればコンテキストが変わるため、その前後で比較することはできません。

さて話をスプリント計画に戻しましょう。このチームのベロシティは12なので、一週間あたり12ポイント分のタスクをこなすことができます。 ちょうど8/9の8/15の週は夏季休暇とかぶっており、この週は稼働率が30%に設定されています。 そのため、12ポイントの30%である3ポイントから4ポイント分の作業が次回のスプリントでこのチームがやるべきタスクになるわけです。

8/16の週は稼働率が100%になるため、このままいけば12ポイント分の作業がスプリント計画として上がることになります。

インクリメント #

インクリメントはこれまでのスプリントでの成果と今スプリントで完成したプロダクトバックログの項目を合わせたものです。 多くの場合、動作しているソフトウェアとして提供され、スプリント終了時点で完成していて正常に動作していなければなりません。 そのため、プロダクトオーナーと開発チームが「完成」のさす内容については共通の基準を持っている必要があります。 これを 「完成の定義」 と呼びます。

完成の定義はチームによって様々です。コードレビューを通していることだったり、 ユニットテストとE2Eテストを全県通していることだったり、デプロイが完了していることだったり、 性能だったり、あるいは様々な条件の複合だったりします。

ここまでで、スクラムチームが何を作るかを説明しました。 では次にスクラムチームの開発の流れについて説明してみます。