ユーザ・ストーリーの見積もりテクニック
コンサルタントとして働くことの最大の喜びの一つはいろいろなアイディアを試してみてからことが上手くいくように自分が一番好きな方法を適用することができることです。この記事では私が効果的だと思うユーザ・ストーリーの（開発工数）見積もりテクニックの詳細について述べています。
InfoQ
InfoQ
トピック・タグ別の表示
User Storiesに関するすべてのコンテンツ
User Storiesに関する最新コンテンツ
User Storiesに関するNews
ユーザーストーリーの見積もりをやめるときなのか？
最新のアジャイルチームは、時間ベースの見積もりから、ストーリーポイントを使った相対的な見積もりに推移してきているが、我々はこれからも見積もりが必要なのだろうか？
ユーザーストーリーを分割する方法
アジャイル技法が十分に機能するようにユーザーストーリーを細分化することは、ほとんどの新しいアジャイルチームにとって困難である。アジャイルコミュニティのメンバーが、いくつかの記事を通してユーザーストーリーを効果的に分割する方法についてのガイダンスを提供している。
スクラムにユースケースは使えるか？
スクラムでは一般的に，要件はユーザストーリーで表される。ではユースケースの使用も認められるだろうか？ 認められるとすれば，どのような状況で用いるべきだろうか？
誰がこのユーザストーリーを欲しているのか？
誰の利益になるのか簡単には言えないユーザストーリーがある。誰がこのユーザストーリーを欲しているのか表現できないとき、標準的な「... として、.... が欲しい。それは ... のためだ」というユーザストーリーのテンプレートをどうやって埋めればよいのか？
ユーザストーリー完了後の再見積は精度向上に有効か？
Scrum Development メールリストの最近のスレッドで，Paul Battison 氏がひとつの質問を投げかけている。スプリントの終了後に完了したストーリーの再見積を行って，チームの速度 (Velocity) 評価に実際の成果を反映させることは適当だろうか，と問うものだ。
未完了、完了、スプリントの終わりに一貫して完了しているか？
スプリントの終わりでストーリーが一貫して「完了の定義」を満たさしているか？チームはプロダクトオーナーの手を縛っていないだろうか？
繰り返しタスクはアジャイルの臭い？
ストーリーを水平方向のタスクに分割することは「アジャイルの臭い」か？これはスクラム/アジャイル計画会議によく見られ、チームの顧客価値へのフォーカスを損なう悪習なのか？代わりに提案されているのはどんなことなのか？