Hours vs User story points
I watched one of the one thousand videos of agile software development. The person who made it, says that the use of hours is better when planifying because it lets you know exactly when a task is going to be finished and therefore, when we can deliver some package of functionality.
I understand the things other way around. When I worked as a developer, you could feel what I call “the hours pressure”. We were estimating our own tasks hours and try to do them within the time. Later on the project manager used the hours to work on his own estimations. Looks nice. Looks fair. Looks flexible. The problem is that the hours pressure come out. Me and my team mates were worried in some sense when we made a mistake in terms of hours. There were always mistakes, of course, and nobody really used the exact hours. That is what made me think, hours are useless. I could say to you, Big task, small task, medium task, enourmous task, but hours?. Better the approach of tasks points or story points or whatever.
Developers have their own proud and people who like to do the things right, try to do it as much as they can when neccessary. It was those kind of non-written rules that even if you are told not to worry, at the end you worry. It’s normal. You cannot avoid it. You don’t like to slow down the team either.
With flexible measures at the end you may make less mistakes, people feel they have some margin, they don’t feel so much pressure and it is easier to assign values. Example, XL t-shirt size for this User Story. It could be 20 hours or maybe 30 hours but usually will oscilate because we always we have in mind a similar amount of WORK per evaluation.
You could say, how do you know when something is going to finish? Well, how do you know with User Story points in Scrum?