Ask HN: Points or hours for time tracking and estimation?

At work we use story points (Fibonacci series) to estimate tasks. At first, when we were deciding between time and story points, I wasn't totally on board with the idea of story points because the size of a point seemed completely ambiguous--you could even define 1 point to be an hour or day making them equivalent. Some argued a benefit was that our estimates couldn't be used against us if a task took longer than estimated. However, since a team velocity is tracked it seemed that the story points could still be converted to a time estimate. In the end though I have come to appreciate using story points, specifically Fibonacci points, for three main reasons: 1) Time estimates never seemed to be accurate; 2) In my experience it's easier to gauge relative complexity; 3) Using Fibonacci numbers inherently models the "fact" that larger tasks are harder to estimate.

We use JIRA for tracking.

I must say though in the end estimating things still always seems like a waste of time to some extent. I think it's more important to just have a prioritized backlog. I'm also always reminded of the following excerpt from the book Peopleware: https://news.ycombinator.com/item?id=14371140.

The case for points over time estimates as I understand it, is that humans are not necessarily good at estimating in terms of time. We are good at estimating complexity in reference to other similar things. You can estimate that a new task is more/less/the same complexity as a similar task performed in the past more accurately than how long it will take.

After a while of doing this (as a group, not individually), you can get a velocity that starts to give you a good historical estimate of how long it takes to complete a given point, and use that to have realistic commitments for your work.

Note that one team cannot be compared to another because each group will estimate differently, with one group maybe estimating more conservatively, so their points and velocities will seem bigger and more productive than other groups. This is the reason why management should not use velocity as a performance indicator.

Since you need a history of estimating to get the velocity to accurately plan, this system is unreliable if the team is constantly switching out teammates. At my company we switch up the teams pretty often, so pointing doesn't really work well for us in this case.

In Riter (https://riter.co/) we use "clean" and "dirty" hours for time tracking. You can read about them here: https://riter.co/docs/time-tracking#estimation-types.

If briefly, developers estimate tasks in clean hours (or minutes), that's approximate time they need to implement this particular job (without taking into account time required for solving technical problems, meetings, reading manuals and so on). As a rule, developers can estimate clean hours rather accurately. But not dirty hours – they are less predictable for most of us.

When working on tasks, developers specify clean and dirty hours spent on them. Based on different estimates, we can calculate the coefficients of performance and accuracy of all developers and more accurately estimate the deadlines in the future. We plan to use AI later to obtain more accurate deadlines on the basis of these coefficients and collected statistics.

As far as I remember, we have described why we don't support points estimation here: https://riter.co/blog/time-estimation-missteps.