Time Tracking, Estimation and Quoting Specification

Introduction

This page lists requirements regarding time tracking, estimation and quotation for projects which are managed through Trac. It is contributed to by the Trac-community. It was initiated through ticket #369.

While this is a requirements-only document, some plugins have already been developed implementing some of these. Please see time or estimation.

Requirements and Rationale

1. We wish to be able to note on a ticket the amount of time a developer spent on it. This should be a list rather than a single box with total hours, because many developers may work on this ticket many times before the ticket is complete. Currently we plan to add this to comments on a ticket. Possibly as a separate table that references comments.
2. A ticket should show a summary of the time spent per developer and in total.
3. A ticket should have an estimated time field attached, probably just a custom field specified in trac.ini.
4. Tickets should also provide a rate or fixed cost bounty field so that there is a corresponding price for the estimated time.
5. We wish to be able to query per ticket / component / milestone / project (Trac instance) how much time has been spent per developer and in total. We should also be able to query this for different time periods: how much time this month did we spend on ticket 1, etc.
6. We should be able to query the amount over/under our estimation we were per per ticket / component / milestone / project (Trac instance).
7. A permissions set that is associated with viewing and adding/editing these fields.
8. Integrate into webadmin to allow setting permissions on all of the newly added fields. This will be the most user friendly way of editing permissions and shouldn't be too much work in total.

Specification

Time Tracking

To track how much time each developer is spending on a ticket, there should be some easy, query-able way to add time spent to a ticket. My first thought on this is to add two fields next to the comment that are time spent (in hours) and whether or not this is billable time (a checkbox). Then the developer (name) associated with that comment is also associated with the time. When a comment is added it should also add that time to the time log and update the total time spent for this ticket (which should probably be displayed in ticket properties as three fields: billable, non-billable, total) or a new time management section. When displaying comments, where it currently displays "date time changed by user" we should append a time spent.

If there is an error in a reported time, the plugin should allow the user to enter a second comment with a negative time. This will allow us to have a record of both the positive allotment of time as well as the redaction of that time.

Time Estimation and Price Quoting Facilities

We wish to be able to offer bounties / quote prices on a ticket. In addition to this ​time estimation has proven to be a difficult problem for software developers. The most commonly expressed way of becoming good at it, is to systematically record your estimations, compare that with actual output and adjust your estimations accordingly. To this end, every ticket should have an estimated time on it. The price / bounty should be expressible in either amount per hour or total cost.

Querying Time Information

There needs to be a way to query all of the time data that we will be adding to the database. We want this to be by time of entry, by developer, and billable/not billable. We also want the capability to compare the total amount of hours spent to total estimated.

Permissions

There should be a permission structure in place to (dis)allow viewing and editing of the various bits of data we are adding:

1. TIME_VIEW
2. TIME_EDIT
3. TIME_QUERY (this could possibly be tied in with TIME_VIEW though it might be nice to have it separated as well)
4. ESTIMATE_VIEW
5. ESTIMATE_EDIT

I would like this to mirror the Trac built in permissions structure as much as possible.

Possible Features (a place to hold feature creep)

1. It would also be nice to be able to have graphs of some of the various data bits. This could be provided through an svg/javascript graphing package.