Tasks And Time Tracking
Working as a team, and loving order and focus, we want to keep track of all our tasks.
There are a bunch of reasons for this:
- Since our time on projects is charged to the customers, we want (!) them to know on what we spent our time
- Having tracked tasks allow for project leaders, peers and customers to negotiate their priorities
- We don't want ambiguity when we communicate: tracking tasks we can refer them with piercing precision using IDs
- When a task is properly tracked and described, everybody in the team can work it out (trading off efficiency for efficacy maybe, but still)
At the same extent, we want to track the time we spend on task so that:
- We can report it to client
- We know if we are exceeding our budget or more basically how much we have spent
- We can have metrics related to tasks life-cycles, etc.
We don't want to measure velocity or speed of individuals. Everyone has her own pace.
Velocity rates are kept into consideration for the whole team, with the goal to continuously improve its effectiveness, remove obstacles, make them work less to produce more, etc.
We appreciate people setting personal goals on proficiency or productivity but to us it's not as a matter of sheer speed, so time is only one of the variables.
We track our tasks on Gitlab.
Tasks can be tracked directly by us, mostly when working on projects with a backlog of items to be developed; or can be tracked by the customer on boards representing maintenance or support activities.
Credentials are needed to log into our tracker and work on projects.
We track time on Toggl. Each member of SparkFabrik will be provided with a Toggl business account and will be able to track time on company projects and tasks.
There are rules to keep things consistent between the tools so that we can make something out of all these data.
Talking about our everyday work, we recognize three different type of activities:
- Approved tasks: this is what the customers usually call us for. These activities are described in a signed agreement of sort, have a budget, a deadline and deploy a deliverable (even intangile, like a training course or T&M consultancy).
- Warranty: this is what the customer wants done but does not expect to pay for. Fixing a bug or amending an issue which is due to us, for example.
- Support: this is the time spent to deliver the approved tasks_ or to help a customer getting what he need, not only in term of deliverables. These activities are often (not always) in charge to project or customer leads.
We track time differently for those activities.
As a general rule, all time entries must contain links to specific issue codes when available; in addition remember the description line always is a gift to your future self, since you may be required to explain the admininistration or the customer why you spent that time and on what.
|Issue ID and title||Good time entry description||Bad time entry description||Very bad time entry description|
||#123 - Verified steps to replicate the bug||#123 Problems with contact forms||Analysis|
||#345 - Login form styling||#345 - Development||Development|
||Call with John Doe about new feature; tracked issue #789||Call with John Doe||Phone call|
Forenote: Despite we try to group tiny activities to form a 3+ working days whole, it happens that we must deliver very small tasks to our customers, such as one-shot security upgrades or very small changes to a living product.
Such small, isolated activities, must be tracked under the Support rolling task (see below).
Each task approved by a customer/for a project is tracked on Toggl as a
Task (heh!), with the format
[Task ID] Task Name, where
Task ID is an internal reference code, in the format
DDII is an optional part composed by two-digits day (
DD) and a discriminant incremental), and
Task Name is a mnemonic description such as
New media gallery,
Q3 Maintenance etc.
Approved tasks have a time budget on Toggl and the tracked time is counted against that time budget. Should a customer extend the budget, the task will be updated/extended or a new task will be created, depending on what makes more sense in the context.
Project/Customer leads should take care of keeping things consistent in terms of issue tracking, using Gitlab's Milestones. Create a milestone with the same name as the related task (
[Agreement Code] Task Name) and add all issues partaining to this task in there.
Each customer project has a Warranty task in it. This is a "rolling" task, in that it has no time budget assigned. Administrtion will get a monthly chunk of the time entries for reporting. It is important to undestand that, should we discover that a warranty issue is not actually covered by warranty (it happens sometimes), we will move it where it belongs (Support or other tasks): to this extent, it is mandatory that each time entry refers to an issue on the tracker.
Most of the time, who stands in the front line is most likely to track time under this task. As the Warranty task, this is also a rolling activity and we can see it as a catchall for the many different tasks a project/customer lead must undergo from day to day.
It is very unlikely that you can refer an issue for such type of activities: having a phone call, reviewing the project status, replying mails etc have too much overhead in tracking. To make some distinction during reporting and lifecycle analysis, there is four tags to apply to time entries that falls under Support umbrella:
- Customer care: when you help a customer doing stuff or making sense out of something.
- Estimation: when you devote time to estimate new features, projects or improvements.
- Project Management: all activites partaining to helping the team and the customer getting approved tasks done (agile events, validation, grooming, etc)-
- Issue checking: when an issue is raised you may have to spend time making sure it is properly detailed or to verify it is actually relevant (think about bug tracking for example). Here is where you'll track such time.
Not all these entries will result in a cost for the customer, so don't worry about this: just track everything you do! You will be engaged in analysis by the administration during the reporting phases.
In addition, all time entries for those very small activities agreed with the customer by mail or without a purchase order, which we performe from time to time, such as security updates, small and sporadic changes, etc, must be tracked as
Support. When you track a
Support entry of that kind it is important that you refer to an issue and provide a sound description since no written contract or purchase order will help us track the request during reporting.
Support tags examples
Find below some examples on how to use those tags.
||The customer can be expected to be trained on this, or to keep notes, so you are actually supporting it.|
||The customer can't do this without our involvement. This activity helps providing the correct service.|
||All partecipants have to track individual entries; despite this involves estimations, the activity is necessary to keep things on track and is not triggered by the client that needs cost-related information for his decisional process. That's why it is tagged as
||We will check the issue, the provided information and verify it is a bug (our fault). If this is the case the whole time spent will be classified as warranty effort.|
||This may involve the whole team, in which case all will have to track under this task and tag.|
||All partecipants have to track individual entries; If the new project falls under an existing main project, use the
||There are customers that for contextual reasons won't use our tracker and will keep going the same old root. Our task is to keep things tidy and organized and this is management and ownership.|