User Story & Task, Story Point & Hours
Mike lists two blogs, there are some valid points too :
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.