Back when I was a programmer in traditional command and control companies I would estimate large vague tasks in days or weeks. We avoided listing granular tasks because it's no fun having micromanagers hold us to detailed plans that invariably turn out to be wrong once the work is started. Microaccountability would impede the creative process.

In good Agile teams, the Sprint Tasks are constantly, freely, and blamelessly revised by the team. There's also more collaboration. Your old CYA habit of hiding behind large vague tasks is unnecessary when your boss isn't breathing down your neck. Breaking tasks into smaller chunks becomes a useful way of communicating what you're doing with your self-managed team and a more honest way of re-estimating progress for the Sprint Burndown Chart.

(Note that Product Backlog Items are distinct from the Sprint Tasks I'm talking about here.)

If you see a pattern of tasks more than about a day long, investigate whether there are trust issues making team members uncomfortable revealing to each other what they are actually doing.

Also note that *placeholder tasks* of many hours are useful for items toward the end of the Sprint that haven't been started yet. When you start them, break them into more granular tasks, always subject to change.