You're right that there is a limit to the usefulness of breaking down sub-tasks. It's up to a team how granular they get. Here is why it is important: a) Risk

You're right that there is a limit to the usefulness of breaking down sub-tasks. It's up to a team how granular they get. Here is why it is important: a) Risk management - if you break a feature down into sub-tasks at any granularity, you are creating an agreement (or at least a conversation) among your peers that this is how something will be implemented, and digging in beforehand to uncover areas which might impede shipping the feature sooner. b) You're going to have to break down the feature at some point. Being able to think through this ahead of time can be challenging, but often times is the meat of the work you do. You have to get into the hang of it -- think top-down or bottom-up ways of approaching it. But what if you don't have enough information or understanding yet to do that? Agile is not great for these tasks where you need to take some time learning or experimenting. I would offer you a couple extra tools here: - A "spike" ticket -- Agile is all about deliverables and commitments, but sometimes that doesn't work. So create a spike ticket, and define what it is you want to investigate. If you deliver something, great! If not, no worries. The important part is that in the future you've done work that enabled you to learn how to estimate or break down that task in the future. - A time-boxed ticket -- similar to the spike, but you just make sure you don't spend more than an allotted time on a task.