GitHub units, metrics, and properties
GitHub units, metrics, and properties
This page describes the available units, metrics, and properties when creating a chart for a GitHub data source.
See also these related resources:
Chart editor guide
Creating charts using GitHub Projects custom fields
Screenful Knowledge base
Units
Units are the numbers shown in the charts. Unit can be any of these:
Issues and PRs | The default unit is Issue or pull request i.e. a chart displays the count of issues and pull requests. |
|---|---|
Number field | Your custom Number fields can be used as unit in the charts. Available for GitHub Projects data sources. |
Dropdown field | Your custom Dropdown fields can be mapped as units. Available for GitHub Projects data sources. |
Time in state | Timing metrics (reaction, lead, cycle time). These are calculated for all issues and subtasks. |
All units share these characteristics:
They can be filtered by any property of an issue
They can be summarized as sum, average, or median
They can be formatted as numbers, monetary units, or time units
Metrics
Metrics are the calculations performed on the selected unit.
Total | Shows the total amount of the selected unit in the selected data sources. |
|---|---|
Not started | Work not started according to the workflow settings. |
Not started & In progress | Incomplete work according to the workflow settings. |
In progress | Work in progress according to the workflow settings. |
Created (within date range) | Issues by creation date (issue creation date from the GitHub API). |
Completed (within date range) | Issues by Date completed. The last date & time when the issue or PR was completed (moved to a status mapped as done in the workflow settings). |
By Due date | Issues by Due date. Includes the items that have a Due date within the selected date range (regardless of their workflow state). |
By Start date | Issues by Start date. Includes the items that have a Start date within the selected date range (regardless of their workflow state). |
By [custom Date field] | Issues by a custom Date column. Includes the items that have the date within the specified date range (regardless of their workflow state). |
Reaction time (avg, completed items) | Time before the work was started. The average time spent in the states mapped as Not started in the workflow settings. |
Reaction time (sum, completed items) | Time before the work was started. The sum of time spent in the states mapped as Not started in the workflow settings. |
Cycle time (avg, completed items) | Time from start to completion. The average time spent in the states mapped as In progress in the workflow settings. |
Cycle time (sum, completed items) | Time from start to completion The sum of time spent in the states mapped as In progress in the workflow settings. |
Lead time (avg, completed items) | Lead time (avg) = Time from the issue or PR creation until its completion. |
Lead time (sum, completed items) | Lead time (sum) = Time from the issue or PR creation until its completion. |
Time in state (avg, completed items) | Time spent in specific workflow states. Use the filter to select the states. |
Time in state (sum, completed items) | Time spent in specific workflow states. Use the filter to select the states. |
Issue properties
Issue properties that can be displayed as columns in a Task list.
Assignee | The assigned person |
|---|---|
Assignees | The assigned persons (if multiple) |
Base branch | Base branch of a pull request. |
Completed on time | Was the issue completed before the due date (true/false). |
Created by | The person who created the issue or PR. |
Cycle time | Time from start to completion. The time spent in the states mapped as In progress in the workflow settings. |
Cycle time (working hours) | Time from start to completion. The time spent in the states mapped as In progress in the workflow settings. Time is calculated only within the set working days and hours. |
Data source | The GitHub board the issue or PR is currently in, or the repository, depending on which one was imported. |
Date completed | The last date & time when the issue or PR was completed (moved to a status mapped as done in the workflow settings). |
Date created | Issue or PR creation date (from the GitHub API). |
Date updated | Last update date (from the GitHub API) |
Due date | Issue Due date. |
GitHub ID | Issue or pull request number (from the GitHub API). |
Head branch | Head branch of a pull request. |
Issue or PR ID | Unique identifier of the issue or pull request (from the GitHub API). |
Issue or PR name | Issue or PR Title. A brief summary of the issue or pull request. |
Issue type | Issue type (e.g. Task, Bug, or Feature). |
Item type | Draft issue, issue, or pull request. |
Label | The labels added to the issue or PR. |
Lead time | Time from the issue or PR creation until its completion. |
Lead time (working hours) | Time from the issue or PR creation until its completion, during the specified working hours. |
Mapped state | Mapped workflow state according to the workflow settings. Either Not started, In progress, or Done. |
Milestone | The Milestone the issue or PR is currently in. |
Moved to mapped state | The time when the issue or PR was moved to its current mapped workflow state. |
Moved to workflow state | The time when the issue or PR was moved to its current workflow state. |
Project | The Project the issue or PR is currently in. |
Reaction time | The time before the work was started. The time spent in the states mapped as Not started in the workflow settings. |
Reaction time (working hours) | The time before the work was started. The time spent in the states mapped as Not started in the workflow settings during the specified working hours. |
Reopened | Whether the issue or PR has been reopened (true/false) |
Repository | The Repository the issue or PR is currently in. |
Reviewer | The person who reviewed the pull request |
Sprint (completed in) | The Sprint the issue was completed in. |
Start date | Issue Start date. |
State (open/done) | Whether the issue PR's mapped state is Open (Not started or In progress) or Done. |
Time in progress | The time spent in the states mapped as In progress in the workflow settings. |
Time in progress (working hours) | The time spent in the states mapped as In progress in the workflow settings during the specified working hours. |
Time in workflow state | The total time spent by the issue or PR been in its current workflow state. |
Timings | The total time spent in each workflow state. |
Workflow state | The current workflow state of the issue or pull request. |
This page describes the available units, metrics, and properties when creating a chart for a GitHub data source.
See also these related resources:
Chart editor guide
Creating charts using GitHub Projects custom fields
Screenful Knowledge base
Units
Units are the numbers shown in the charts. Unit can be any of these:
Issues and PRs | The default unit is Issue or pull request i.e. a chart displays the count of issues and pull requests. |
|---|---|
Number field | Your custom Number fields can be used as unit in the charts. Available for GitHub Projects data sources. |
Dropdown field | Your custom Dropdown fields can be mapped as units. Available for GitHub Projects data sources. |
Time in state | Timing metrics (reaction, lead, cycle time). These are calculated for all issues and subtasks. |
All units share these characteristics:
They can be filtered by any property of an issue
They can be summarized as sum, average, or median
They can be formatted as numbers, monetary units, or time units
Metrics
Metrics are the calculations performed on the selected unit.
Total | Shows the total amount of the selected unit in the selected data sources. |
|---|---|
Not started | Work not started according to the workflow settings. |
Not started & In progress | Incomplete work according to the workflow settings. |
In progress | Work in progress according to the workflow settings. |
Created (within date range) | Issues by creation date (issue creation date from the GitHub API). |
Completed (within date range) | Issues by Date completed. The last date & time when the issue or PR was completed (moved to a status mapped as done in the workflow settings). |
By Due date | Issues by Due date. Includes the items that have a Due date within the selected date range (regardless of their workflow state). |
By Start date | Issues by Start date. Includes the items that have a Start date within the selected date range (regardless of their workflow state). |
By [custom Date field] | Issues by a custom Date column. Includes the items that have the date within the specified date range (regardless of their workflow state). |
Reaction time (avg, completed items) | Time before the work was started. The average time spent in the states mapped as Not started in the workflow settings. |
Reaction time (sum, completed items) | Time before the work was started. The sum of time spent in the states mapped as Not started in the workflow settings. |
Cycle time (avg, completed items) | Time from start to completion. The average time spent in the states mapped as In progress in the workflow settings. |
Cycle time (sum, completed items) | Time from start to completion The sum of time spent in the states mapped as In progress in the workflow settings. |
Lead time (avg, completed items) | Lead time (avg) = Time from the issue or PR creation until its completion. |
Lead time (sum, completed items) | Lead time (sum) = Time from the issue or PR creation until its completion. |
Time in state (avg, completed items) | Time spent in specific workflow states. Use the filter to select the states. |
Time in state (sum, completed items) | Time spent in specific workflow states. Use the filter to select the states. |
Issue properties
Issue properties that can be displayed as columns in a Task list.
Assignee | The assigned person |
|---|---|
Assignees | The assigned persons (if multiple) |
Base branch | Base branch of a pull request. |
Completed on time | Was the issue completed before the due date (true/false). |
Created by | The person who created the issue or PR. |
Cycle time | Time from start to completion. The time spent in the states mapped as In progress in the workflow settings. |
Cycle time (working hours) | Time from start to completion. The time spent in the states mapped as In progress in the workflow settings. Time is calculated only within the set working days and hours. |
Data source | The GitHub board the issue or PR is currently in, or the repository, depending on which one was imported. |
Date completed | The last date & time when the issue or PR was completed (moved to a status mapped as done in the workflow settings). |
Date created | Issue or PR creation date (from the GitHub API). |
Date updated | Last update date (from the GitHub API) |
Due date | Issue Due date. |
GitHub ID | Issue or pull request number (from the GitHub API). |
Head branch | Head branch of a pull request. |
Issue or PR ID | Unique identifier of the issue or pull request (from the GitHub API). |
Issue or PR name | Issue or PR Title. A brief summary of the issue or pull request. |
Issue type | Issue type (e.g. Task, Bug, or Feature). |
Item type | Draft issue, issue, or pull request. |
Label | The labels added to the issue or PR. |
Lead time | Time from the issue or PR creation until its completion. |
Lead time (working hours) | Time from the issue or PR creation until its completion, during the specified working hours. |
Mapped state | Mapped workflow state according to the workflow settings. Either Not started, In progress, or Done. |
Milestone | The Milestone the issue or PR is currently in. |
Moved to mapped state | The time when the issue or PR was moved to its current mapped workflow state. |
Moved to workflow state | The time when the issue or PR was moved to its current workflow state. |
Project | The Project the issue or PR is currently in. |
Reaction time | The time before the work was started. The time spent in the states mapped as Not started in the workflow settings. |
Reaction time (working hours) | The time before the work was started. The time spent in the states mapped as Not started in the workflow settings during the specified working hours. |
Reopened | Whether the issue or PR has been reopened (true/false) |
Repository | The Repository the issue or PR is currently in. |
Reviewer | The person who reviewed the pull request |
Sprint (completed in) | The Sprint the issue was completed in. |
Start date | Issue Start date. |
State (open/done) | Whether the issue PR's mapped state is Open (Not started or In progress) or Done. |
Time in progress | The time spent in the states mapped as In progress in the workflow settings. |
Time in progress (working hours) | The time spent in the states mapped as In progress in the workflow settings during the specified working hours. |
Time in workflow state | The total time spent by the issue or PR been in its current workflow state. |
Timings | The total time spent in each workflow state. |
Workflow state | The current workflow state of the issue or pull request. |
This page describes the available units, metrics, and properties when creating a chart for a GitHub data source.
See also these related resources:
Chart editor guide
Creating charts using GitHub Projects custom fields
Screenful Knowledge base
Units
Units are the numbers shown in the charts. Unit can be any of these:
Issues and PRs | The default unit is Issue or pull request i.e. a chart displays the count of issues and pull requests. |
|---|---|
Number field | Your custom Number fields can be used as unit in the charts. Available for GitHub Projects data sources. |
Dropdown field | Your custom Dropdown fields can be mapped as units. Available for GitHub Projects data sources. |
Time in state | Timing metrics (reaction, lead, cycle time). These are calculated for all issues and subtasks. |
All units share these characteristics:
They can be filtered by any property of an issue
They can be summarized as sum, average, or median
They can be formatted as numbers, monetary units, or time units
Metrics
Metrics are the calculations performed on the selected unit.
Total | Shows the total amount of the selected unit in the selected data sources. |
|---|---|
Not started | Work not started according to the workflow settings. |
Not started & In progress | Incomplete work according to the workflow settings. |
In progress | Work in progress according to the workflow settings. |
Created (within date range) | Issues by creation date (issue creation date from the GitHub API). |
Completed (within date range) | Issues by Date completed. The last date & time when the issue or PR was completed (moved to a status mapped as done in the workflow settings). |
By Due date | Issues by Due date. Includes the items that have a Due date within the selected date range (regardless of their workflow state). |
By Start date | Issues by Start date. Includes the items that have a Start date within the selected date range (regardless of their workflow state). |
By [custom Date field] | Issues by a custom Date column. Includes the items that have the date within the specified date range (regardless of their workflow state). |
Reaction time (avg, completed items) | Time before the work was started. The average time spent in the states mapped as Not started in the workflow settings. |
Reaction time (sum, completed items) | Time before the work was started. The sum of time spent in the states mapped as Not started in the workflow settings. |
Cycle time (avg, completed items) | Time from start to completion. The average time spent in the states mapped as In progress in the workflow settings. |
Cycle time (sum, completed items) | Time from start to completion The sum of time spent in the states mapped as In progress in the workflow settings. |
Lead time (avg, completed items) | Lead time (avg) = Time from the issue or PR creation until its completion. |
Lead time (sum, completed items) | Lead time (sum) = Time from the issue or PR creation until its completion. |
Time in state (avg, completed items) | Time spent in specific workflow states. Use the filter to select the states. |
Time in state (sum, completed items) | Time spent in specific workflow states. Use the filter to select the states. |
Issue properties
Issue properties that can be displayed as columns in a Task list.
Assignee | The assigned person |
|---|---|
Assignees | The assigned persons (if multiple) |
Base branch | Base branch of a pull request. |
Completed on time | Was the issue completed before the due date (true/false). |
Created by | The person who created the issue or PR. |
Cycle time | Time from start to completion. The time spent in the states mapped as In progress in the workflow settings. |
Cycle time (working hours) | Time from start to completion. The time spent in the states mapped as In progress in the workflow settings. Time is calculated only within the set working days and hours. |
Data source | The GitHub board the issue or PR is currently in, or the repository, depending on which one was imported. |
Date completed | The last date & time when the issue or PR was completed (moved to a status mapped as done in the workflow settings). |
Date created | Issue or PR creation date (from the GitHub API). |
Date updated | Last update date (from the GitHub API) |
Due date | Issue Due date. |
GitHub ID | Issue or pull request number (from the GitHub API). |
Head branch | Head branch of a pull request. |
Issue or PR ID | Unique identifier of the issue or pull request (from the GitHub API). |
Issue or PR name | Issue or PR Title. A brief summary of the issue or pull request. |
Issue type | Issue type (e.g. Task, Bug, or Feature). |
Item type | Draft issue, issue, or pull request. |
Label | The labels added to the issue or PR. |
Lead time | Time from the issue or PR creation until its completion. |
Lead time (working hours) | Time from the issue or PR creation until its completion, during the specified working hours. |
Mapped state | Mapped workflow state according to the workflow settings. Either Not started, In progress, or Done. |
Milestone | The Milestone the issue or PR is currently in. |
Moved to mapped state | The time when the issue or PR was moved to its current mapped workflow state. |
Moved to workflow state | The time when the issue or PR was moved to its current workflow state. |
Project | The Project the issue or PR is currently in. |
Reaction time | The time before the work was started. The time spent in the states mapped as Not started in the workflow settings. |
Reaction time (working hours) | The time before the work was started. The time spent in the states mapped as Not started in the workflow settings during the specified working hours. |
Reopened | Whether the issue or PR has been reopened (true/false) |
Repository | The Repository the issue or PR is currently in. |
Reviewer | The person who reviewed the pull request |
Sprint (completed in) | The Sprint the issue was completed in. |
Start date | Issue Start date. |
State (open/done) | Whether the issue PR's mapped state is Open (Not started or In progress) or Done. |
Time in progress | The time spent in the states mapped as In progress in the workflow settings. |
Time in progress (working hours) | The time spent in the states mapped as In progress in the workflow settings during the specified working hours. |
Time in workflow state | The total time spent by the issue or PR been in its current workflow state. |
Timings | The total time spent in each workflow state. |
Workflow state | The current workflow state of the issue or pull request. |
Learn more
Learn more
FAQ
Common questions
It depends on whether you're importing GitHub repositories or GitHub Projects.
When you import GitHub repositories, one data source can contain multiple repositories. You can select the repositories to include in the data source by selecting them at the time of import.
When you import GitHub Projects, a data source is one GitHub Project.
The difference between these is that when importing a GitHub Project, you can use project metadata, such as statuses, iterations, and custom fields, in your reports, which are not available when importing repositories.
You can import data sources from all the tools we support in the same Screenful account. Learn more about managing data sources.
It depends on whether you're importing GitHub repositories or GitHub Projects.
When you import GitHub repositories, one data source can contain multiple repositories. You can select the repositories to include in the data source by selecting them at the time of import.
When you import GitHub Projects, a data source is one GitHub Project.
The difference between these is that when importing a GitHub Project, you can use project metadata, such as statuses, iterations, and custom fields, in your reports, which are not available when importing repositories.
You can import data sources from all the tools we support in the same Screenful account. Learn more about managing data sources.
Yes, we support both user-owned and organization-wide project boards as well as repository project boards. You can import both classic and new projects.
Yes, we support both user-owned and organization-wide project boards as well as repository project boards. You can import both classic and new projects.
When you import a data source, all data is imported and made available for reporting. You can narrow the data to any subset by setting a filter. For example, you can filter out issues or pull request by using 'Type' filter.
When you import a data source, all data is imported and made available for reporting. You can narrow the data to any subset by setting a filter. For example, you can filter out issues or pull request by using 'Type' filter.
The Analytics & Reports GitHub App requires read-only access to issues, members, metadata, organization administration, organization projects, pull requests, and repository projects.
The Analytics & Reports GitHub App requires read-only access to issues, members, metadata, organization administration, organization projects, pull requests, and repository projects.
The Analytics & Reports OAuth app requires these OAuth scopes:
"read:org"
"repo" or "public_repo" (depending on whether user selects "authorise public repos only" or "authorize public and private repos”
An OAuth token will share the permissions of the user that authorized the application. That means, if your account authorizes the application and has 'write' permission to a repository, the token will also have 'write' permission to that repository. This is how OAuth tokens work in the GitHub platform.
From a security point of view, we recommend using the GitHub app instead of the OAuth app.
The Analytics & Reports OAuth app requires these OAuth scopes:
"read:org"
"repo" or "public_repo" (depending on whether user selects "authorise public repos only" or "authorize public and private repos”
An OAuth token will share the permissions of the user that authorized the application. That means, if your account authorizes the application and has 'write' permission to a repository, the token will also have 'write' permission to that repository. This is how OAuth tokens work in the GitHub platform.
From a security point of view, we recommend using the GitHub app instead of the OAuth app.
You can’t switch an existing Screenful account from OAuth to GitHub App. To use the GitHub App, you need to create a new Screenful account.
You can’t switch an existing Screenful account from OAuth to GitHub App. To use the GitHub App, you need to create a new Screenful account.
When importing project boards, you can specify your workflow based on the columns on the board which you can configure in the workflow settings. You can learn more from the Lead Time FAQ.
When importing repositories, the timing metrics are calculated as follows:
Lead time starts when an issue is created
Cycle time starts when the issue is assigned to a person, or when pull request is opened
Lead & cycle time is stopped when the issue is closed, or the pull request merged
When importing project boards, you can specify your workflow based on the columns on the board which you can configure in the workflow settings. You can learn more from the Lead Time FAQ.
When importing repositories, the timing metrics are calculated as follows:
Lead time starts when an issue is created
Cycle time starts when the issue is assigned to a person, or when pull request is opened
Lead & cycle time is stopped when the issue is closed, or the pull request merged
You can manage the subscription in the billing settings. The location of the billing settings depends on the product you are subscribed to. You can learn more by following the instructions in this guide.
You can manage the subscription in the billing settings. The location of the billing settings depends on the product you are subscribed to. You can learn more by following the instructions in this guide.
We do not make changes to your data. We only read it via the API of your tool. Screenful is only for reporting and analytics. It does not update any data within your tools.
We do not make changes to your data. We only read it via the API of your tool. Screenful is only for reporting and analytics. It does not update any data within your tools.
All data sources are synced automatically once per hour. Changing settings or configuration will trigger additional sync so your data is at most one hour old. You can sync data manually at any time in the sync settings.
All data sources are synced automatically once per hour. Changing settings or configuration will trigger additional sync so your data is at most one hour old. You can sync data manually at any time in the sync settings.
Yes, you can create charts with a prompt and ask questions about a chart by using the Screenful AI Assistant. The assistant combines the leading LLMs with advanced multidimensional data analytics to help you understand and interpret your data.
Yes, you can create charts with a prompt and ask questions about a chart by using the Screenful AI Assistant. The assistant combines the leading LLMs with advanced multidimensional data analytics to help you understand and interpret your data.
What is the difference between these metrics?
Reaction time = time before the work was started
Cycle time = time from start to completion
Lead time = Reaction time + Cycle time
Timing metrics explained: Lead time vs Cycle time
How is the reaction time calculated?
Reaction time starts running when a task is moved into a state that is mapped to the "Not started" in the workflow mapping. The reaction time stops when the task is moved out from that state. If the task is never placed into a state that is mapped to the “Not started” workflow state, then the reaction time is zero.
What if tasks skip lists/columns, or there is no sequential workflow?
The timing information is based on how long items stay in the workflow states that are mapped to "In progress" in the workflow mapping. There is no need for sequential progress, and it is totally fine if tasks skip some of the workflow steps.
What if a task is moved from the “not started” state directly to “done” without going through any of the “in progress” states?
In that case, the cycle time will be zero.
How does the cycle time work if a task is moved into "in progress" and then back to "not started yet"? Similarly, what happens if a card is archived while it's in progress?
Cycle time is calculated only for completed tasks, so in both of those cases, cycle time would be undefined.
If a task is moved from "in progress" to "done", but then back to "in progress" again for additional work would this time be added to the cycle time?
Cycle time is counted only when the task is in progress, so the time spent in the "done" state is not included in the calculation.
When is a task created? Does the clock start when a task is created or when it is put in the "next" state (or equivalent)?
The clock starts when a task is moved to a workflow state that is mapped to the "not started" or "in progress" workflow state.
Are weekends included in the cycle time calculations?
Weekends are included in the calculations by default, but you can change that in the chart settings by selecting 'Exclude non-business hours. See How to set weekend days and office hours
What is the difference between these metrics?
Reaction time = time before the work was started
Cycle time = time from start to completion
Lead time = Reaction time + Cycle time
Timing metrics explained: Lead time vs Cycle time
How is the reaction time calculated?
Reaction time starts running when a task is moved into a state that is mapped to the "Not started" in the workflow mapping. The reaction time stops when the task is moved out from that state. If the task is never placed into a state that is mapped to the “Not started” workflow state, then the reaction time is zero.
What if tasks skip lists/columns, or there is no sequential workflow?
The timing information is based on how long items stay in the workflow states that are mapped to "In progress" in the workflow mapping. There is no need for sequential progress, and it is totally fine if tasks skip some of the workflow steps.
What if a task is moved from the “not started” state directly to “done” without going through any of the “in progress” states?
In that case, the cycle time will be zero.
How does the cycle time work if a task is moved into "in progress" and then back to "not started yet"? Similarly, what happens if a card is archived while it's in progress?
Cycle time is calculated only for completed tasks, so in both of those cases, cycle time would be undefined.
If a task is moved from "in progress" to "done", but then back to "in progress" again for additional work would this time be added to the cycle time?
Cycle time is counted only when the task is in progress, so the time spent in the "done" state is not included in the calculation.
When is a task created? Does the clock start when a task is created or when it is put in the "next" state (or equivalent)?
The clock starts when a task is moved to a workflow state that is mapped to the "not started" or "in progress" workflow state.
Are weekends included in the cycle time calculations?
Weekends are included in the calculations by default, but you can change that in the chart settings by selecting 'Exclude non-business hours. See How to set weekend days and office hours
By default yes, but you can specify your working hours and days in the Account Settings.
By default yes, but you can specify your working hours and days in the Account Settings.
Yes, there are a few different ways you can filter out outliers from the charts, including
Filtering by item name
Filtering by how long an item has been in progress
Setting a label and filtering out based on that label
You can learn more from this guide: How to remove outliers from data?
Yes, there are a few different ways you can filter out outliers from the charts, including
Filtering by item name
Filtering by how long an item has been in progress
Setting a label and filtering out based on that label
You can learn more from this guide: How to remove outliers from data?
Does this support my specific workflow or do I have to use some specific states like "open", "in progress" and "done"?
You are not limited to any specific set of states or a workflow. You can configure your own workflow, if such exists, and you can use that in your reporting. It's also ok if you don't have any workflow in your boards, as can create reports based on any other criteria by setting a filter.
You are not limited to any specific set of states or a workflow. You can configure your own workflow, if such exists, and you can use that in your reporting. It's also ok if you don't have any workflow in your boards, as can create reports based on any other criteria by setting a filter.
You can embed any custom chart or report to any web page using the embed code. Learn more about the sharing feature from the online guide.
You can embed any custom chart or report to any web page using the embed code. Learn more about the sharing feature from the online guide.
The Getting Started Guide contains Instructions for setting up Screenful.
See also our Accounts & Pricing FAQ.
Check out our knowledge base and video tutorials, or get in touch by emailing support@screenful.com
The Getting Started Guide contains Instructions for setting up Screenful.
See also our Accounts & Pricing FAQ.
Check out our knowledge base and video tutorials, or get in touch by emailing support@screenful.com
FAQ
Common questions
It depends on whether you're importing GitHub repositories or GitHub Projects.
When you import GitHub repositories, one data source can contain multiple repositories. You can select the repositories to include in the data source by selecting them at the time of import.
When you import GitHub Projects, a data source is one GitHub Project.
The difference between these is that when importing a GitHub Project, you can use project metadata, such as statuses, iterations, and custom fields, in your reports, which are not available when importing repositories.
You can import data sources from all the tools we support in the same Screenful account. Learn more about managing data sources.
It depends on whether you're importing GitHub repositories or GitHub Projects.
When you import GitHub repositories, one data source can contain multiple repositories. You can select the repositories to include in the data source by selecting them at the time of import.
When you import GitHub Projects, a data source is one GitHub Project.
The difference between these is that when importing a GitHub Project, you can use project metadata, such as statuses, iterations, and custom fields, in your reports, which are not available when importing repositories.
You can import data sources from all the tools we support in the same Screenful account. Learn more about managing data sources.
Yes, we support both user-owned and organization-wide project boards as well as repository project boards. You can import both classic and new projects.
Yes, we support both user-owned and organization-wide project boards as well as repository project boards. You can import both classic and new projects.
When you import a data source, all data is imported and made available for reporting. You can narrow the data to any subset by setting a filter. For example, you can filter out issues or pull request by using 'Type' filter.
When you import a data source, all data is imported and made available for reporting. You can narrow the data to any subset by setting a filter. For example, you can filter out issues or pull request by using 'Type' filter.
The Analytics & Reports GitHub App requires read-only access to issues, members, metadata, organization administration, organization projects, pull requests, and repository projects.
The Analytics & Reports GitHub App requires read-only access to issues, members, metadata, organization administration, organization projects, pull requests, and repository projects.
The Analytics & Reports OAuth app requires these OAuth scopes:
"read:org"
"repo" or "public_repo" (depending on whether user selects "authorise public repos only" or "authorize public and private repos”
An OAuth token will share the permissions of the user that authorized the application. That means, if your account authorizes the application and has 'write' permission to a repository, the token will also have 'write' permission to that repository. This is how OAuth tokens work in the GitHub platform.
From a security point of view, we recommend using the GitHub app instead of the OAuth app.
The Analytics & Reports OAuth app requires these OAuth scopes:
"read:org"
"repo" or "public_repo" (depending on whether user selects "authorise public repos only" or "authorize public and private repos”
An OAuth token will share the permissions of the user that authorized the application. That means, if your account authorizes the application and has 'write' permission to a repository, the token will also have 'write' permission to that repository. This is how OAuth tokens work in the GitHub platform.
From a security point of view, we recommend using the GitHub app instead of the OAuth app.
You can’t switch an existing Screenful account from OAuth to GitHub App. To use the GitHub App, you need to create a new Screenful account.
You can’t switch an existing Screenful account from OAuth to GitHub App. To use the GitHub App, you need to create a new Screenful account.
When importing project boards, you can specify your workflow based on the columns on the board which you can configure in the workflow settings. You can learn more from the Lead Time FAQ.
When importing repositories, the timing metrics are calculated as follows:
Lead time starts when an issue is created
Cycle time starts when the issue is assigned to a person, or when pull request is opened
Lead & cycle time is stopped when the issue is closed, or the pull request merged
When importing project boards, you can specify your workflow based on the columns on the board which you can configure in the workflow settings. You can learn more from the Lead Time FAQ.
When importing repositories, the timing metrics are calculated as follows:
Lead time starts when an issue is created
Cycle time starts when the issue is assigned to a person, or when pull request is opened
Lead & cycle time is stopped when the issue is closed, or the pull request merged
You can manage the subscription in the billing settings. The location of the billing settings depends on the product you are subscribed to. You can learn more by following the instructions in this guide.
You can manage the subscription in the billing settings. The location of the billing settings depends on the product you are subscribed to. You can learn more by following the instructions in this guide.
We do not make changes to your data. We only read it via the API of your tool. Screenful is only for reporting and analytics. It does not update any data within your tools.
We do not make changes to your data. We only read it via the API of your tool. Screenful is only for reporting and analytics. It does not update any data within your tools.
All data sources are synced automatically once per hour. Changing settings or configuration will trigger additional sync so your data is at most one hour old. You can sync data manually at any time in the sync settings.
All data sources are synced automatically once per hour. Changing settings or configuration will trigger additional sync so your data is at most one hour old. You can sync data manually at any time in the sync settings.
Yes, you can create charts with a prompt and ask questions about a chart by using the Screenful AI Assistant. The assistant combines the leading LLMs with advanced multidimensional data analytics to help you understand and interpret your data.
Yes, you can create charts with a prompt and ask questions about a chart by using the Screenful AI Assistant. The assistant combines the leading LLMs with advanced multidimensional data analytics to help you understand and interpret your data.
What is the difference between these metrics?
Reaction time = time before the work was started
Cycle time = time from start to completion
Lead time = Reaction time + Cycle time
Timing metrics explained: Lead time vs Cycle time
How is the reaction time calculated?
Reaction time starts running when a task is moved into a state that is mapped to the "Not started" in the workflow mapping. The reaction time stops when the task is moved out from that state. If the task is never placed into a state that is mapped to the “Not started” workflow state, then the reaction time is zero.
What if tasks skip lists/columns, or there is no sequential workflow?
The timing information is based on how long items stay in the workflow states that are mapped to "In progress" in the workflow mapping. There is no need for sequential progress, and it is totally fine if tasks skip some of the workflow steps.
What if a task is moved from the “not started” state directly to “done” without going through any of the “in progress” states?
In that case, the cycle time will be zero.
How does the cycle time work if a task is moved into "in progress" and then back to "not started yet"? Similarly, what happens if a card is archived while it's in progress?
Cycle time is calculated only for completed tasks, so in both of those cases, cycle time would be undefined.
If a task is moved from "in progress" to "done", but then back to "in progress" again for additional work would this time be added to the cycle time?
Cycle time is counted only when the task is in progress, so the time spent in the "done" state is not included in the calculation.
When is a task created? Does the clock start when a task is created or when it is put in the "next" state (or equivalent)?
The clock starts when a task is moved to a workflow state that is mapped to the "not started" or "in progress" workflow state.
Are weekends included in the cycle time calculations?
Weekends are included in the calculations by default, but you can change that in the chart settings by selecting 'Exclude non-business hours. See How to set weekend days and office hours
What is the difference between these metrics?
Reaction time = time before the work was started
Cycle time = time from start to completion
Lead time = Reaction time + Cycle time
Timing metrics explained: Lead time vs Cycle time
How is the reaction time calculated?
Reaction time starts running when a task is moved into a state that is mapped to the "Not started" in the workflow mapping. The reaction time stops when the task is moved out from that state. If the task is never placed into a state that is mapped to the “Not started” workflow state, then the reaction time is zero.
What if tasks skip lists/columns, or there is no sequential workflow?
The timing information is based on how long items stay in the workflow states that are mapped to "In progress" in the workflow mapping. There is no need for sequential progress, and it is totally fine if tasks skip some of the workflow steps.
What if a task is moved from the “not started” state directly to “done” without going through any of the “in progress” states?
In that case, the cycle time will be zero.
How does the cycle time work if a task is moved into "in progress" and then back to "not started yet"? Similarly, what happens if a card is archived while it's in progress?
Cycle time is calculated only for completed tasks, so in both of those cases, cycle time would be undefined.
If a task is moved from "in progress" to "done", but then back to "in progress" again for additional work would this time be added to the cycle time?
Cycle time is counted only when the task is in progress, so the time spent in the "done" state is not included in the calculation.
When is a task created? Does the clock start when a task is created or when it is put in the "next" state (or equivalent)?
The clock starts when a task is moved to a workflow state that is mapped to the "not started" or "in progress" workflow state.
Are weekends included in the cycle time calculations?
Weekends are included in the calculations by default, but you can change that in the chart settings by selecting 'Exclude non-business hours. See How to set weekend days and office hours
By default yes, but you can specify your working hours and days in the Account Settings.
By default yes, but you can specify your working hours and days in the Account Settings.
Yes, there are a few different ways you can filter out outliers from the charts, including
Filtering by item name
Filtering by how long an item has been in progress
Setting a label and filtering out based on that label
You can learn more from this guide: How to remove outliers from data?
Yes, there are a few different ways you can filter out outliers from the charts, including
Filtering by item name
Filtering by how long an item has been in progress
Setting a label and filtering out based on that label
You can learn more from this guide: How to remove outliers from data?
Does this support my specific workflow or do I have to use some specific states like "open", "in progress" and "done"?
You are not limited to any specific set of states or a workflow. You can configure your own workflow, if such exists, and you can use that in your reporting. It's also ok if you don't have any workflow in your boards, as can create reports based on any other criteria by setting a filter.
You are not limited to any specific set of states or a workflow. You can configure your own workflow, if such exists, and you can use that in your reporting. It's also ok if you don't have any workflow in your boards, as can create reports based on any other criteria by setting a filter.
You can embed any custom chart or report to any web page using the embed code. Learn more about the sharing feature from the online guide.
You can embed any custom chart or report to any web page using the embed code. Learn more about the sharing feature from the online guide.
The Getting Started Guide contains Instructions for setting up Screenful.
See also our Accounts & Pricing FAQ.
Check out our knowledge base and video tutorials, or get in touch by emailing support@screenful.com
The Getting Started Guide contains Instructions for setting up Screenful.
See also our Accounts & Pricing FAQ.
Check out our knowledge base and video tutorials, or get in touch by emailing support@screenful.com
FAQ
Troubleshooting
You can pull metrics from repositories that you own or that are in your organisation. If your organisation has applied special restrictions on 3rd party access you need to grant access to the Screenful app first.
You can pull metrics from repositories that you own or that are in your organisation. If your organisation has applied special restrictions on 3rd party access you need to grant access to the Screenful app first.
When you create a new Organization within GitHub it may not automatically appear within Screenful. You may need to enable access to the new organizaion within the GItHub UI.
Notice also that the OAuth integration is managed per user account rather than per organization. The integration will see all the organizations for that GitHub user.
To add your new GitHub organization, you will need to add access to Screenful for this new organization:
Navigate to Account(top right) > Settings > Applications > Authorized OAuth Apps
Click on Screenful
Find your Organization(s) and click on Grant.
You should now be able to import repositories and projects from this organization!
When you create a new Organization within GitHub it may not automatically appear within Screenful. You may need to enable access to the new organizaion within the GItHub UI.
Notice also that the OAuth integration is managed per user account rather than per organization. The integration will see all the organizations for that GitHub user.
To add your new GitHub organization, you will need to add access to Screenful for this new organization:
Navigate to Account(top right) > Settings > Applications > Authorized OAuth Apps
Click on Screenful
Find your Organization(s) and click on Grant.
You should now be able to import repositories and projects from this organization!
Go to the Applications settings in GitHub and remove Screenful from the authorised OAuth applications. After that, you can import projects or repositories using a different GitHub account.
Go to the Applications settings in GitHub and remove Screenful from the authorised OAuth applications. After that, you can import projects or repositories using a different GitHub account.
While both the public and private channels are shown in the menu, you won’t receive the report to a private channel without explicitly adding the Screenful app to that channel. Learn how to enable sending to a private Slack channel.
There can also be restrictions on who can install apps to your Slack. Learn how to manage app approval in your Slack workspace.
Some browser plugins may interfere with the authorization process. If you see an empty page during the authorization or the list of channels is empty, you should try with another browser (or ask your colleague to do the Slack authorization).
While both the public and private channels are shown in the menu, you won’t receive the report to a private channel without explicitly adding the Screenful app to that channel. Learn how to enable sending to a private Slack channel.
There can also be restrictions on who can install apps to your Slack. Learn how to manage app approval in your Slack workspace.
Some browser plugins may interfere with the authorization process. If you see an empty page during the authorization or the list of channels is empty, you should try with another browser (or ask your colleague to do the Slack authorization).
Filter options are derived from task data, which means that if you recently added some properties, such as labels, but haven't yet assigned them to any tasks, they won't show up in the filter options. As soon as you assign them to tasks, they will show up in the filter options from then on.
Filter options are derived from task data, which means that if you recently added some properties, such as labels, but haven't yet assigned them to any tasks, they won't show up in the filter options. As soon as you assign them to tasks, they will show up in the filter options from then on.
If you or your colleague didn't receive the user invitation email, you can go to the user settings and click the Copy invitation link button to copy the link to the clipboard. After that, you can share the link via any channel (email, Slack, Teams, etc). You can learn more from the user invitation guide.
If you or your colleague didn't receive the user invitation email, you can go to the user settings and click the Copy invitation link button to copy the link to the clipboard. After that, you can share the link via any channel (email, Slack, Teams, etc). You can learn more from the user invitation guide.
FAQ
Troubleshooting
You can pull metrics from repositories that you own or that are in your organisation. If your organisation has applied special restrictions on 3rd party access you need to grant access to the Screenful app first.
You can pull metrics from repositories that you own or that are in your organisation. If your organisation has applied special restrictions on 3rd party access you need to grant access to the Screenful app first.
When you create a new Organization within GitHub it may not automatically appear within Screenful. You may need to enable access to the new organizaion within the GItHub UI.
Notice also that the OAuth integration is managed per user account rather than per organization. The integration will see all the organizations for that GitHub user.
To add your new GitHub organization, you will need to add access to Screenful for this new organization:
Navigate to Account(top right) > Settings > Applications > Authorized OAuth Apps
Click on Screenful
Find your Organization(s) and click on Grant.
You should now be able to import repositories and projects from this organization!
When you create a new Organization within GitHub it may not automatically appear within Screenful. You may need to enable access to the new organizaion within the GItHub UI.
Notice also that the OAuth integration is managed per user account rather than per organization. The integration will see all the organizations for that GitHub user.
To add your new GitHub organization, you will need to add access to Screenful for this new organization:
Navigate to Account(top right) > Settings > Applications > Authorized OAuth Apps
Click on Screenful
Find your Organization(s) and click on Grant.
You should now be able to import repositories and projects from this organization!
Go to the Applications settings in GitHub and remove Screenful from the authorised OAuth applications. After that, you can import projects or repositories using a different GitHub account.
Go to the Applications settings in GitHub and remove Screenful from the authorised OAuth applications. After that, you can import projects or repositories using a different GitHub account.
While both the public and private channels are shown in the menu, you won’t receive the report to a private channel without explicitly adding the Screenful app to that channel. Learn how to enable sending to a private Slack channel.
There can also be restrictions on who can install apps to your Slack. Learn how to manage app approval in your Slack workspace.
Some browser plugins may interfere with the authorization process. If you see an empty page during the authorization or the list of channels is empty, you should try with another browser (or ask your colleague to do the Slack authorization).
While both the public and private channels are shown in the menu, you won’t receive the report to a private channel without explicitly adding the Screenful app to that channel. Learn how to enable sending to a private Slack channel.
There can also be restrictions on who can install apps to your Slack. Learn how to manage app approval in your Slack workspace.
Some browser plugins may interfere with the authorization process. If you see an empty page during the authorization or the list of channels is empty, you should try with another browser (or ask your colleague to do the Slack authorization).
Filter options are derived from task data, which means that if you recently added some properties, such as labels, but haven't yet assigned them to any tasks, they won't show up in the filter options. As soon as you assign them to tasks, they will show up in the filter options from then on.
Filter options are derived from task data, which means that if you recently added some properties, such as labels, but haven't yet assigned them to any tasks, they won't show up in the filter options. As soon as you assign them to tasks, they will show up in the filter options from then on.
If you or your colleague didn't receive the user invitation email, you can go to the user settings and click the Copy invitation link button to copy the link to the clipboard. After that, you can share the link via any channel (email, Slack, Teams, etc). You can learn more from the user invitation guide.
If you or your colleague didn't receive the user invitation email, you can go to the user settings and click the Copy invitation link button to copy the link to the clipboard. After that, you can share the link via any channel (email, Slack, Teams, etc). You can learn more from the user invitation guide.