User Story & Task, Story Point & Hours
User Story & Task, Story Point & Hours

User Story & Task, Story Point & Hours

An recent discussion on scrumdevelopment group, it started from asking whether should split stories into tasks, and moved to whether it is a good idea to estimate product backlog items in hours, one of Mike’s reply is good, extract here :

Indeed. I often make this point by thinking about working at a car wash and having a quota of washing 4 cars per hour. That is perhaps a reasonable quota when measured over an 8 hour day or certainly over a 160 hour week. It would be inappropriate though for me to get fired from the car wash after any ONE hour in which I only washed 3 cars.  Velocity (whether calculated in story points or ideal days) is a useful long term measure ("you must wash 400 cars in 100 hours") but not useful in the short term ("You must wash 4 cars between 10-11 tomorrow")

Mike Cohn

Mike lists two blogs, there are some valid points too :

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.

Suppose a basketball team is in the middle of their season. They’ve scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say “We will probably average 98 points per game the rest of the season.” But they should not say before any one game, “Our average is 98 therefore we will score 98 tonight.”