Docs
🎯 Goals/Alerting
Templates

Goals Templates

Hatica Goals empowers teams to achieve their full potential by setting, monitoring, and driving success through meaningful and measurable changes. Engineering managers can adopt various goal templates to set clear objectives, track real-time progress, and make proactive decisions based on insights. This document provides an overview of different goal templates available within Hatica, explaining their types, data sources, descriptions, and calculation methods.

Developers with no Pull Requests since x days

  • Type: Velocity, Project Health
  • Data Sources: VCS/Git Tools
  • Description: Promote a culture of active participation by ensuring developers regularly contribute to the codebase.
  • Calculation: We calculate the number of days since each developer’s last Pull Request creation date to identify developers who have not submitted a Pull Request within the specified x days.

Limit Work in Progress to x Pull Requests

  • Type: Velocity
  • Data Sources: VCS/Git Tools
  • Description: Limiting Work in Progress is widely recognized as the most critical driver for more focused teams that deliver faster. By ensuring developers handle fewer active Pull Requests at a time, teams can work more collaboratively and efficiently, leading to shorter cycle times.
  • Calculation: We calculate this using the total number of open Pull Requests authored by all team members across all repositories. If the work-in-progress pull requests exceed the specified limit, they are flagged.

Update task status within x days

  • Type: Velocity, Project Health
  • Data Sources: Project Management Tools
  • Description: To keep projects on track, it's important to oversee task progress effectively. Set time limits (x days) for each stage of development to ensure tasks are progressing on time. For example, if a task stays "In Progress" too long, it might mean that it wasn’t truly in progress or it needs to be broken down into smaller tasks.
  • Calculation: Amount of time that each task remains in different statuses, beginning when it's moved to 'In Progress,' and then tracking the duration for all statuses until it is completed. Status is tracked individually for each ticket status and flagging tasks that exceed the specified limit of x days.

Developers with no Pull Request activity since x days

  • Type: Velocity
  • Data Sources: VCS/Git Tools
  • Description: Promote a culture of active participation by ensuring developers regularly contribute to the codebase through Pull Requests, commits, reviews, and other activities, fostering collaboration and efficiency within the team.
  • Calculation: We track the timestamps of the last Pull Requests created, commits pushed, and any other Pull Request-related activities by each developer. By comparing these timestamps to the current date, we determine developers who have not engaged in any Pull Request activity for the specified duration of x days.

Limit Pull Request Size to x lines of code changes

  • Type: Velocity, Project Health
  • Data Sources: VCS/Git Tools
  • Description: Encourage smaller, more manageable Pull Requests for easier and faster code reviews, improving the quality and efficiency of the development process.
  • Calculation: We track the number of lines of code (LOC) changed in each Pull Request. Compare this count to the specified limit of x lines. If the LOC count is more than x, we flag the Pull Request as a violation of this goal.

Limit Pickup Time to x days

  • Type: Velocity
  • Data Sources: VCS/Git and Project Management Tools
  • Description: Ensure that Pull Requests are picked up for review promptly, thereby optimizing the code review process. This leads to smoother development cycles, faster feedback for developers, and quicker identification of potential issues.
  • Calculation: We track the timestamp of when the Pull Request was created and compare it to the timestamp of the first review action (comment, approve or request for change). The duration between these two timestamps is the time for the first review. We flag the pull requests that exceed the specified limit.

Pull Request merged with fewer than x reviewers

  • Type: Project Health
  • Data Sources: VCS/Git Tools
  • Description: Monitor Pull Requests that haven't received a minimum number of reviews. This helps ensure thorough code review and promotes knowledge sharing within the team. Some teams require multiple reviewers (>1) which is easily set with this goal.
  • Calculation: We track the number of reviewers involved in the review process for each Pull Request. If this count is less than x, the Pull Request is flagged as a violation of the goal. This calculation ensures that Pull Requests undergo a thorough review by multiple reviewers as needed.

Limit Merge Cycle Time to x days

  • Type: Velocity
  • Data Sources: VCS/Git and Project Management Tools
  • Description: Track the time it takes for Pull Requests to be merged (or closed) after creation. This helps identify delays and optimize the overall development process.
  • Calculation: We track the timestamp of when the Pull Request was created and compare it to the timestamp of when it was merged (or closed). The duration between these two timestamps gives us the time it took for the Pull Request to be merged (or closed) after creation. We flag the pull requests that exceed the specified limit.
ManageFAQ