Flow’s ticket-based reports pull information from Jira and ADO services to give you insights into your ticket delivery processes. These ticketing systems are highly configurable, so your experience with Flow’s ticket-based reports varies based on settings in your ticketing system and in Flow.
This article outlines some of the outcomes of these differing experiences and how to configure Flow to work best for you.
Note: If you use a workflow that does not align with how Flow processes ticket data, Flow may show your data differently than expected or not at all.
Differences in data between Flow and your ticketing system
The data you see in Flow might differ from what you see in your ticketing system.
Sometimes this is a natural result of how Flow processes your data. Other times, you need to update your configurations to ensure accurate data processing.
Flow doesn’t delete ticket data, even if you delete tickets from your ticketing system.
If you notice discrepancies in metrics like your total number of completed tickets, check your ticket configurations. Make sure all your ticket status mappings and ticket configurations are set correctly. For example, if you exclude a ticket type in Flow, that ticket type doesn’t count toward Flow metrics, but may be included in the metrics in your ticketing system.
Flow ingests data for the Sprint movement report at the end of a sprint. This is a snapshot of the data at the end of the sprint, and does not change later.
Flow only sees the total number of story points at the end of a sprint. This means if the number of story points in a sprint changes during a sprint, Flow may show a different number of story points than what you see in your ticketing system.
- If you remove committed tickets from a sprint before it ends, the tickets still count as committed work for the sprint and appear in Sprint movement. If tickets are added after a sprint starts and removed before it ends, they do not count as committed work and do not appear in Sprint movement.
If you bulk change label names in Jira, Flow does not receive data on the updated labels. This means bulk editing Investment layers in Jira will not result in Investment layer categories being updated for past tickets in Investment profile. New tickets created with the updated labels will show the updated label in Flow. If this happens you will see both old and new Investment layers listed.
Differences in data between Flow reports
Each Flow report has a different function. While Flow works to bring you consistent data across your reports, your data may show up differently across reports based on their function.
Differences in sprints between Flow reports
The Sprint movement and Ticket log reports ingest sprint data directly from your ticketing system. Flow automatically shows your sprints based on how they’re configured in Jira or ADO services. Flow doesn’t use data from ADO releases (external site, opens in new tab).
Tip: When searching for sprints in Sprint movement, other teams’ sprints may show as options when filtering for a specific team. Sprint movement shows all sprints with tickets assigned to a team. If a team member works on a ticket in a different team’s sprint, that sprint appears as an option in Sprint movement.
Other Flow reports like Team health insights let you filter by sprints. Since these sprints are configured in Flow, not ingested from your ticketing system, sprints configured in Flow may not match the sprints in your ticketing system.
Differences between Sprint movement and Retrospective
Sprint movement doesn’t show work done during a sprint that isn’t assigned to the sprint. This is usually work done from the backlog that isn’t assigned to the sprint. However, the Retrospective report shows this work during the corresponding time period. This means your total tickets completed could look different when comparing Sprint movement and Retrospective during the same time period.
Work done in your team’s project by another team is also not accounted for in your sprint. This work is visible in Retrospective, but not Sprint movement.
When selecting a date range in Retrospective, Flow looks for any activity through the end of the last day selected. You cannot filter by hours. Work completed on the day your sprint ends but after the sprint ends appears in Retrospective, but not Sprint movement.
Tip: If you’re trying to find a ticket but you’re not seeing it in Sprint movement or Retrospective, search Ticket log. It gives you a source of truth for tickets Flow has ingested. Follow these steps for finding missing tickets if you need additional help.
Troubleshooting steps for missing data in Flow reports
Sometimes, Flow doesn’t show data in ticket-based reports as you expect. Potential reasons may include:
Flow hasn’t processed the data yet.
Ticket project configurations in Flow need to be adjusted.
Team membership and view rights settings are impacting what a user is able to see.
When does Flow process my data?
Flow processes ticket data every few hours. Changes to tickets in your ticketing system don’t immediately show up in Flow.
Flow shows when data was last processed in the upper right corner of Ticket log, Retrospective, and Sprint movement. If you’re not seeing data for recent activity, wait until Flow reprocesses your data, then try again.
Sprint movement only shows completed sprints. This report doesn’t show in-progress sprints. To see data for an in-progress sprint, use Ticket log to filter by the sprint you’re interested in.
Flow only shows ticket data for tickets updated within the past twelve months. Older tickets do not appear in Ticket log or other ticket-based reports.
Resolving issues with ticket configurations
If tickets from a ticket project aren’t showing data as expected, check that your ticket configuration is set up correctly. Every ticket project in an integration needs its own configuration because each project can have a unique set of ticket types, statuses, and activity weights.
Use the Ticket configurations article to review how to configure your ticket projects.
Double-check that you’ve mapped your ticket statuses to Not started, Active, or Done states. In most cases, Flow looks at tickets in Active or Done states when showing data in reports. For reports like Sprint movement, tickets must be moved to an Active state to appear in the report.
If there aren’t any tickets in those states, Flow doesn’t display data. If you don’t see ticket data in your reports, first check to make sure your ticket projects are configured.
While you’re checking to make sure your projects are configured correctly, check the status of your project on the Ticket project page. Use the data status column to make sure your projects are in a healthy state. If they are in a failed or rate limited state, click the data status link to view information about how to resolve the issue.
Resolving issues with team memberships and view rights
If you have individuals on your team who can't see their work in reports, make sure the team is set up correctly.
Ticket-based reports are primarily team reports, so you need to make sure all team members have their work accounted for.
If data from some team members isn’t showing in reports:
Go to the Teams page in Flow.
Find the team you want to view data for.
Make sure all members of the team have been added to the team.
Check that every person on the team whose data should be visible in reports is marked as a Contributor. Team members whose membership type is Viewer can see reports, but Flow doesn’t show their data in reports.
If some team members can't access ticket-based reports:
If you can't find tickets for an individual in Ticket log, make sure they’re assigned to a team. Ticket log only shows tickets for Flow users assigned to teams, either as contributors or viewers.
Note: Flow shows ticket data based on historical assignees in your ticketing system. When filtering based on a team, tickets only appear in ticket-based reports if any of the assignees from the time the ticket moves into an Active state are on the team.
Tickets which have never had an assignee in an Active state don’t appear in ticket-based reports, except for Ticket log.
Resolving issues with Sprint movement scope added
Sometimes, Sprint movement shows a higher scope added percentage than expected. Usually this is because tickets are added to the sprint after the sprint starts.
Tickets are considered added if they are added to the sprint after the sprint starts. Sometimes teams add work to the sprint on the first day of the sprint. If this happens after the sprint starts in your vendor, it counts as added work by default, regardless of whether or not you added it as part of a normal sprint kickoff meeting.
The main solution to this is assigning tickets to a sprint before a sprint starts.
- If you use Jira, customize when a sprint starts using the start sprint feature (external site, opens in new tab).
- If you use ADO, your sprint/iteration always starts at 00:00:00Z or midnight UTC on the day the sprint starts. This is not configurable.
In Flow, use the sprint grace period setting in each project to ensure that any ticket added within the first 24 hours of the sprint starting will be considered committed work, not added work. This will be most useful if you do sprint planning on the first day of the sprint.
Troubleshooting story points in Flow
Flow pulls story points data from your ticketing system to show in Flow. There are many ways to store data about story points in both Jira and ADO. Flow looks at the default and most common places to store story points when ingesting data. If you store story point data in a different location, you must indicate that when configuring your ticket projects.
These default locations are different in Jira and ADO. If you either see no story point data for your projects or the wrong story point data for your projects, check your ticket vendor to see if you’re using a custom story point field and if you need to set that up in Flow.
Where does Flow ingest Jira story point data from?
For company-managed projects, Flow looks at Jira's system Story points field by default when ingesting story points.
For team-managed projects, Flow looks at the Jira system Story point estimation field by default when ingesting story points.
If you use a field in Jira other than the system fields listed above to store your story point data, use the Custom mapping section of the ticket configuration wizard to tell Flow where to look for your story point data. You can tell if you need to update this mapping if your ticket reports show no story point data, even though your organization uses story points. Learn more about configuring ticket projects.
Note: Jira allows the creation of custom fields with the same name as these system fields. Make sure you use the system fields and not any custom fields with the same or similar names. The field ID for custom fields (external site, opens in new tab) always starts with cf.
Where does Flow ingest ADO story point data from?
Flow processes ADO story point data from the default project template types and work items.
These are the fields Flow uses for story points in each work item type for multiple project template types:
|Product backlog item
If you don’t use one of these templates, fields, or work item types to store your story point data, use the Custom mapping section of the ticket configuration wizard to tell Flow where to look for your story point data. You can tell if you need to update this mapping if your ticket reports show no story point data, even though your organization uses story points, effort, or size. Learn more about configuring ticket projects.
If you need help, please contact Pluralsight Support.