Would be nice to be able to log time on a story card.

two aspects with regard to the time management:

1) Simply the ability to log/track time spent on the story for billing purpose and also for my management metrics;

2) Then, comes the planning aspect where the story can be broken down to the "task" level where engineers/scrum master will be able to tie to a time duration.

To me, the first one is more or less a must for project mgmt purpose and the second one, well, it's nice to have, in my opinion.

BTW, we are planning to write a Java app by integrating through your web services API to report the time. Did someone develop similar solution before and you can share?

- Rene ( Delete or Edit)

Tracking time per task (in a per-story task list) would be valuable for helping teams improve. Agile estimation is decidedly two-tiered, and should probably stay that way.

Top tier - rough estimate of story "size" in points. Done quickly, ideally by consensus with fibbonaci (planning poker). These rough numbers aggregate to give per-sprint velocity data. Remember, they aren't _hours_ they are points. Since you can't track time spent in "points", you can't really reconcile these estimates. But that's ok, you don't need to.

Second tier - a story is decomposed into a set of execution tasks (update the UI, migrate the db, expose API, etc). These tasks are estimated in hours. The implementation team can record the time spent versus the time estimated. This allows them (with good reporting) to get better at estimating the time to do new tasks. That helps the team.

You could roll up the hours*tasks per story data and see how estimated (and actual) hours per story point play out - but that's really only useful for someone required to track "time spent" - it doesn't help with release-planning or execution, unless the data at the task level (which takes much longer to create) is a much better predictor of velocity (at the sprint level), than the story-estimates are. The detailed data, when rolled up, will only be a better predictor if the story estimates are (1) consistently wrong, and (2) erratically wrong - inconsistently high or low, and (3) there is not enough data in #2 that it will average out and look like #1 over time. When there isn't enough data, then the detailed-level data isn't going to really help much either.

At the end of the day - this feature (if implemented) only makes sense for task estimates, and then only for (1) project managers who have to track hours spent per "something" and (2) developers/testers who want to get better at estimating tasks. ( Delete or Edit)

I think this would be quite toxic for Tracker. The whole promise of agile turns on estimations over time, which can then be evaluated in terms of trends in over- or under-delivering planned iterations. Tracking individual stories by time would allow PMs to specifically not engage in the agile process, and use Tracker like any other brain-dead software management tool. ( Delete or Edit)