ブログ

ryuzeeによるブログ記事。不定期更新

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

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

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

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

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

原文は以下の通りです。

  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!
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Of course, splitting stories may just make the original story be in more digestible chunks so they fit better into iterations.

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック