「それはチームで相談して決めることだ」と言われると終わってしまいますが
おっしゃるとおりチーム内で合意さえとれていれば粒度は問題ではないと思いますが、とはいえ難しいですよね。
最適解では当然ないですが、私が取り組んだときは以下のようなアプローチを行いました。
1.すでに実装することが決定しているタスクの中から、やるべき内容が明確で程よい規模(複雑さ)のタスクを消化する。(End to End で出来るだけ独立した内容だとなお良い *ここは肌感で決めちゃう)
2.消化したタスクが、程よい複雑さだったかチームで振り返る。
3.2の結果、重くも無く軽くもなかったねと合意が取れれば良し
4.2を振り返って重すぎたor分割できた場合はタスクを分割して考える。
5.3と4の工程をもとにタスクに相対見積もりの基準値として3とする
6.今後は、基準値3とした基準のタスクの粒度までは細分化するようにする。
見たいな感じで最初のストーリーの粒度の目安を決めていました。
要はチームメンバーが「規模感がつかみ易いサイズ」を見つける作業を行って、以後はそれに粒度を
合わせていくようにしたって感じですね。
スプリントを進めていけば基準となるタスクの数は増えてきますし、精度も良くなっていくと思うので
最初のうちは恐れず手をつけてみるのが吉かなと思ってます。
「規模感がつかみ易いサイズ」っていうのもチームによってまちまちだとおもうので。
その後はスプリント計画の都度、チーム全体でプランニングポーカーしていくと合意形成しやすかったです。
より大きなEPCISもあります。
エピックの取り扱いは、プロダクトオーナーとの話し合いの中で「ユーザにこんなベネフィットを届けたい!」
みたいな本当におおまかな内容を表現するのに使っていました。
エピックはそれを実現・構成する複数のストーリーに分割されて、またプランニングポーカーで各ストーリーを見積もるみたいな進め方をしていました。
タスクはストーリーが複雑ではないけど実施内容が複数ある場合に、サブタスクとしてtodoリストみたいに使ってましたね。(これはメンバーによって使わない人、使う人、それぞれいました。)
どちらにせよ、チームとして管理する最小の粒度はストーリーまでって感じでした。
STORYの中にはTASKSもあるし、より大きなEPCISもあります。
大きな順から エピック > ストーリー > タスク(個人で使う)
みたいな考え方で運用をしてました。
また、プランニングポーカーで使う数値の最大値を8にしておいて、プランニングポーカーで8と見積もられたストーリーは分割可能なエピックとみなされて、3とかになるまでその場で分割するみたいな進め方をしていました。
あくまでも、これは私の所属するチームが落ち着いていった方法なので、最適解では全然ないと思いますが、何か参考になれば幸いです。
試行錯誤と合意形成を繰り返していって、チームの最適解がみつかるとよいですね!
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2016/08/30 01:42