How to organize tasks and hours without mixing up the Kanban and the reports

Finance wants to know how many hours were spent on development. The person managing the project wants to know whether the payments integration is ready. The person who did the work needs to record the three hours they worked in the right place.

All three are talking about the same work, but not the same information. Development says what kind of hour was done. Implement the payments integration says which deliverable consumed those hours.

When a company tries to represent both things with a single list of "tasks," two problems show up at once: the report gets fragmented and the Kanban loses its meaning. The fix does not depend on the name the software uses. It starts by separating hour classification from project delivery.

An hour needs classification and context

Every time entry needs to answer at least:

1. Which project did the work happen in?
2. What kind of work was done?
3. Which deliverable or request was being carried out?

Project, category, and deliverable are different dimensions. A company may call the second one a task, a service, a discipline, or an activity type. The third may show up as an activity, a card, a work item, or a task. The vocabulary varies; the job of each piece of information does not.

In RabbitWork, task is the name given to the reusable type of work, while activity is the executable item on the project. That is a product modeling choice, not a universal rule of language.

Tasks tab: work categories reused across projects

Example: a website development project

Imagine an agency running the project "Company X's new website."

The catalog of work types can stay small and be reused:

• Design
• Development
• Meeting
• Testing

The execution plan holds specific deliverables:

• Approve the wireframe with the client
• Implement checkout
• Set up the analytics events
• Sign off the final version

One entry could record 2h30 of Development on the activity Implement checkout, inside the project Company X's new website.

Each part answers a question. The project identifies where the cost happened. The "Development" task lets you group equivalent hours across clients. The "Implement checkout" activity shows which deliverable consumed the time and how much is left before it is done.

If "Implement checkout" is registered as a work type on the account, it will hardly be reused with the same meaning. If "Development" becomes a Kanban card, nobody knows which result has to be delivered before it can move to "Done."

How mixing them hurts reports

A useful classification has to stay stable. If each project creates "Website X development," "App Y development," and "Client Z dev," the report stops answering how much time the company invested in development. Before anyone can analyze it, someone has to manually consolidate names that mean the same thing.

The effect reaches billing too. When categories define billable hour types or different rates, an inconsistent taxonomy makes it harder to explain how the amount is composed to the client. The problem is not a lack of data. It is having many names for the same concept.

A good hour category usually:

• can be used on several projects;
• represents a nature of work, not a deliverable;
• stays understandable without the client's name;
• allows financial or operational grouping;
• changes less often than project scope.

How mixing them weakens the Kanban

The Kanban needs to show flow. Each card should represent something that can move from one stage to the next and reach a recognizable done state.

A card called "Development" does not make clear what is being developed, who owns the delivery, or when it will be ready. The column changes, but the real progress is still explained in chat, in a meeting, or in a side spreadsheet.

A card like "Implement password recovery" is something you can manage. You can assign a person, set a date, estimate hours, describe the definition of done, and split the delivery into smaller steps.

On the RabbitWork Kanban board, each card is an activity. The list and the board show the same entity; moving the card changes its stage, not the classification of the hours logged.

Kanban board with activities specific to the project

A simple test before you create an item

Before you create an item, ask two questions.

Should this be an hour category?

Use a category when:

• the name makes sense on other projects;
• finance needs to group the hours this way;
• it represents a specialty, a discipline, or a mode of work;
• it has no done condition of its own.

"Consulting," "Design," and "Meeting" usually pass this test.

Should this be a project activity?

Use an activity when:

• there is an identifiable deliverable or result;
• someone can own it;
• there is a due date, an estimate, or a priority;
• the item can change stage and be completed;
• files, comments, or decisions need to stay in that context.

"Review the commercial proposal" and "Sign off the app with the client" are usually activities.

If the delivery is large, use sub-activities to represent its steps. Do not turn each step into an account-level category.

How to reorganize a structure that already got messy

You do not need to rewrite the whole history. Start with the active projects and set a rule for the next entries.

1. List the current work types. Spot synonyms, client names, and specific deliverables.
2. Separate what is reusable. Keep broad categories that make sense across different projects.
3. Avoid duplicates. Pick one primary form, such as "Development," instead of also keeping "Dev" and "Programming" for the same purpose.
4. Archive what should not be reused. The hour history can stay tied to the old records without offering that name for new entries.
5. Create activities for the open deliverables. Bring into the project the items that need an owner, a due date, and follow-up.
6. Adopt a title convention. Verbs make the delivery checkable: implement, review, approve, publish, sign off.
7. Apply the new structure from here forward. Changing historical data is only worth it when there is a concrete accounting or analytical need.

In RabbitWork, setting up the catalog and applying it to projects is explained in how to add tasks to the project. Owner, due date, estimate, description, and history are covered in how to create an activity.

How to tell whether the organization improved

After a few weeks, look for objective signs:

• the report groups work types without depending on the client's name;
• the catalog stopped growing with every new request;
• the cards describe deliverables the team recognizes;
• the important activities have an owner and a due date;
• you can compare the estimate with the hours logged;
• files and decisions are tied to the delivery;
• the person logging time knows how to classify the hour without creating a new record.

This separation improves two different conversations. Finance starts to see how the hours are composed. The person managing the project starts to see deliverables, owners, and flow.

How RabbitWork implements this model

In RabbitWork, the task classifies the hour and can be reused across projects. The activity organizes the specific work on the list or on the Kanban, with an owner, a due date, labels, an estimate, logged hours, a description, sub-activities, attachments, comments, and history.

The point is not to argue which word is linguistically correct. It is to stop a single list from trying to serve at once as a financial catalog and as an execution plan. When each structure answers the right question, time entries produce better reports and the Kanban goes back to representing the real work.

To set up this separation, see the difference between activities and tasks and the guide to managing activities on the project.