Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ストーリーポイント.pdf
Search
Kento Matsumoto
February 06, 2020
Technology
0
88
ストーリーポイント.pdf
Kento Matsumoto
February 06, 2020
Tweet
Share
More Decks by Kento Matsumoto
See All by Kento Matsumoto
社内LT2020/01/23
stepanve
0
45
社内LT2019/11/21
stepanve
0
64
社内LT2019/11/7
stepanve
0
80
社内LT2019/10/24
stepanve
0
66
Other Decks in Technology
See All in Technology
次世代のメールプロトコルの斜め読み
hirachan
3
330
20251102 WordCamp Kansai 2025
chiilog
1
500
AIエージェントによる業務効率化への飽くなき挑戦-AWS上の実開発事例から学んだ効果、現実そしてギャップ-
nasuvitz
5
1.6k
初海外がre:Inventだった人間の感じたこと
tommy0124
1
180
2025/10/27 JJUGナイトセミナー WildFlyとQuarkusの 始め方
megascus
0
110
DMARCは導入したんだけど・・・現場のつぶやき 〜 BIMI?何それ美味しいの?
hirachan
1
140
最近読んで良かった本 / Yokohama North Meetup #10
mktakuya
0
380
CLIPでマルチモーダル画像検索 →とても良い
wm3
2
780
kotlin-lsp の開発開始に触発されて、Emacs で Kotlin 開発に挑戦した記録 / kotlin‑lsp as a Catalyst: My Journey to Kotlin Development in Emacs
nabeo
2
290
ざっくり学ぶ 『エンジニアリングリーダー 技術組織を育てるリーダーシップと セルフマネジメント』 / 50 minute Engineering Leader
iwashi86
9
4.3k
Data Engineering Guide 2025 #data_summit_findy by @Kazaneya_PR / 20251106
kazaneya
PRO
7
940
OpenCensusと歩んだ7年間
bgpat
0
330
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
9
650
Understanding Cognitive Biases in Performance Measurement
bluesmoon
31
2.7k
The Pragmatic Product Professional
lauravandoore
36
7k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Visualization
eitanlees
150
16k
Why You Should Never Use an ORM
jnunemaker
PRO
60
9.6k
Designing Experiences People Love
moore
142
24k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Building Adaptive Systems
keathley
44
2.8k
Agile that works and the tools we love
rasmusluckow
331
21k
Transcript
ストーリーポイント 社内勉強会
ストーリーポイントとは? ユーザーストーリーを見積もるために、チームで暗黙的に了解された単位 EX) - スクラポーカー(フィボナッチ数列: 1, 2, 3, 5, 8,
13, 21, 44...) - Tシャツのサイズ(XS, S, M, L, O...) - 犬の名前(ラブラドール, ポメラニアン, ニホンオオカミ...) - 太陽系の惑星(水星、金星、地球、火星、木星) 基準はストーリーにかかる時間?ストーリーの大きさ?
時間?大きさ? ユーザーストーリーの大きさを基準とした方が良い - 人月の神話(労力と時間)にもあるが、大きさと時間を混同しない方が良い - 大きさを基準として、時間を測る - スプリントで消化できる大きさを元にして、スケジュールを立てる(時間)(アジャイ ルの経験主義) -
時間は個人の差が大きくなる (どうしても消費する時間を計算したい場合、時間を基準にする場合もある。。 )
スプリントのストーリーポイントの決め方 最初にスケジュールを出さないことは了承してもらう必要がある プロジェクトが失敗した事例を見せまくる - まず2, 3回スプリントを実施する(だいたい落ち着いてくる) - 平均のスプリントを求める - 平均のスプリントを×(0.8~1.2)をした範囲をスプリントの基準とする
スクラム ポーカーで見積もる - 数字の大きさとユーザーストーリーの大きさは、チーム内で同意を取る (最初は合わなくても、チームが成熟すると徐々に合ってくる) - 大きすぎるユーザーストーリーは分割すべし (分割後のポイントが、分割前と一致しなくても大丈夫!) - ❓は、ストーリが分かってないの合図。話し合いましょう!
- ☕は、休憩したいの合図!
ストーリーポイントを使うことによって 強いチームを作る! チームで見積もり、機能を開発するプロセスが大事!! ユーザーストーリーをストーリーポイントで大きさを見積もる。 次に、ユーザーストーリーを機能に分解し、責任を持って実行する。 気をつけて - ユーザーストーリーは「◦◦が××できる」のように作成し、機能に含みを - すぐできるでしょ?みたいな頼み方は最悪。責任転嫁の最たる例
References - スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本 (Mitch Lacey (著), 安井 力 (翻
訳), 近藤 寛喜 (翻訳), 原田 騎郎 (翻訳)) - アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法 ~(Mike Cohn (著), マイク コー ン (著), 安井 力 (翻訳), 角谷 信太郎 (翻訳))