---
title: "Check-in"
canonical: "https://support.appfire.com/space/FD/1802633537/Check-in"
format: markdown
---
> Macro (aura-html)

Use Check-in to get concise, data-driven status updates on engineers’ work before and during 1:1s.

Check-in has two views. Set goals for your users with a Status update to get quick insights into an engineer’s progress. Use the Player card to track a user’s trends across Flow metrics.

Use both to help 1:1s run more efficiently and to focus the conversation on what matters to you and your team member.

## Selecting a user and a date range

Select a user and a date range to gain insight into where that user is doing well and where they can improve. These settings apply to the data of the Status update and the player card.

To select a user, date range, and team:

1. Click the down arrow next to the current user’s name to select your desired user. Search by name, or filter users by recent users, users on your teams, or all users.
2. Click the time period next to Date range. Select a preset date range or use the calendar to create your own.
3. Click on the team filter to select the team to compare this user to. Choose whether nested teams are included or excluded.

> ℹ️ For PR-based metrics, selecting a different team may change the user's metrics. PRs are included in metrics only if they were created by a user on the currently selected team and the user viewing the report has the necessary view rights to see those PRs. PRs not created by a member of the selected team but reviewed by the selected user will not be included.

## Status update overview

Use Status update to help set short-term goals for a developer, celebrate their successes, and suggest areas of improvement. The Status update provides quick insights into a developer’s progress on their goal by measuring their activity within a selected time period. Status update breaks down a user’s work patterns across commits, code review, ticket activity, and PRs.

## Setting a user’s short-term goals

In the Status update, users can create short-term goals. These goals help define a user’s success and guide week-over-week improvement on metrics that matter to the user.

> ℹ️ Any user with access to Check-in can edit their own personal short-term goals.

Each objective corresponds with a specific metric:

| Goal | Metric(s) |
| --- | --- |
| Streamline workflow and remove blockers, such as unbatched meetings to have more time to create solutions in the codebase. | Coding days |
| Make small, more frequent commits to make commits easier to review and enable CI/CD. | Commits per day |
| Clarify requirements and scope up front to increase the quality and maintainability of written code. | Efficiency |
| Reduce risk by limiting the number of PRs merged without review. | Unreviewed PRs |
| Maintain focus on new features by spending more time committing new code while maintaining a small and steady commitment to rewriting/cleaning old code. | New work, Legacy refactor |
| Focus on rewriting old code and helping coworkers with their code to improve the overall quality of the codebase. | Legacy refactor, Help others |
| Remove bottlenecks (such as long-running asynchronous communication between devs) in the PR review process to enable timely PR merges into the codebase. | Time to merge |

To set short-term goals:

1. Click **Edit goals** in the top right corner of short-term goals.
2. Click the Objectives dropdown arrow. Select a goal from the Objectives dropdown.
3. Add a target value to track a user’s objective progress over time. Enter targets that are achievable in the time between 1:1s. Goals should be small enough that you see incremental improvement between 1:1s but large enough that you challenge your team members to grow over time.
  If the user performs at or above the team average in the selected objective, the Check-in report encourages the user to select a different objective.
4. Click **Save goal**. The goal and current progress appear in the Status update tab at the bottom of the short-term goals section.
5. When a user hits their goals, edit their goals to challenge them with new goals. Click the **Edit goals** button and select a new objective or adjust the current objective’s values. This strengthens team members across goal areas.

## What type of commits has a user focused on lately?

In the Status update tab, Commit focus shows the percentage of each work type contributed by a team member in the selected date range. Commit focus categorizes a user's work according to the following four [coding metric work types](https://appfire.atlassian.net/wiki/spaces/FD/pages/1802109293): New work, Legacy refactor, Help others, and Rework.

Use Commit focus to balance the type of work a user does on each project. For example, you might expect the Legacy refactor to be at 55%. If you see that it is below 55%, use your 1:1 to explore why and what you both can do to better set and meet goals.

![Commit focus breakdown, with percentages for New work, Legacy refactor, Help others, and Rework, each compared to the team average.](media://4f1d543a-aa79-458a-9019-7b60ea4e217a)

## How complex are a user’s commits?

Commit complexity is a measure of how likely a particular commit is to cause problems. Each commit authored by the selected user is categorized as Low, Medium, or High complexity.

Some complexity is expected. Watch for spikes in complexity toward the end of a sprint. Spikes may indicate setbacks to accomplishing your and your team’s goals.

![Commit complexity pie chart with the breakdown between low, medium, and high complexity commits.](media://48903d87-332c-4b45-b365-e84d52c1f69a)

Click **Show details** to view an in-depth look at the complexity and focus of specific commits.

Filter commits by their complexity. Filter a user’s commits to get a closer look and identify patterns that may warrant follow-up conversations in your 1:1s. Click on a work type column, such as Legacy refactor, to sort the results by work type.

![Commit complexity details table, with information about the commit, its complexity, and the breakdown of coding metric work types for each commit.](media://7bd3a58b-492f-44bc-80b1-e8d8de76ac21)

## How does a user balance coding and reviewing?

The code/review balance matrix compares a user’s coding days to the number of reviewed PRs. Use this matrix in the Status update to ensure your engineers practice a healthy balance between individual contributions and PR review, and collaboration.

Toggle between the code/review balance matrix and the codebase contribution matrix by clicking the down arrow next to the metric name. 

Hover over the data points to see an exact breakdown of a team member's code/review balance as well as the average code/review balance of the selected team.

![Code Review balance graph with the x-axis labeled Number of Reviewed PRs and the y-axis labeled Coding days.](media://c7f2b139-610c-4d67-b6c0-b54aae6947bd)

## How does a user balance Impact and Efficiency?

The codebase contribution matrix compares a user's Impact to Efficiency percentage. Use this matrix to show the cognitive difficulty of a set of work and how much Rework was required to accomplish it.

Toggle between the code/review balance matrix and the codebase contribution matrix by clicking the down arrow next to the metric name.

Mouse over over the data points to see an exact breakdown of a team member's codebase contribution, as well as the average codebase contribution of whichever team occupies the team filter.

![Codebase contribution graph, with the x-axis labeled Efficiency and the y-axis labeled Impact.](media://68178cfd-9398-4ee4-b5f2-c5aabedf1004)

If Impact increases, look for Efficiency to hold relatively steady. The High Impact commits should occur only at specific points in the project’s lifecycle. Try to avoid High Impact commits at the end of a sprint or during the fit-and-finish stage of a project.

## Viewing a user's total activity

The Status update includes the Work log view of an individual user to give an overview of their recent work. This helps spot patterns and trends within a user’s activity.

Both the manager and the engineer can review this section before 1:1s. This helps make 1:1s more efficient by keeping you on the same page regarding work status. 

Use the Show filter to select which commit types, PR activity, PR comments, or Ticket activity you'd like to see.

![Check-in Activity overview, with information about commit, PR, and ticket activity.](media://d2ef4b11-4473-40d4-9092-7e5ca2f6cae2)

Use the Weekends toggle to choose whether the chart displays activity from weekends. Look at the activity from other weeks by clicking the previous page and next page arrow buttons on the left and right. Mouse over an icon to view more details about that activity.

## Viewing a user’s PR activity

The PR section shows the PRs open during the selected time frame. Managers can use the PR section to gain insight into long-running open PRs and see where an engineer needs assistance so they can provide help and coaching.

Narrow down which PRs you see by choosing a Sort by option, like Recently opened, Biggest, and Least activity. Using these filters means you see exactly which PRs you're interested in.

![PR activity overview, with bars for each PR.](media://159224c3-27f9-4a63-88cf-1b838bc42499)

Hover over a PR to view more information about it, such as recently committed code or comments. Click on a PR to see the pull request number and a link to view it.

## What does the Player card show?

Player card displays metrics across four categories relevant to assessing a developer’s overall contributions. The four metric categories are culture, activity, predictability, and efficiency. Each category has a colored border that correlates with the category legend at the top of the Player card.

> ℹ️ [View rights](https://appfire.atlassian.net/wiki/spaces/FD/pages/1802272970) impact what data you see in the Player card. For collaborative metrics like Iterated PRs, Reaction time, PR iteration time, Thoroughly reviewed PRs, Time to first comment, and Time to merge, your Player card data will look different if you only have access to view your own metrics rather than having access to view others’ metrics. Having limited view rights limits the actions that can be counted toward your collaborative metrics in Flow reports.

![Player card, with a tile for each metric which includes the metric value, trend, and an open to show details.](media://b68c4894-11be-4f86-a7e2-286240c37957)

### Culture

Culture metrics pertain to a developer's role within their larger team. This gives insight on how the developer contributes to the code review process.

### Activity

Activity metrics reflect how a developer’s habits contribute to their team’s work pace.

### Predictability

Predictability metrics measure how efficiently your team completes its work.

### Efficiency

Efficiency metrics measure how a developer contributes to the overall flow of the team and the rate at which they move work through the pipeline.

### Additional insight into individual metrics

To get more information on an individual metric, click **Show details** within a metric card.

Expanding a metric shows a developer’s target for that metric and their current status against that target. Learn more about [setting targets](https://appfire.atlassian.net/wiki/spaces/FD/pages/1802371242).

![Player card metric details expansion, with a bar graph and additional metric information.](media://e8d66f3f-1f76-4596-b5cd-f290370a7db1)

## How do I customize the Player card’s metrics?

You can customize the Player card to display the metrics that most matter to you in your 1:1s.

To customize which metrics the Player card displays:

1. Click **Edit metrics** in the top right of the Player card report.
2. Select the metrics you want to include in your Player card report.
3. Click **Update layout**. Your selected metrics appear within the Player card report.

![Player card Edit metrics menu.](media://db68f729-5a38-430f-9405-7ff180f97833)