A common source of confusion on agile teams occurs when the sprint ("iteration") backlog and the product backlog are both estimated in hours. To avoid this confusion I strongly recommend estimating these backlogs in different units. In sprint planning the team should always talk of tasks and hours. Sprint planning covers the horizon of typically two to four weeks out. In release planning the team can choose between "ideal days" and "story points."

Regardless of which they choose, they still do sprint planning in hours. I prefer story points for the product backlog items (typically "user stories" are on the product backlog for me). What this means is that I may have a user story ("As a vacation planner, I can see photos of hotels so that I can choose the right hotel for my vacation.") that is estimate in points--let's say 5 points. That hangs out on the product backlog (PB) until the product owner prioritizes it such that the team chooses to work on it in a sprint. Once selected it is broken down into tasks and hours:

• code the user interface, 6 hours
• code new stored procedure, 4 hours
• add photo maintenance page, 8 hours
• write automated tests, 5 hours

and so on.

So both are used but at different times and when viewing items at different horizons. Here's a key reason I prefer points: If I estimate the PB items in ideal days then it is too easy to mistakenly think that the PBIs and the items on the sprint backlog are estimated in the same unit. After all, the sprint backlog is estimated in ideal hours and the PB is estimated in ideal days. So, they're the same unit (times 8 for the PB), right? This is a huge fallacy. On average the teams I've coached spend 30 minutes breaking a product backlog item into tasks and estimating those tasks.

So, let's not call that estimate "hours". Let's call it "hours I thought a lot about." On the other hand, teams I coach spend 2-3 minutes on average estimating the PBIs. (These items don't need the detailed thought upfront; we just want a rough estimate so we can decide priorities and basic schedule.) So, let's call these "hours I pulled out of the air." When the PB and the SB are estimated in days and hours, it is too tempting to divide the number of days on the PB (times eight) by the number of hours finished per sprint and think that's an estimate of how long the rest of the project will take. However, that's bad math. It's literally dividing apples by oranges. It's "hours I pulled out of the air" divided by "hours I thought a lot about." The result will be meaningless. The problem goes away when teams go to two-level planning (release and sprint) and when they track velocity in story points.