# Work log

## Overview

The work log helps you understand what your teams are actually working on day to day. Each dot represents a developer activity (a commit, pull request, review, or issue completion), giving you a more holistic picture of work in progress than your issue tracker alone can provide.

## How it works

<figure><img src="/files/85Z9UZM4oTYNoLWsmudR" alt="Swarmia - Controls in work log" width="563"><figcaption></figcaption></figure>

The controls at the top of the work log page give you flexibility in how you want to group the activity on the work log. The way you group your work will affect what you see on the left side, including the rows and which work activities are grouped on each row. In this example, we are grouping work by Issues and more specifically by epics. This is why we see all of the epics that had some linked activity during the visible time period.

The controls at the bottom let you select which type of activity to display in the work log. In the screenshot above, we have selected to view commits, pull requests, and issue completions.

With epics selected as the grouping and commits, pull requests, and issue completions selected as the visible activity, we are grouping all the work linked to any epic. For Jira issues, this means child issues; for pull requests and commits, it means a direct link to the epic or to any child issue in the issue hierarchy. In practice, a pull request with a link to a Jira task linked to a story, which is again linked to an epic, will be shown as linked to that epic in the work log when grouped by epics.

Activities that we are unable to link to any issue of the selected issue type will still be visible in their own rows on the work log.

The "Other Issues" row shows all activity linked to other issues owned by the team, but we are not grouping it by work log. For example, when grouping by epics, if the team has worked on a standalone task that is not linked to any epic, it will be shown under the "Other Issues" row.

<figure><img src="/files/IQcf1kT5uSTjnxP4AfY5" alt="Swarmia - Other issues in work log" width="563"><figcaption></figcaption></figure>

The "Bugs" row shows all activity linked to the issue type bug. Work related to bugs is separated into its own row, since most teams want to pay special attention to how much work is tied to the bugs they have.

<figure><img src="/files/vw4rwOl8tIy0XK9GQwpp" alt="Swarmia - Bugs in work log" width="563"><figcaption></figcaption></figure>

Finally, the "Everything else" row shows all the activity we cannot group into any of the rows above it. This can include unlinked commits and pull requests, as well as activity linked to Jira issues owned by other teams than the team we are looking at. The "Everything else" row is meant to highlight the more reactive work that might not be reflected in the team's issue tracker. This is why the work log can give you a more holistic picture of your work in progress compared to your issue tracker.

<figure><img src="/files/0dl2wBFgJnuZxQW5MSnS" alt="Swarmia - Everything else in work log" width="563"><figcaption></figcaption></figure>

## Unhealthy patterns

### **Working alone**

People tend to gravitate to working on their own things because it's easy and doesn't involve coordinating with others. However, great teams are built upon collaboration and sharing knowledge.

Look for epics, stories, or tasks where you can only see one contributor. Could they use a hand?

Being able to work on the same feature sets the bar higher for planning because you can't figure things out as you go. This is generally a good thing: better planning reduces wasteful rework, but it can feel painful at first.

<figure><img src="/files/rEw0d81CPUaxdjW67PKz" alt="Swarmia - Working alone in work log"><figcaption></figcaption></figure>

### **Siloed work**

Another form of siloing is when some people always gravitate to working together on the same features or when someone is stuck only fixing bugs or reviewing code.

Look for patterns in which individual contributors are only working on one kind of thing. In the example below, the bottom contributor is mainly reviewing code instead of a balanced mix of commits, pull requests, and reviews.

<figure><img src="/files/TenwGXmb6CQJMY2g2rT0" alt="Swarmia - Different activities in work log"><figcaption></figcaption></figure>

{% hint style="info" %}
Work log can also show you whether the author was on leave, if you have your [HR system connected](/settings/integrations/hr-systems.md) or you've [imported time off data](/settings/integrations/hr-systems/upload-time-off-data-via-csv.md).
{% endhint %}

### **Too much reactive work**

Housekeeping work is important to ensure the team's capability to deliver on roadmap work. But if priorities and focus are unclear, or the team is fighting fires, it can be easy to get lost in the weeds of ad hoc work.

If the work log is bottom-heavy with lots of reactive work (eg. bugs and tasks), try to correct the course by focusing more on high-impact stories and epics.

Is there a lot of bug-fixing work, and work that's not linked to any issues?

<figure><img src="/files/ZVBjmQQ0atlQp28JjU0d" alt="Swarmia - Not linked issues in work log"><figcaption></figcaption></figure>

### **Multitasking and days without progress**

We're encouraged to stop starting and start finishing, but something urgent always comes up. Even short disruptions can impair flow, and context switching is expensive.

Is the team getting interrupted or working on too many things at the same time? Or has the team a habit of creating larger commits and Pull Requests?

<figure><img src="/files/M61o8xq7TzPPVMhOTMOW" alt="Swarmia - Inactive days in work log"><figcaption></figcaption></figure>

## Healthy patterns

### **Team collaboration**

Issues that the team collaborates on are more likely to be completed faster and are usually more fun to work on due to social interaction, knowledge sharing, and quicker reviews.

Look for stories with a high amount of collaborators, and continuous delivery (commits happening regularly every day).

Plan for collaboration (eg. when breaking work into tasks) to increase the odds of collaboration.

<figure><img src="/files/PkKxrqWegxfBNkAyvwy6" alt="Swarmia - Good work habits in work log"><figcaption></figcaption></figure>

### **Increasing focus on the biggest priorities**

Limiting the amount of work is another way to increase team collaboration, and complete batches of work faster. This helps drive focus which ensures the team can progress in their most important priorities.

Again, ensure the stories get continuous progress and little to no empty days. Additionally, look for a step pattern. If there is one, the team transitions well between stories and takes the time to finish work before jumping on to the next topic.

<figure><img src="/files/HjUGNCitMS3Ejfs3OeUc" alt="Swarmia - Good focus in work log"><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.swarmia.com/features/focus/analyzing-the-activity-patterns-on-work-log.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.