<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Scrum on Logical Dice 技術ブログ</title>
		<link>https://www.logical-dice.com/tags/scrum/</link>
		<description>Recent content in Scrum on Logical Dice 技術ブログ</description>
		<generator>Hugo</generator>
		<language>ja</language>
		
		
		
		
			<lastBuildDate>Thu, 25 Jul 2024 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://www.logical-dice.com/tags/scrum/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>スクラムのストーリーポイントの「時間で見積もらない」とは</title>
				<link>https://www.logical-dice.com/posts/2024/07/25/story-point-knowledge/</link>
				<pubDate>Thu, 25 Jul 2024 00:00:00 +0000</pubDate>
				<guid>https://www.logical-dice.com/posts/2024/07/25/story-point-knowledge/</guid>
				<description>&lt;h2 id=&#34;背景&#34;&gt;背景&lt;/h2&gt;&#xA;&lt;p&gt;普段スクラム開発でスクラムマスターとして業務しています。&lt;/p&gt;&#xA;&lt;p&gt;開発者の方々にはストーリーポイントで見積もりをしてもらっています。&lt;br&gt;&#xA;ストーリーポイントは「工数」で見積もってはならず、代わりに「難易度」や「労力」で見積もります。&lt;/p&gt;&#xA;&lt;p&gt;ただ、この表現がフワッとしていてメンバーが困っていました。&lt;br&gt;&#xA;メンバーにより解釈に違いがあるし、そもそも工数で見積もらないけどストーリーポイントを元にスプリントで実施できるチケットを判断したりしているし、&lt;br&gt;&#xA;結局皆どうしても各チケットの相対的な工数を考えてしまっており、すごい悶々としていました。&lt;/p&gt;&#xA;&lt;p&gt;そんな時にスクラムコーチの方々のスクラム研修を受ける機会があり、いい機会なので見積もりの考え方について色々ぶつけてみました。&lt;br&gt;&#xA;結果として自分の中ではすごいシックリくる解釈ができたので残しておきます。&lt;/p&gt;&#xA;&lt;h2 id=&#34;見積もりの考え方&#34;&gt;見積もりの考え方&lt;/h2&gt;&#xA;&lt;p&gt;結果から言ってしまうと「各チケットの相対的な工数」を考えるのは間違いでは無さそうです。&lt;br&gt;&#xA;ただし、前提条件があるので、そこを履き違えてしまうと正しい見積もりができません。&lt;/p&gt;&#xA;&lt;h3 id=&#34;前提条件自分がやった場合ではない&#34;&gt;前提条件①：自分がやった場合。ではない&lt;/h3&gt;&#xA;&lt;img src=&#34;https://www.logical-dice.com/images/2024/story-point-knowledge-001.png&#34; style=&#34;width:300px;&#34;/&gt;  &#xA;&lt;p&gt;見積もりをしていてポイントの根拠を聞いた時によく聞くセリフで以下のようなものがあります。&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;この対応はCSSでの調整が必要ですが、自分はスタイル調整が苦手なので高めに付けました。&lt;/li&gt;&#xA;&lt;li&gt;この機能は自分は関わった事がないので、影響箇所の調査から入るので高めに付けました。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;上記の考え方はダメです。&lt;br&gt;&#xA;客観的にみて「どんな作業があるか」「それぞれの作業は一般的にどの程度重いか」を考えてポイントを入れる必要があります。&lt;br&gt;&#xA;チーム内で「もし普段この業務を担当している並レベルの人がやった場合」などの基準を設けましょう。&lt;br&gt;&#xA;また、もしタスクに対して必要な作業が分からなければ、ポイントを入れる前に有識者から作業内容をざっくり聞いておきましょう。&lt;/p&gt;&#xA;&lt;p&gt;それを行なった上でも「作業の重さ」というのはズレが生じるので、そこだけ最後に擦り合わせできれば良いと思います。&lt;br&gt;&#xA;他の人とズレてたなと思った場合は擦り合わせた結果を次の見積もりから活かせば良いです。&lt;/p&gt;&#xA;&lt;h3 id=&#34;前提条件工数は具体的な数値じゃなくてどっちの方が時間かかりそうかで考える&#34;&gt;前提条件②：工数は具体的な数値じゃなくて、どっちの方が時間かかりそうかで考える&lt;/h3&gt;&#xA;&lt;img src=&#34;https://www.logical-dice.com/images/2024/story-point-knowledge-002.png&#34; style=&#34;width:300px;&#34;/&gt;  &#xA;&lt;p&gt;相対的に工数でポイントをつけるとは言ったものの、この作業にどのくらいの時間がかかりそうかを考える時に、具体的に「3日かかりそうだから3P相当」みたいな考え方はやってはいけません。&lt;/p&gt;&#xA;&lt;p&gt;なぜかというと人は成長していくものなので今は3日かかる作業も1年後は1日でできるようになっているかもしれません。&lt;br&gt;&#xA;もし具体的な数値で見積もっていると全く同じ作業をでも現在と1年後でポイントが3倍も変わってしまい、同じ作業なのにポイントが違うという矛盾が生じてしまいます。&lt;/p&gt;&#xA;&lt;p&gt;具体的な数値ではなく相対的な感覚でいけば1年後もポイントが大きくズレることはないと思います。&lt;/p&gt;&#xA;&lt;h3 id=&#34;前提条件よく分からなければポイントを入れない&#34;&gt;前提条件③：よく分からなければポイントを入れない&lt;/h3&gt;&#xA;&lt;img src=&#34;https://www.logical-dice.com/images/2024/story-point-knowledge-003.png&#34; style=&#34;width:300px;&#34;/&gt;  &#xA;&lt;p&gt;これは前提条件というか、見積もる際の注意点かもしれません。&lt;/p&gt;&#xA;&lt;p&gt;前提条件①でも少し触れましたが、見積もりタスクに対して「この機能は自分は関わった事がない」という事は普通にありえると思います。&lt;br&gt;&#xA;ポイント見積もり前にどんな作業があるのかなどは話し合いますが、それでも全然想像を付かなけば見積もりに参加しない勇気も必要です。&lt;br&gt;&#xA;WEBのプランニングポーカーツールでも「？」があると思いますが、それです。&lt;/p&gt;&#xA;&lt;p&gt;作業量が分からないのに無理にポイントをいれてもノイズにしかならないので、空気読んで他の人と合いそうなポイントを入れるって言うのは止めましょう。&lt;br&gt;&#xA;ただし、該当機能は今後見積もりをしなくていいやと諦めるのではなく、どんなポイントが付いたのかを見ながら次からは参加できるようにする努力はしましょう。&lt;/p&gt;&#xA;&lt;h2 id=&#34;あとがき&#34;&gt;あとがき&lt;/h2&gt;&#xA;&lt;p&gt;いろいろと前提条件をつけましたが、これを一言で伝えるのは難しいと思いました。&lt;br&gt;&#xA;その結果出てきた表現が「難易度」とか「労力」なのかなと思います。&lt;/p&gt;&#xA;&lt;p&gt;また、見積もりはあくまで作業の目安をつけているだけで顧客に価値は提供していません。&lt;br&gt;&#xA;より良い見積もりをするために工数をかけすぎて、結果として顧客に提供できる価値にかける工数が減ってしまっては本末転倒です。&lt;br&gt;&#xA;チームによって最適な運用というのは違うと思うので、各チームで現実的な見積もり方法というのを見つけていきましょう。&lt;br&gt;&#xA;その辺りを推進していくのもスクラムマスターの仕事かと思います。&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
