> For the complete documentation index, see [llms.txt](https://help.swarmia.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.swarmia.com/definitions/developer-effort-ftes/daily-effort-model.md).
# What changed in the effort model
Swarmia used to calculate [developer effort](/definitions/developer-effort-ftes.md) once per calendar month. It now calculates effort one working day at a time and adds the days up. The whole history is recalculated on the new model, so past figures shifted slightly.
{% columns %}
{% column %}
Legacy monthly model
{% endcolumn %}
{% column %}
Daily model
{% endcolumn %}
{% endcolumns %}
## Why your numbers shifted
The legacy model ran one calculation per month. Anyone with activity landed close to a full FTE, and a single busy stretch of a few days could define a large share of the whole month.
The daily model calculates each working day on its own. Every working day counts equally, no matter how much activity happened on it, and a working day without activity counts as zero. Three groups move the most:
* **Intermittent contributors.** Effort now follows the days someone actually worked, so an engineer active on 5 of 22 working days lands near 0.2 FTE instead of close to 1.0.
* **Issue-tracker work.** Assigned in-progress issue days carry more weight, so work with little code activity is captured better.
* **Part-time engineers with a reduced FTE allocation.** The legacy model relied on that allocation alone. The daily model also lowers effort for the days they don't work, so an allocation set for someone who works fewer days now reduces their effort twice. See [how to set allocations under the daily model](/definitions/developer-effort-ftes.md#part-time-employees).
Two of the changes pull in opposite directions. Dropping the half-weight penalty on unlinked pull requests raises that code work, while giving assigned in-progress issue days more weight raises issue-tracker work. The two roughly cancel out, so the balance between code and issue-tracker work stays close to the legacy model.
## How the daily model compares to the legacy model
| | Legacy effort model | Daily effort model |
| ------------------------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------- |
| How effort is calculated | From a whole month's activity in one calculation | Each working day separately, then added together |
| Granularity of the calculation | One value per month | One value per working day |
| Working days without activity | Only stretches longer than 5 business days are deducted | Every working day without activity lowers effort |
| Minimum activity | Contributors with fewer than 10 activities a month are excluded | No minimum, even a single event counts |
| Contributors with only issue-tracker activity (no code) | Excluded, below the minimum | Receive effort from their assigned in-progress days |
| Activity on pull requests not linked to an issue | Counted at half weight | Counted at full weight |
| Assigned in-progress issues | Counted | Counted, with more weight |
| Human activity on bot-authored pull requests | Excluded | Counted |
| Weekend activity | Added to the month's total | Doesn't add to the month's total |
## What stayed the same
* The same signals count: commits, pull requests, reviews, comments, and assigned in-progress issues.
* Bots are still excluded as contributors.
* FTE allocations for part-time work still apply.
* Time off still lowers effort, from the same sources: your [HR system](/settings/integrations/hr-systems.md), a [CSV upload](/settings/integrations/hr-systems/upload-time-off-data-via-csv.md), or the [Time offs API](/settings/integrations/swarmia-apis/time-off-api.md).
* A contributor still reaches at most 1.0 FTE in a month.
* Exports and the API still report monthly FTE.
We keep refining the effort model based on the data we gather and real usage, making the model more accurate and easier to understand. The daily model is part of that work.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://help.swarmia.com/definitions/developer-effort-ftes/daily-effort-model.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.