よく話題にあがる内容ですが、タスクの粒度はどれくらいを目安にしていますか？
粗すぎるとマネジメント精度が低下しますし、細かすぎるとマネジメント負荷が高くなりますよね？1日で終るサイズがいいとか、4時間で終わるサイズがいいとか、聞きますが、皆様は、どれくらいの粒度にしていますか？？？
「いいね！」 2
1-2日が多いですね😄
「いいね！」 1
結構気にせず必要なタスクは登録する感じですね。大きかったら子課題をあとで登録する感じかも。
結局1-2日が多い気がする🙄
「いいね！」 1
自分も1-2日ですね
「いいね！」 1
粒度気にせず登録して、
大きすぎたら子チケット化したり、別チケットを追加したりしています。
物品購入など待ちが多いタスクだと2w～4wくらいになることもあります。
「いいね！」 2
細かいことは気にせず、とりあえず起票するようにしています。
粒度を考え出すと、面倒になってメンバーが避けるようになるので、とにもかくにも起票するようにしてもらいます。
タスクが進行する中で、複数人での作業が必要なケースや、キリの良さそうなタイミングをみつけたら分解（別チケットの起票）をします。
タスク一つ一つの粒度を揃えようとするのは、かなり負荷が高いと言いますか、あまり本質的でもない気がするので、そこはもうまったく意識しないようになりました。
「いいね！」 3
> とにもかくにも起票するようにしてもらいます。
起票することは大事ですね👍
「いいね！」 1
みなさん仰っているように、まず起票する、というのが大事かと思います。
粒度を決めてしまうと、チケットを起票するのに粒度が適切か？というタスクが発生し、チケットの起票に対してのハードルが高くなってしまうと思っています。
チケットの起票は管理者のみしか行わない、というルールがあれば粒度設定は必要かもしれませんが、誰でも起票できる場合は気軽さも大事かと思っています。
「いいね！」 4
時間や期間と別軸で、担当者が重複しない、状態がなるべく一致することも大切だと思います。
比較的小さな運用課題であれば、Gitのブランチ管理がしやすいように、親課題は全体的な概要、子課題は作業単位でディレクターにお願いすることもありました。
「いいね！」 1
1年ぶりくらいにヘルプセンターにヘルプセンターの狙いに沿った内容のエントリがされたような気がします。感動すら覚えます。
私は割とガントチャート的に使用しているので、
- 大きな粒度のタスク(案件)は親課題としてざっくり
** ただしその親課題の目的と完了条件はしっかり書く - 小さな粒度のタスクは小課題として1営業日〜5営業日の単位でぶら下げる
** 小課題の課題名は必ず動詞(〜する、とか)で書く
という運用にしています。
ただ、皆さんもおっしゃっていますが、まず気になったことはなんでも起票するのが一番かと。気軽に課題起票できるのがBacklogの強みですから。
ある程度量が溜まってきたところで、この課題はどこに紐付けようか、どのくらいで解決できそうな課題? みたいな、ある意味棚卸し的なMTGを週次で実施したりしています。
「いいね！」 2