
Ask HN: Points or hours for time tracking and estimation? - baens
I&#x27;ve been meaning to try and get better at estimating my work, but I figured I&#x27;d start tracking to figure out exactly how long I take on things to begin with. I&#x27;ve been on the fence of whether to track by time or hours so figured I&#x27;d reach out to the community to see what people feel as a good pick now? Whether it be on a team, individual, or what have you. How do you track progress? What do you like or dislike? And what kind of software (or nontechnical system) do you help manage the data?
======
blcArmadillo
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](https://news.ycombinator.com/item?id=14371140).

------
katelynsk
In Riter ([https://riter.co/](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](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](https://riter.co/blog/time-estimation-missteps).

------
jaredsmithse
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.

