ユーザーストーリー分割のメリット

みなさんこんにちは。@ryuzeeです。

New to agile - Learn how to split storiesより抜粋してご紹介します。

ユーザーストーリー分割のメリットのメリットは以下の10個です。

ストーリー分割によって、元のストーリー上のいくつかの仕事はやる必要がなくなるかもしれない（リーンの警告にあるような無駄をしなくなる）
ストーリーを小さくした方が扱いやすく、分かりやすい
ストーリーを分割すると、個々のリスクが明らかになる
ストーリー分割によって、変更への対応が容易になる。大きいストーリーが変更されると大きなショックを受けるが、小さなストーリーならショックも小さい
小さなストーリーの方が複数人で同時作業しやすい。ストーリーが大きくて専門知識が必要だと、一人の人にそのストーリーを任せる傾向にあるが、小さく分割されていれば、専門的知識がなくてもできるところがたくさんある
ストーリー分割によって、本当のストーリーのサイズが明らかになる。ストーリーポイントが13のストーリーを3つに分割してみたら、個々のストーリーポイントはそれぞれ8だったというようなことを良く見てきた。これは不確実ということではなく、自分たちの限界を超えるようなものは何でも「大きい」と判断してしまう傾向にあるからだ
ストーリー分割によって、新たな品質標準を使うことができるようになる。例として、あるレポートシステムは２種類の似たようなレポート機能を持っていて、1つは毎時動作し、もう1つは1年に1回しか動作しない。毎時のレポートは年次のレポートよりも高い品質が必要とされていた。あんまり良い例ではないかもしれないが、相対する概念については分かるだろう
ストーリーが正しく分割されるとテストしやすくなる。いくつかの部分はエンド・ツー・エンドでのテストが必要になるかもしれないが、その他の部分はモックオブジェクトを使ってテストできる
ストーリー分割はパフォーマンスの問題を切り離すことができる。元のストーリーの一部の機能がパフォーマンスに影響を与えるかもしれないというような場合に、パフォーマンステストの優先度を高くすることができる
もちろん、ストーリー分割することで、より消化しやすいチャンクにすることができ、イテレーションにぴったりはまるようになる

原文は以下の通りです。

It may be possible to split a story so some of the work on the original story doesn’t have to be done. Ding, ding! Huge productivity improvement! Lean principle alert ? eliminate waste! This reason is good in some many ways you can’t even begin to count them. Any time work can be eliminated without affecting the overall value of the product it is a good thing. Oh, and if after splitting the story we see we don’t need to do any of it, well that’s just AWESOME!
Stories can be split to expose more personas. Sometimes teams see a story as large because there are many different types of personas which must be taken into account. The story becomes easier to deal with, and we gain clarity, when we see the personas split out separately.
Stories can be split to help expose risk. We may have user stories which have elements of risk in them. If we can split the user story to isolate the risk we may be able to avoid the risk altogether.
It may be possible to split a story to ease a transition. When we upgrade existing functionality we often give users a bit of a shock. Sometimes we can split stories to give a smaller shock up front and postpone other work until a later release.
A split story may be able to have more people work on it at once (swarming). If a story is large and requires primarily one type of expertise we tend to let a single person do all of that type of work. However, a split story may enable others to chip in because some portions of the large chunk of work can be handled by people with less expertise.
Splitting a story may give us more visibility into its true size. I have seen many teams split a size 13 story into 3 pieces and end up with 3 stories each of size 8! In fact it isn’t even that uncommon. When we have an upper bound on our story size we tend to use that size for anything “big.” This leads to large under-estimating for truly large stories.
A story split may allow us to use a different quality standard for the new stories. A simple example in a reporting system may be two of the same type of report, but one is run hourly and one is run yearly. The hourly report may need higher quality than the one run yearly. This may be a bad example, but I think it gets the concept across.
When a story is split correctly it can help with testing. Some portions of the story may require full end-to-end testing, while other portions may be able to be tested in a mock environment.
A split story may isolate performance factors. One portion of the original story may affect performance while another does not. This may affect prioritization as well as performance testing time.
Of course, splitting stories may just make the original story be in more digestible chunks so they fit better into iterations.