I was recently asked whether it would be OK for a team to complete their iteration planning without going to the point of estimating tasks in hours. To answer this, let's consider what the purpose of iteration planning is. In my view, the purpose of the iteration planning is for the team to arrive at a commitment to some set of functionality that they feel reasonably confident they can complete in the coming iteration. The purpose is not to identify tasks.

The purpose is not to estimate the number of hours for each of those tasks. The purpose is to figure out how many and which product backlog items they can commit to delivering in the coming iteration. If a team can do this without discussing tasks and hours, so be it. If a team can walk into the iteration planning meeting and one team member announces, "Sssh, I've receiving divine inspiration......... We can do the first three items plus the sixth on the product backlog," I would call the meeting over and we'd have our commitment. I'd be impressed and I'd be skeptical, but we'd be done with the meeting.

Since I haven't seen a team do this yet, I strongly recommend that an iteration planning meeting involve identifying tasks, estimating the effort of each, and then using that information to arrive at a set of product backlog items the team can commit to. I think this is the best way for a team to arrive at that reasonable commitment that I believe is the purpose of this meeting. Is it the only way? No. I've also worked with teams who decide that they will split work up such that all tasks are "about half a day". They then can skip explicitly estimating the hours for each task because, in a way they've already done it. But, until I learn how to receive divine inspiration at the start of my iteration planning meetings, I'm sticking with identifying tasks as hours as a good way to figure out how much to commit to.