■ご利用プラン
プレミアム
■Backlog利用目的
日常業務・タスク管理
■相談したいこと/解決したいこと
Backlogを使い始めてしばらく経ち、基本的な課題登録やコメントのやり取りには慣れてきました。
ただ「課題をどのくらいの粒度で作ればいいのか」というところで悩んでおります。
例えば、
(1)1つの大きなタスク（例：Webサイトの更新作業）をそのまま1課題にまとめてしまう
(2)あるいは「デザイン修正」「テキスト修正」「動作確認」と細かく課題を分ける
といった判断です。
課題を細かくすると進捗は分かりやすいけれど、課題の数が多くなって管理が大変になりそうです。逆にまとめすぎると進捗が見えにくかったり、誰が何を担当しているのか不明確になってしまう気もしております。
みなさんはどのような基準やルールで「課題を分割する／まとめる」を決めていますでしょうか？
実際のチームでの工夫や経験談を教えていただけますと幸いです。
■相談の背景・目的
適切な課題の粒度で設定し、自他共に負担なく使いやすい運用をしたいと考えているため。
私の場合明確な基準があるわけではありませんが、なるべく「担当者が1～2日、もしくは1回の作業で終えられる単位」で課題を作成するように意識しています。ハセガワさんの例だと (2) に近いですね。
これくらいの粒度だと、課題一覧の「状態」を見るだけで進捗の全体像が把握しやすくなって、マネジメントの観点でも確認の手間が減るのかなと思います。(例えば進捗をコメントに記録するスタイルだと、管理者が個々の課題を開いて確認する必要が生じます。)
もちろん更新する側にとっては少し手間が増えると思いますが、進捗をリアルタイムで共有できることは大きなメリットですし、管理側の手間が減った分だけチームに余裕が出ると思います。
なにより、課題の単位が大きすぎて何週間も「処理中」のままになってしまうと、担当者のモチベーションが心配になりますよね。
こちらご回答いただき誠にありがとうございます！
「1回の作業で終えられる単位」というのがすごく納得感があり、参考になりました。
確かにおっしゃる通り、例えば1課題で「デザイン修正・テキスト修正」の2工程を一人が行う場合、管理者は都度中身を確認しないと進行が分かりづらいという問題がありますよね…
また、課題単位が大きすぎるが故の“いつまでも処理中問題”もその通りだなと…仕事が進んでいる感覚やモチベーションが、タスク処理者も管理者も感じられなくなってしまうとBacklogを使っているのに本末転倒になるなあと感じました。
非常に参考になるご意見をありがとうございました！！
運用に活用させていただきます！
共有する
